L'interoperabilità tra IntServ e DiffServ

Nei paragrafi precedenti sono state illustrate quelle che attualmente sono le due soluzioni maggiormente quotate per portare il concetto della qualità del servizio sulla rete Internet. Entrambe hanno i loro vantaggi e svantaggi, IntServ introduce il concetto fondamentale di QoS associata al singolo flusso, ma porta inevitabilmente a problemi di scalabilità, DiffServ elimina l'esigenza di mantenere informazioni di stato per i singoli flussi e non ha bisogno di alcun protocollo di segnalazione, tuttavia manca della capacità di ``isolare'' le singole richieste di QoS.

In realtà non è detto che le due soluzioni vadano applicate in modo esclusivo, si stanno facendo diversi tentativi [15] volti proprio a permettere l'interoperabilità delle due soluzioni. IntServ si mostra molto più utile ed efficiente per la rete d'accesso dell'utente mentre DiffServ è certamente più adatto per le reti di transito sulle quali passano grossi aggregati di traffico.

Figure: L'integrazione di IntServ e DiffServ
\resizebox*{12cm}{!}{\includegraphics{immagini/CAP3/IntServANDDiffServ.eps}}

In figura [*] è appunto mostrata questa situazione. Secondo questo scenario, gli host sono collegati a reti di accesso che supportano IntServ e la segnalazione RSVP end-to-end, in realtà però il traffico prodotto arriva alla rete di transito dove è supportato DiffServ, e quindi i vari traffici vengono aggregati secondo i criteri adottati da quest'ultimo. In prossimità delle interfacce IntServ-DiffServ, ci sono gli edge-router, costituiti per metà da un router RSVP standard e per l'altra metà da un modulo di interfaccia capace di interagire con l'admission control della rete DiffServ. In prossimità delle interfacce DiffServ-IntServ, ci sono invece i boundary router, adibiti allo svolgimento delle normali funzioni di policing della rete DiffServ.

Una caratteristica importante è la possibilità di garantire la segnalazione RSVP end-to-end, in questo modo la rete DiffServ sottostante risulta del tutto trasparente agli host. In pratica l'host mittente genera il messaggio Path contenente la descrizione del traffico, all'interno della rete di accesso IntServ questo viene processato in maniera standard dai router RSVP. In prossimità del primo edge-router le informazioni di stato convogliate dal messaggio Path vengono memorizzate, ed il messaggio viene inoltrato verso la rete di transito che viene attraversata fino a raggiungere la rete IntServ all'altro capo, in quest'ultima il messaggio viene nuovamente processato dai router RSVP. A questo punto in prossimità dell'host ricevente viene generato il messaggio Resv che deve effettuare la prenotazione delle risorse. Il meccanismo standard di prenotazione viene applicato all'interno della rete IntServ, arrivato all'edge-router il messaggio viene accettato o rifiutato a seconda della disponibilità di risorse sull'interfaccia a valle. In pratica viene sottoposto al controllo d'ammissione della rete DiffServ basandosi sul livello di servizio diffserv richiesto (ottenuto mediante un mapping delle classi IntServ), se viene accettato attraversa in modo trasparente la rete di transito fino a giungere all'altra sottorete IntServ. A questo punto il messaggio Resv giunge all'host mittente, il quale lo interpreta come una conferma della disponibilità di risorse e quindi può iniziare a trasmettere.

Con questa tecnica si riesce a garantire una qualità del servizio end-to-end anche su una rete eterogenea che utilizzi contemporaneamente le due diverse tecnologie.

Debian User 2003-06-05