Alma Mater Studiorum - Università di Bologna Facoltà di Scienze Matematiche Fisiche e Naturali Dipartimento di Scienze dell’Informazione Supporto al multihoming nei protocolli SIP e RTP: uno strumento simulativo laureanda: Selene Vincenzi relatore: Dott. Vittorio Ghini

Scenario Proxies ABPS: ● Permette al correspondent node di comunicare col il mobile node ● Nasconde la mobilità del mobile node al correspondent node ● Firma i pacchetti nel canale virtuale tra client proxy e server proxy La scenario di rete realistica implementato e' costituito da: - 2 reti di classe B suddivise in subnet con tecnologia IEEE g e IEEE Router per instradare pacchetti tra le diverse subnet - Nodi ethernet e WiFi - 5 Access Point - 1 host mobile - 1 proxy server SIP/RTP - Ostacoli.

Scenario: RWMA Il meccanismo QoS chiamato Robust Wireless Medium Access prevede due applicazioni, una sulla station ed una sul server, che fungano da proxy per le applicazioni VoIP. UDP Load Balancer: ULB si occupa di incapsulare in datagram UDP i pacchetti RTP ricevuti dall'applicazione ed inviarli a destinazione. ULB posta sul Mobile Host Riceve notifiche da più fonti, alla luce delle quali decide se il pacchetto deve essere scartato o ritrasmesso, quale interfaccia utilizzare per inviare il datagram. ULB posta sul Fixed Host Registra l'indirizzo IP dell'interfaccia wireless da cui ha ricevuto un UDP datagram.

Obiettivi Obiettivo generale: Implementazione del bilanciamento di carico tra le varie interfacce di rete disponibili. Progettazione e implementazione: - progettazione del metodo di gestione dell'univocità dei singoli pacchetti: modifica del protocollo RTP. - implementazione, sul proxy server, di un metodo che distingua le eventuali copie di un pacchetto, sulla base della modifica apportata al protocollo RTP. - gestione delle notifiche ricevute dall'ULB posto sulla station.

RTP Ritrasmissione pacchetto RTP: quante volte è stato spedito? È stato inserito il campo retryNum, in questo modo: Client: Ogni qualvolta il pacchetto venga inviato, verrà incrementato il suo retryNum. Server: Grazie all'introduzione del retryNum l'ULB posto sul server è in grado di riconoscere quale pacchetto avente lo stesso numero di sequenza è quello più aggiornato.

Server Proxy SIP/RTP Poiché ora possono arrivare più copie del medesimo pacchetto, per riconoscere la copia più aggiornata viene controllato il valore del campo retryNum.

Gestione notifiche Monitor: ReconfNot: indica quando è possibile inviare pacchetti. Ted: IPNotify: indica quando è necessario ritrasmettere pacchetti. Nel caso in cui il Ted mi dia una notifica negativa, ma l'interfaccia utilizzata sia attiva, questa verrà identificata come sospetta.

Gestione notifiche 1 Nel caso in cui mi arrivi un IPNotify “failure”, ma vi sia un'interfaccia di rete attiva, o sospetta, l'ULB tenta di rispedire il pacchetto. Il retryNum viene incrementato.

Gestione notifiche 2 All'arrivo di un ReconfNot “CONFIGURED” l'applicazione richiede un indirizzo al server DHCP, una volta configurata l'interfaccia, rispedisce i pacchetti che non erano stati inviati prima.