3. NETWORK SIMULATOR
In questo capitolo analizzeremo Network Simulator (NS), l’ambiente di simulazione per le reti di telecomunicazioni che abbiamo utilizzato nel nostro lavoro di tesi.
Partiremo da un’analisi molto generale sulla simulazione e sui suoi aspetti per passare poi ad una dettagliata descrizione di NS, dalle sue caratteristiche alle sue funzionalità fino ai moduli già presenti che abbiamo utilizzato per implementare il protocollo RSVP-TE.
3.1. L’importanza della simulazione
La simulazione è l’imitazione del funzionamento di un sistema reale per lo studio di particolari aspetti. Essa si ottiene riproducendo l’evoluzione temporale del processo in questione, e più precisamente generandone un’evoluzione artificiale.
I mezzi di simulazione oggi a disposizione sono diversi (da carta e penna ai software sui calcolatori), ma in ogni caso un aspetto fondamentale di ogni tecnica è il modello di simulazione, che è una rappresentazione del sistema da analizzare data da un insieme di assunzioni espresse sotto forma di relazioni matematiche, logiche o simboliche fra entità del sistema stesso.
I motivi che spingono all’approccio simulativo sono diversi: • lo studio e la sperimentazione delle interazioni interne di un
sistema complesso;
• una migliore conoscenza del sistema reale come conseguenza della creazione del modello di simulazione; • lo studio dell’impatto sui risultati dei diversi parametri del
modello di simulazione;
• la valutazione del funzionamento e delle prestazioni di un sistema prima della costruzione del prototipo;
• la verifica di soluzioni analitiche;
• la possibilità di valutare eventi e condizioni rare o rischiose.
Altri aspetti fortemente vantaggiosi che spingono verso un processo di simulazione sono:
• la valutazione what-if senza interrompere il funzionamento del sistema;
• la compressione e l’espansione del tempo per l’analisi dettagliata di fenomeni interessanti;
• l’acquisizione di conoscenze sull’interazione fra le diverse variabili del sistema e sulla maggiore importanza di alcune rispetto ad altre;
• l’identificazione dei punti deboli del sistema;
• la flessibilità nello studio del comportamento del sistema. Naturalmente accanto ai numerosi aspetti positivi ci sono tutta una serie di complicazioni e difficoltà: la creazione del modello e la sua validazione possono richiedere molto tempo, e l’analisi stessa di un sistema complesso può essere molto lunga. Inoltre è necessaria una forte esperienza nelle tecniche di simulazione e i risultati delle prove possono essere comunque di difficile interpretazione.
Per l’organizzazione di uno studio di simulazione sono necessarie varie fasi, come mostra la figura 3.1:
1. fase iniziale: bisogna formulare il problema, definendo gli obiettivi e pianificando lo studio;
2. costruzione del modello e acquisizione dei dati: si deve progettare il modello, acquisire i dati di input ed output dal sistema reale, implementare il modello, verificarlo e validarlo;
3. simulazioni: bisogna definire le varianti da studiare, progettare le sessioni di simulazione e analizzare i risultati, ed eventualmente pianificare nuove sessioni di simulazione;
NO NO
NO
Formulazione del problema Definizione degli obiettivi
Astrazione del modello Raccolta dati
Esecuzione e analisi dei dati Codifica del modello
Progetto delle sessioni di simulazione
Validazione
Verifica
Documentazione e presentazione dei dati Figura 3.1: fasi del processo di simulazione
4. documentazione e presentazione dei dati: si deve documentare il modello e le diverse sessioni di simulazione, e infine mostrare i risultati dello studio.
Concludiamo questa veloce panoramica parlando della simulazione ad eventi discreti, che è il tipo di simulazione che ci interessa da vicino.
Ricordiamo innanzitutto che le variabili di stato sono quelle variabili che caratterizzano in modo completo lo stato del sistema e la cui dinamica definisce interamente l’evoluzione del modello. Nei sistemi discreti [8] le variabili di stato cambiano solo in istanti appartenenti appunto ad un insieme discreto; l’evoluzione in un determinato intervallo di tempo di un sistema di questo tipo è data quindi da un numero finito di eventi, e perciò è necessaria esclusivamente la loro simulazione.
Per effettuare uno studio simulativo su questi sistemi bisogna dapprima stabilire lo stato iniziale e le modifiche da apportare alle variabili di stato per ogni evento, e poi ordinare gli eventi stessi in un calendario sulla base dell’istante di occorrenza. La simulazione (come esecuzione del programma) consiste quindi nello scorrere il calendario, eseguire gli aggiornamenti delle variabili di stato in base all’evento verificatosi ed effettuare le misure sulle variabili di uscita che ci interessano.
3.2. Network Simulator
NS è un simulatore di rete IP-based, nato come variante del simulatore di rete REAL e implementato dall’Università di Berkeley nel 1989. Nel 1995 lo sviluppo fu supportato anche dal gruppo DARPA (una collaborazione tra USC/ISI, Xerox PARC, LBNL e Università di Berkeley) attraverso il progetto VINT (Virtual InterNetwork Testbed), e numerosi continuano ad essere ancora oggi i contributi di altre ricerche, da ACIRI a UCB Daedalus fino a Sun Microsystem, data la natura open-source del simulatore [9].
NS utilizza come linguaggio di programmazione il Tcl (Tool Command Language), per descrivere tutte le operazioni necessarie alla definizione di una simulazione [10]. Mediante comandi Tcl è infatti possibile impostare lo scenario di rete oggetto dello studio di simulazione (la topologia della rete, le proprietà dei collegamenti, i protocolli da usare, ecc.) e la sua evoluzione temporale (la composizione del traffico, la generazione e la terminazione delle sessioni, eventuali modifiche della topologia della rete), elaborare i dati acquisiti e ottenere i risultati cercati. Inoltre, sempre attraverso comandi Tcl, è possibile effettuare operazioni come la gestione dei file o le operazioni di ingresso/uscita.
NS è stato costruito semplicemente aggiungendo le funzioni specifiche di un simulatore di reti ai servizi di base offerti da Tcl (e da OTcl, che è la versione Tcl orientata alla programmazione di oggetti).
Nel nostro lavoro di tesi abbiamo utilizzato la seconda versione di NS (NS2), e in particolare la versione 2.26 per Linux.
Riportiamo di seguito alcune parti di un programma d’esempio che presenta vari comandi utili alle funzioni appena menzionate.
# Impostiamo la topologia della rete set s1 [$ns node] #sorgenti
set s2 [$ns node]
set G1 [$ns mpls-node] #gateway set r1 [$ns node] #ricevitore
# Impostiamo i collegamenti e le loro proprietà $ns duplex-link $s1 $G1 10Mb 100ms DropTail $ns rsvp-duplex-link $s2 $G1 1Gb 10ms Param Null $ns simplex-link $G1 $r1 10Mb 1ms DropTail
$ns simplex-link $r1 $G1 1Mb 10ms DropTail
# Impostiamo il traffico, creando una sorgente TCP, # una sorgente UDP e un ricevitore TCP
set tcp1 [new Agent/TCP/Reno] $ns attach-agent $s1 $tcp1
set udp2 [new Agent/UDP] $ns attach-agent $s2 $udp2 set sink1 [new Agent/TCPSink] $ns attach-agent $r1 $sink1 $ns connect $tcp1 $sink1 $ns connect $udp2 $sink1 # Creiamo delle applicazioni set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1
set ftp2 [new Application/FTP] $ftp2 attach-agent $tcp2
# Scriviamo una procedura per il calcolo del rate proc record {step}
{
global NumBytePrec1 set now [$ns now]
set Byte1 [$mon1 set barrivals_]
set DeltaByte1 [expr $Byte1-$NumBytePrec1] puts $f1 "$now [expr $DeltaByte1/$step*8]" set NumBytePrec1 $Byte1
$ns at [expr $now+$step] "record 0.5" }
# Apriamo i file per i risultati set f1 [open rate w]
# Definiamo gli istanti di partenza delle sorgenti # e delle procedure $ns at 0.0 "record 0.1" $ns at 0.1 "$ftp1 start" $ns at 1.0 "$udp2 start" $ns at 5.0 "$udp2 stop" $ns at 20.0 "$ftp1 stop" $ns at 20.1 "finish" $ns run
Altri comandi tipici di uno script Tcl di simulazione sono i seguenti:
• set ns [new Simulator]
che genera un oggetto (e un suo handler) della classe Simulator in ambiente C++, e contestualmente uno shadow-object in ambiente Otcl, legato strettamente al primo in modo che una modifica dell’uno comporti automaticamente una modifica sull’altro;
• ns-random 67
che fissa il seme del generatore di numeri casuali, in modo che, utilizzando di volta in volta semi diversi, si possano effettuare simulazioni incorrelate;
• set file1 [open simulazione.nam w]
che creano un file per la visualizzazione NAM della simulazione (in figura 3.2 c’è un’immagine generata appunto dall’interfaccia grafica del simulatore);
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
• set file2 [open simulazione.tr w] $ns trace-all $file2
che creano un file di trace con le informazioni sui pacchetti nei vari nodi (istante di generazione, mittente, destinatario, dimensione, ecc.), come mostra la figura 3.3; questo file viene spesso utilizzato per il calcolo di vari parametri tramite appropriate procedure.
3.2.1. Object-programming
Possiamo immaginare una rete di telecomunicazioni come un insieme di oggetti di diversa natura e con diverse proprietà (router, bridge, link, applicazioni, ecc.) che interagiscono e cooperano per offrire dei servizi agli utenti.
La scomposizione di una rete nei suoi elementi base è utile per costruire sia la struttura interna del simulatore sia l’interfaccia verso l’utente: si può infatti associare ad ogni componente reale un oggetto virtuale nell’ambiente di simulazione che ne rispecchia più o meno fedelmente le caratteristiche. Questa proprietà di modularità permette di creare dei modelli estremamente flessibili, facilmente adattabili cioè al particolare
problema da studiare. La figura 3.4 esemplifica il concetto: ad ogni oggetto reale che compone la rete da simulare corrisponde un oggetto simulato che ne approssima il comportamento.
Organizzare il codice in questo modo (Object-Oriented Programming) comporta diversi vantaggi:
• è più semplice ed intuitivo costruire una simulazione;
• il codice del simulatore risulta strutturato coerentemente alla realtà, quindi più facile da gestire;
Simulazione Mondo reale Router Ogg. Nodo Ogg. Link Ogg. Link Ogg. Appl. Ogg. Appl. Ogg. Appl. Appl. Appl. Appl.
Figura 3.4: oggetti reali e oggetti simulati Link
• è più semplice sviluppare nuove funzionalità, grazie alla facilità con cui i diversi oggetti possono essere associati ad entità reali.
3.2.2. Aspetti generali
NS2 è scritto interamente in C/C++ e utilizza un interprete Tcl/OTcl come interfaccia utente. Questo software di simulazione è di pubblico dominio e può essere scaricato gratuitamente all’indirizzo http://www.isi.edu/nsnam/ns/ [9]. Il programma (molto semplice da istallare) è stato progettato e testato su sistemi Unix/Linux, ma può essere utilizzato facilmente anche su piattaforma Windows.
Come detto, il suo motore di simulazione (engine) è scritto in C++ e l'utente interagisce con il simulatore mediante comandi Otcl. I comandi possono essere digitati uno dopo l’altro dal prompt del simulatore oppure raccolti in un file di testo usato come input dal programma. Tcl/OTcl è un linguaggio di scripting (le istruzioni vengono interpretate ed eseguite una linea alla volta), disponibile sia in ambiente Unix/Linux che Windows.
OTcl, come accennato nel paragrafo precedente, è l'interfaccia attraverso cui l'utente descrive il modello di simulazione, indicando topologia della rete, sorgenti di traffico, istanti di
attivazione e così via. Il programma simula il funzionamento della rete descritta nel file di configurazione della simulazione (uno script Otcl) e produce l’insieme dei file di risultati.
E’ inoltre possibile impostare il simulatore NS2 in modo da generare un file di testo (tipicamente con estensione .nam) in cui vengano registrati tutti gli eventi che avvengono durante la simulazione, ed in particolare gli istanti di generazione e ricezione di ogni singolo pacchetto ed il loro percorso dettagliato nella rete. Questo file può essere successivamente processato da un programma dotato di interfaccia grafica, denominato NAM (Network Animator Module) che permette di ricostruire la simulazione attraverso un’animazione. In questo modo possiamo avere un riscontro visivo del funzionamento della rete e dell'interazione fra i vari componenti; inoltre nel corso dell'animazione è possibile realizzare dei fermo-immagine, aumentare o diminuire la velocità di riproduzione e, “cliccando” sui vari elementi grafici che compongono la simulazione, ottenere informazioni specifiche (ad esempio, cliccando su un collegamento si ottiene il numero dei pacchetti persi su quel link).
Due esempi di animazione NAM sono riportati nelle immagini in figura 3.5, tratte dalla simulazione di reti molto semplici.
3 7 2 6 1 5 0 4 8 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
3.2.3. Simulazione ad eventi
NS2 fa parte della classe dei simulatori ad eventi discreti (event-driven simulator), nei quali vengono eseguite delle azioni solo agli istanti in cui si presentano eventi che modificano lo stato del sistema, come ampiamente descritto nel paragrafo 3.1.
Il simulatore dispone di una lista di eventi marcati con l’istante di simulazione. Il centro elaborazione del simulatore accede alla lista di eventi attraverso uno scheduler, che gestisce le operazioni di inserimento e di estrazione dalla lista in base ad un criterio predefinito: ad ogni passo il centro elaborazione seleziona dalla lista l’evento indicato dallo scheduler (figura 3.6-a), esegue le azioni associate a tale evento e genera eventualmente nuovi eventi che passa allo scheduler in modo che siano aggiunti alla lista (figura 3.6-b). Il meccanismo viene avviato da un insieme di eventi decisi dall’utente.
Lo scheduler è implementato attraverso una classe OTcl e viene generato contestualmente alla creazione di un'istanza della classe Simulator.
NS2 dispone di due sottoclassi per lo scheduler:
• Scheduler/List: è lo scheduler predefinito, realizzato da una lista concatenata ordinata cronologicamente; a causa di tale modalità di ordinamento, l'inserzione e la rimozione di un
evento richiedono una scansione della lista, mentre la scelta del successivo evento da processare comporta semplicemente l'estrazione del primo elemento dalla testa della lista;
• Scheduler/RealTime: permette di sincronizzare gli eventi simulati con il tempo reale; questa funzionalità (attualmente ancora in fase di sviluppo) consente di interfacciare il simulatore con reti a bassa velocità, ottenendo l’emulazione di reti reali.
Selezione dell’evento Step 2
Figura 3.6-a: scelta dell’evento Step 1 Invocazione scheduler Evento 1, t=0.0 Evento 2, t=0.5 Evento 3, t=0.8 Evento 4, t=1.2 Evento 5, t=1.6 Scheduler Centro elaborazione
3.2. I moduli che abbiamo utilizzato
In questo paragrafo parleremo dei moduli e dei protocolli già implementati in NS2 che abbiamo utilizzato nel nostro lavoro di implementazione e dai quali siamo partiti per sviluppare il modulo di RSVP-TE.
E’ necessario innanzitutto notare che l’implementazione di qualsiasi protocollo differisce in vari punti dai documenti ufficiali del protocollo stesso, perché l’ambiente di simulazione impone diversi limiti all’implementazione, perché alcuni aspetti possono essere più facili da implementare in una simulazione e perché la natura stessa della simulazione e le
Step 4
Step 3 Esecuzione delle azioni
associate all’evento Step 4 Aggiunta di un nuovo evento Evento 1, t=0.0 Evento 2, t=0.5 Evento 3, t=0.8 Evento 4, t=1.0 Evento 5, t=1.2 Scheduler Elaborazione eventi
risorse disponibili (memoria e CPU) limitano necessariamente il livello di dettaglio.
Bisogna comunque sottolineare che per ogni nuova implementazione si cerca di raggiungere delle caratteristiche ben precise quali la modularità (in modo da poter facilmente aggiungere e sostituire blocchi funzionali), l’estendibilità (per l’inserimento di nuovi oggetti e nuove opzioni), la facilità d’utilizzo (in modo che gli utenti possano imparare ad usare il modulo con semplicità) e la portabilità (per poter utilizzare il modulo con linguaggi e sistemi operativi differenti).
3.2.1. RSVP/ns
RSVP/ns è il modulo che implementa il protocollo RSVP. Creato dal ricercatore dell’Università di Bonn Marc Greis [11], presenta quasi tutti gli oggetti di RSVP, sia nel formato per IPv4 che per IPv6, come mostra la tabella in figura 3.7.
Ci sono alcune piccole differenze tra gli oggetti implementati in RSVP/ns e gli oggetti reali definiti da RSVP; per esempio, nell’oggetto Session di RSVP/ns sono omessi la porta di destinazione e l’identificativo del protocollo, visto che nella simulazione le sessioni sono identificate univocamente dal loro flow-id, mentre per semplificare il processing dei pacchetti è stato aggiunto un campo con l’indirizzo del destinatario.
Object Class-Num SESSION 1 RSVP_HOP 3 TIME_VALUES 5 ERROR_SPEC 6 STYLE 8 FLOWSPEC 9 FILTER_SPEC 10 SENDER_TEMPLATE 11 SENDER_TSPEC 12 RESV_CONFIRM 15
Gli unici oggetti trascurati in RSVP/ns sono Integrity (nella simulazione non possono esserci messaggi corrotti da utenti maliziosi), Scope (non è implementato lo stile di prenotazione WF), AdSpec (tralasciato per semplicità) e Policy_Data (non è implementato alcun meccanismo di policing).
Per quanto riguarda i messaggi, sono stati tutti implementati, tranne il PathErr Message: la sua unica funzione nel mondo reale, almeno in RSVP, è segnalare errori nati da mismatch coi numeri di porta, ma NS2 non utilizza le porte, rendendone così inutile la realizzazione.
Altre limitazioni in RSVP/ns sono la presenza di un solo stile di prenotazione (FF) invece dei tre stabiliti dall’RFC e, nell’ambito degli Integrated Services, della sola classe controlled-load.
Gli agent RSVP conservano i path e i reservation state su tutti i nodi RSVP e generano e processano i messaggi. In ogni agent c’è una struttura “session” per ogni sessione: essa contiene vari campi, tra cui i puntatori alle liste di psb e rsb, un flag che segnala il refresh e un flag che segnala la volontà di inviare un ResvConf Message in risposta ad un Resv Message. Le strutture “psb” e “rsb” ricalcano quasi fedelmente la composizione indicata dall’RFC.
Per le sessioni ci sono due liste, come mostra la figura 3.8: tutte le sessioni sono in una session_list e tutte le sessioni con state block (che devono essere quindi rinfrescate) sono in una timer_list, posta in ordine cronologico di refresh.
Il link per RSVP si basa su un duplex-intserv-link, al quale sono stati aggiunti un oggetto RSVPChecker (che ha il compito di intercettare i pacchetti RSVP sul collegamento e inviarli all’agent RSVP del nodo all’estremo del link) e uno scheduler WFQ (che usa gli algoritmi WFQ e WF2Q, con una coda best effort destinata a tutti i pacchetti che il classifier non riconosce
e, grazie all’opzione “borrow”, anche ai pacchetti delle varie classi che superano i limiti imposti).
Il comando per la creazione del link è:
$ns duplex-rsvp-link $n1 $n2 40Kb 10ms 0.8 1000 500 Param Null
che crea un collegamento bidirezionale tra i nodi n1 e n2 con banda pari a 40 Kbps e tempo di propagazione pari a 10 ms. Il parametro 0.8 sta ad indicare che l’80% della banda può essere allocata ai flussi RSVP e il restante 20% è destinato al traffico best effort. Inoltre 1000 bps sono riservati ai messaggi di segnalazione RSVP e la dimensione del buffer del link è fissata
Session Session Session
psb rsb psb rsb psb psb rsb rsb rsb psb psb rsb s_list t_list
in 500 byte. Infine sono indicati l’algoritmo di admission control e lo stimatore utilizzato per tale algoritmo, selezionabili tra una lista di opzioni.
Concludiamo la descrizione del modulo RSVP/ns con l’elenco dei vari comandi che mette a disposizione: nella tabella ci sono i comandi e i vari argomenti, e successivamente c’è una breve spiegazione della funzione svolta da ogni comando.
comando argomenti
1 add-rsvp-agent nodo
2 get-rsvp-agent nodo
3 session rsvpagent, destinazione, flowID
4 release rsvpagent, sessionID
5 sender rsvpagent, sessID, rate, bucket, TTL 6 reserve rsvpagent, sID, style, flow descr. list
7 confirm rsvpagent, sessionID
8 sessions rsvpagent
9 set-status rsvpagent, sessionID, valore 10 get-status rsvpagent, sessionID 11 set-handle rsvpagent, sessionID, oggetto 12 get-handle rsvpagent, sessionID
1. carica l’agent RSVP sul nodo indicato;
2. restituisce un handle per l’agent RSVP del nodo indicato; 3. crea una sessione con i parametri indicati;
4. rilascia una sessione;
5. manda un Path Message per segnalare la creazione di una sessione e i suoi parametri;
6. manda un Resv Message in risposta al messaggio di Path e indica, tra gli altri parametri, la banda da allocare;
7. manda un oggetto Resv_Conf col successivo messaggio di prenotazione;
8. fornisce una lista di tutte le sessioni nell’agent; 9. assegna un valore allo status della sessione; 10. fornisce il valore dello status della sessione;
11. assegna un handle a quell’oggetto di quella sessione; 12. fornisce l’handle di quell’oggetto per quella sessione. Nell’appendice A è inserito uno script di esempio che contiene tutte le più importanti funzionalità di questo modulo.
3.2.2. MNS
Il modulo MNS (MPLS Network Simulator) implementa il protocollo MPLS e le sue funzionalità principali (LDP e label switching). Creato dai ricercatori della Southern California University Gaeil Ahn e Woojik Chun, è stato successivamente
esteso alla versione 2 (MNS-v2.0), in cui il protocollo CR-LDP ha preso il posto del protocollo LDP.
Un nodo MPLS è formato da vari componenti [12], come mostra la figura 3.10, tra cui:
• LDP: genera e processa i messaggi LDP/CR-LDP;
• MPLS Classifier: esegue le operazioni sulle label dei pacchetti (push, pop e swap);
• Service Classifier: classifica i servizi che devono essere forniti ai pacchetti che arrivano, grazie alle informazioni delle label e delle interfacce, e associa ad ogni pacchetto la relativa prenotazione;
• Admission Control: guarda i Traffic Parameter di CR-LDP e determina se il nodo MPLS ha abbastanza risorse per fornire la QoS richiesta;
• Resource Manager: crea e cancella le code e gestisce le informazioni sulle risorse;
• Packet Scheduler: gestisce i pacchetti nelle code in modo che ricevano il servizio richiesto.
In particolare, per estendere il simulatore NS (IP-based) alle funzionalità MPLS, nel classico nodo IP sono stati aggiunti un classifier MPLS e un agente LDP. Quando un nodo MPLS riceve un pacchetto, il classifier MPLS determina se ha una
label o meno. Se la label c’è, il classifier esegue il label switching per il pacchetto, se la label non c’è ma il suo LSP esiste, il classifier lo gestisce come un pacchetto con label, altrimenti (né label né LSP) lo invia all’AddrClassifier, che esegue il normale forwarding di livello 3.
Per il Packet Scheduler è selezionato uno scheduling di tipo CBQ; nel mondo reale, tale componente è implementato nei nodi, in NS invece è stato implementato nei link
Per il label switching sono definite tre tabelle:
CR-LDP Messages Information Flooding Packet out Packet in Routing Protocol CR-LDP Address Classifier MPLS Classifier Resource Manager Admission Control Packet Scheduler Service Classifier
• Partial Forwarding Table (PFT): è la tabella usata per il mapping tra FEC e label; contiene per ogni riga il FEC, il FlowID e un puntatore ad una entry della tabella LIB; • Label Information Base (LIB): ha tutte le informazioni
necessarie al label switching dei pacchetti; in particolare per ogni LSP contiene le label e le interfacce di ingresso e di uscita;
• Explicit Route information Base (ERB): contiene le informazioni per gli ER-LSP attivati, come LSPID e ServiceID.
Quando arriva un pacchetto con label, il classifier trova la giusta entry nella tabella LIB per label e interfaccia d’uscita, in modo da poter effettuare le operazioni di label swapping, e la giusta entry nella tabella ERB per fornire l’appropriato servizio di accodamento. A seconda della classe di appartenenza, il classifier accoda il pacchetto nell’opportuno buffer del CBQ, che lo serve e lo trasmette sull’interfaccia d’uscita (figura 3.11).
Il processo di prenotazione delle risorse nei nodi e nei link MPLS avviene in questo modo: se il componente CR-LDP riceve un messaggio di Request CR-LDP, chiama l’Admission Control per verificare che il nodo abbia le risorse richieste; se così è, l’Admission Control prenota le risorse aggiornando la
Resource Table, e infine il messaggio di richiesta è inviato al successivo nodo MPLS.
Quando il componente CR-LDP riceve un messaggio di Mapping CR-LDP per il setup di un path con risorse, salva le informazioni sulla label e sull’interfaccia nella tabella LIB e le informazioni sul CR-LSP richiesto nella tabella ERB. Quindi chiama il Resource Manager per creare una coda destinata a servire il CR-LSP e salva il ServiceID nella ERB. Infine invia il messaggio di mapping al nodo successivo.
Packet Scheduler 2 (CBQ) Packet Scheduler 3 (CBQ) Packet Scheduler 1 MPLS Classifier Service Classifier Link 1 Link 3 Link 2 Lookup LIB Table Lookup ERB Table
Come mostra la figura 3.12, in MNS ci sono tre livelli di classi e quattro tipi di servizio (Signaling Traffic, Real-time Traffic, High priority Best-effort Traffic, Simple Best-effort Traffic).
Concludiamo anche questa sezione con la descrizione dei comandi Tcl messi a disposizione da MNS, elencati nella tabella 3.13:
1. crea un nodo MPLS;
2. configura gli agenti LDP su tutti i nodi creati;
3. attiva sui nodi la modalità control-driven (o data-driven, o on-demand, o ordered-control);
4. invia un messaggio di Release per rilasciare l’LSP con quel FEC; Link ST RT BT RT1 RT2 RTn HBT SBT Livello 3 Livello 1 Livello 2
comando argomenti 1 mpls-node 2 configure-ldp-on-all-mpls-nodes 3 enable-control-driven 4 send-ldp-release-msg FEC 5 send-ldp-withdraw-msg FEC
6 aggregate-flows FEC1, FEC2
7 setup-erlsp FEC, Explicit Route, LSPID 8 bind-flow-erlsp FEC, flowID, LSPID 9 cfg-cbq-for-SBTS dim. coda, tipo coda, banda, tempo
di coda, extra-delay
10 bind-flowid-to-SBTS flowID
11 bind-ldp-to-SBTS
12 setup-crlsp FEC, Exp.Route, LSPID, rate di traffico, dim. buffer, dim. pkt, setup
prio, holding prio 13 set-flow-prio FEC, flowID, priorità
14 collect-resource-info tempo
15 constraint-based-routing destinazione, banda 16 reroute-lsp-binding LSPID1, LSPID2 17 enable-reroute-egress-lsr
5. invia un messaggio di Withdraw per rilasciare l’LSP con quel FEC;
6. aggrega un flusso fine con FEC1 in un flusso grosso con FEC2;
7. crea un ER-LSP con i parametri indicati, inviando un messaggio CR-LDP Request;
8. associa un flusso con quel FEC e quel flowID all’ER-LSP con quell’LSPID;
9. configura CBQ su tutti i nodi MPLS con i parametri indicati per supportare la classe SBTS (oppure le altre classi);
10. associa i pacchetti con quel flowID al servizio SBTS (o agli altri servizi);
11. associa i pacchetti LDP al servizio SBTS (o agli altri servizi);
12. crea un CR-LSP con i parametri indicati, inviando un messaggio CR-LDP Request;
13. assegna al traffico con quel FEC e quel flowID la priorità indicata;
14. raccoglie le informazioni sulle risorse dai nodi MPLS con intervalli di tempo regolati dal parametro tempo indicato; 15. calcola un explicit route verso quella destinazione e con
16. associa ad un LSP primario un LSP alternativo; 17. permette ai nodi MPLS di fare merging.
Anche per il modulo MNS riportiamo uno script d’esempio con le maggiori funzionalità nell’appendice A.
