Estensioni da apportare a RSVP-TE
3.3 Network Simulator
3.3.1 Struttura di uno script NS
Di seguito, viene presentato uno script di esempio e ne vengono descritti i principali comandi:
# Creazione di un nuovo Simulator object set ns [new Simulator]
# Definizione topologia set n0 [$ns node] set n1 [$ns node]
$ns duplex-link $n0 $n1 10Mb 20ms DropTail $ns queue-limit $n0 $n1 100
# Definizione della sorgente di Poisson set udp [new Agent/UDP]
$ns attach-agent $n0 $udp
set Poisson [new Application/Traffic/Exponential] $Poisson set burst_time_ 1ms
$Poisson set rate_ 100M $Poisson set packetSize_ 1000
$Poisson attach-agent $udp
# Definizione del ricevitore set sink [new Agent/Null] $ns attach-agent $n1 $sink
$ns connect $udp $sink
#Seme del generatore di numeri casuali ns-random 58
#Generazione file .nam e file .tr set nam_file [open animazione.nam w] $ns namtrace-all $nam_file
set trace_file [open traccia.tr w] $ns trace-all $trace_file
#Definizione procedura di finish proc finish {} {
global ns nam_file trace_file $ns flush-trace close $nam_file close $trace_file exit 0 } #Eventi da simulare $ns at 0.2 "$Poisson start" $ns at 10.0 "$Poisson stop"
$ns at 10.0 "finish"
$ns run
Il primo comando che viene dato al simulatore è il seguente:
set ns [new Simulator]
Tale comando genera una nuova istanza della classe Simulator e restituisce una variabile “ns” contenente il puntatore a tale istanza. La variabile “ns” potrà essere utilizzata per richiamare l’oggetto creato.
La classe Simulator contiene il motore di simulazione, le funzioni necessarie per configurarlo e per inserire nello scheduler gli eventi.
I seguenti comandi servono a creare due oggetti della classe node ed un link tra di loro:
set n0 [$ns node] set n1 [$ns node]
$ns duplex-link $n0 $n1 10Mb 20ms DropTail
I puntatori ai due nodi creati vengono inseriti nelle variabili “n0” ed “n1”. Il link tra n0 ed n1 è di tipo full-duplex, con capacità trasmissiva pari a 10Mbps, ritardo pari a 20ms e disciplina di servizio FIFO.
Dopo aver creato i nodi viene creata una sorgente poissoniana sul nodo n0 che utilizza il protocollo UDP per la trasmissione dei pacchetti:
set poisson [new Application/Traffic/Exponential] $poisson set burst_time_ 1ms
$poisson set rate 100M
$poisson set packetSize_ 1000 $poisson set idle_time_ 0.125ms $poisson attach-agent $udp
Viene quindi creato un ricevitore di tipo sink sul nodo n1 con la funzione di eliminare dalla rete i pacchetti ricevuti; tramite il metodo connect esso viene collegato all’agente trasmittente udp:
set sink [$ns Agent/Null] $ns attach-agent $n1 $sink $ns connect $udp $sink
Per ridurre gli errori di tipo statistico presenti nella simulazione, si eseguono più prove della stessa simulazione facendo in modo che tutti gli elementi casuali siano indipendenti tra una prova e le altre. Per ottenere questa condizione in NS2 si utilizza il seguente comando che permette di inizializzare i generatori di numeri casuali con semi differenti:
ns-random 58
Dopo avere ripetuto le prove indipendenti si calcola una media dei risultati riducendo notevolmente gli errori.
Seguono i comandi che permettono di creare i file di uscita del simulatore, ovvero i file animazione.nam e traccia.tr:
set nam_file [open animazione.nam w] $ns namtrace-all $nam_file
set trace_file [open traccia.tr w] $ns trace-all $trace_file
Tramite il file .nam è possibile visualizzare l’animazione relativa alla simulazione, mentre nel file .tr vengono inserite alcune informazioni riguardanti i pacchetti coinvolti nella simulazione
Infine, si ha la definizione della procedura finish, in cui vengono riportate le operazioni che terminano uno script (nel nostro semplice esempio si hanno solo i comandi per la chiusura dei file):
proc finish {}{
global ns nam_file trace_file $ns flush-trace
close $nam_file close $trace_file exit 0
}
I seguenti comandi servono ad inserire nello scheduler gli eventi da simulare:
$ns at 0.2 “$Poisson start” $ns at 10.0 “$Poisson stop” $ns at 10.0 “finish”
L’ultimo comando dello script serve ad avviare la simulazione:
$ns run
3.4MPLS Network Simulator
Il modulo MNS (MPLS Network Simulator) versione 2.0, creato dai ricercatori della Southern California University Gaeil Ahn e Woojik Chun, è una implementazione della tecnologia MPLS. Tale modulo è compatibile con la versione 2.26 di NS. Nell’ambito di questa tesi si è reso necessario eseguire un adattamento di MNS v2.0 per renderlo compatibile con la versione di NS2 utilizzata (2.32).
Le principali aggiunte che MNS v2.0 apporta a NS2 sono le seguenti:
• MPLS packet switching
• Protocollo CR-LDP
• Strategia control-driven e data-driven
• Modalità control-driven per distribuzione downstream e modalità data-driven per distribuzioni sia upstream che downstream
• Modalità control-driven per distribuzione independent-mode e modalità data-driven per distribuzione sia independent-mode sia ordered-mode
• Conservative label retention mode
• Possibilità di creare LSP espliciti
• Constraint based routing
• Gestione setup e holding priority
Il modello del simulatore MNS è rappresentato in figura 3-3. In esso si possono distinguere diversi componenti, tra i quali:
• LDP/CR-LDP: genera o processa i messaggi LDP/CR-LDP • MPLS Classifier: esegue le operazioni sulle label dei pacchetti
(push, pop e swap)
• Service Classifier: classifica i servizi da garantire ai pacchetti in
arrivo, utilizzando le informazioni estrapolate dalle label e dalle interfacce, e associa ad ogni pacchetto la relativa reservation
• 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 affinché
ricevano il servizio richiesto; è selezionato uno scheduling di tipo CBQ che, se nel mondo reale viene implementato nei nodi, in NS si trova invece implementato nei link
Figura 3-3 Modello concettuale del simulatore MNS
In figura 3-4 è mostrata invece l’architettura del nodo MPLS. All’interno del nodo si trova l’MPLS Classifier che ha la funzione di determinare se il pacchetto ricevuto ha una label o meno. Se la label è presente, l’MPLS Classifier effettua la normale procedura di label switching; in caso negativo, il classifier controlla se il pacchetto debba essere associato ad un LSP o meno. In caso affermativo, il pacchetto viene trattato come un pacchetto etichettato (dopo aver aggiunto ad esso l’header MPLS), altrimenti viene inviato all’Address Classifier, che ha il compito di inoltrare il pacchetto utilizzando il protocollo di routing di livello 3.
MPLS Node CR-LDP Routing Protocol Resource Manager Address Classifier Admission Control Packet Scheduler Service Classifier MPLS Classifier Packet IN Flooding Information LDP/CR-LDP Messages Packet OUT Link
Figura 3-4 Architettura di un nodo MPLS
Nel caso in cui il nodo sia il nodo di destinazione, il pacchetto è inviato al Port Classifier per essere quindi passato all’agent di livello superiore.
Per il label switching sono definite le seguenti tabelle:
• Partial Forwarding Table (PFT): è utilizzata dall’ Ingress LSR
per effettuare il mapping del pacchetto IP in un LSP. Ogni riga contiene FEC, FlowID e un puntatore ad una entry della LIB
Agent (source/null) Agent CR-LDP
MPLS Node
Address Classifier Port Classifier Label Swiching L3 Forwarding If labeled pkt then lookup MPLS Classifier PFT Table LIB Table If unlabeled pkt then lookup• Label Information Base (LIB): contiene informazioni sugli LSP
instaurati e usa tali dati per effettuare il label switching dei pacchetti etichettati; in particolare contiene i seguenti campi:
Incoming Interface
Outgoing Interface
Incoming Label
Outgoing Label
• Explicit Route Information Base (ERB) : utilizzata nel caso siano
presenti dei percorsi espliciti, la tabella contiene informazioni per gli ER-LSP attivati, come LSPID e ServiceID
All’arrivo di un pacchetto con label, il classifier trova la corrispondente entry nella tabella LIB, determinando outgoing label e outgoing interface, in modo da poter effettuare le operazioni di label swapping, e la corrispondente entry nella tabella ERB, determinando il serviceID, per fornire al pacchetto l’appropriato servizio di accodamento. In base alla classe alla quale appartiene il pacchetto, il classifier lo accoda nell’opportuno buffer del CBQ (Class-Based Queueing), che lo serve e lo trasmette sull’interfaccia d’uscita. Tale meccanismo è denominato MPLS QoS traffic processing.