2.3 Estensione di RSVP-TE per LSP P2MP
3.1.1 Nodi e Link
Ogni nodo in nsè parte di una classe OTcl e gestisce le fun- zionalità del protocollo IP, definendo la struttura dell’indi- rizzamento usato e trasmettendo i pacchetti sui link pre- stabiliti o consegnandoli al protocollo di trasporto. Dopo aver instanziato una simulazione, possiamo creare due nodi scrivendo:
set n0 [ $ns node] set n1 [ $ns node]
Cosà ˇn facendo associamo a n0 n1 due oggetti ritornati dal
metodonode della classe Simulator. In Figura 3.1a è ripor-
tata l’architettura di un nodo unicast. Notiamo cheentry_
memorizza un riferimento all’istanza del nodo eclassifier_
contiene un riferimento ai classifier. Se la simulazione uti- lizza il multicast, come mostrato in Figura 3.1b, nei nodi sono presenti dei replicatori e unoswitch_ che permette di
inoltrare i pacchetti al classifier appropriato, infatti in ca- so di simulazione multicast, se il primo bit del pacchetto è uno, il pacchetto è multicast, altrimenti unicast. Tutti i nodi
(a) Architettura nodo unicast. (b) Architettura nodo multicast. Fig. 3.1: Architettura di un nodo NS2.
contengono:
• Un indirizzo oid_che cresce monotonicamente da uno,
• La listaneighbor_,
30 Network Simulator 2
• Un identificatore del tipo di nodo,nodetype_;
• Un modulo di routing.
Possiamo adesso unire i due nodi con un link unidirezionale tramite il comando:
$ns simplex-link $n0 $n1 10Mb 15ms DropTail
che crea un link di capacità 10 Mbps, ritardo di propagazione 15 ms e disciplina FIFO1. L’architettura di un link, riportata
in Figura 3.2, contiene in particolare i seguenti oggetti: • head_: puntatore al primo oggetto del link,
• queue_: puntatore all’oggetto coda della classe link,
• link_: punta all’oggetto che simula il comportamento
del link in termini di ritardo di propagazione e capaci- tà,
• ttl_: punta all’oggetto che gestisce il campo TTL del
pacchetto;
• drophead_: punta all’oggetto coda.
Gli ulteriori elementi riportati in Figura 3.2 sono necessa- ri sia alla visualizzazione della simulazione con NAM che per la raccolta di dati. Se è necessario collegare i due no-
Fig. 3.2: Architettura di un link.
di in entrambe le direzioni basta sostituiresimplex-linkcon duplex-link. Possiamo stabilire un valore<queue_limit> di
pacchetti che potranno essere messi in coda su un link dan0
an1:
1Altre possibili discipline di servizio sono: RED (Random Early Discard),
FR (Fair Queueing), DRR (Deficit Round Robin), SFQ (Stochasting Fair Queueing) e CBQ.
3.1 Creare una simulazione 31
$ns queue-limit $n0 $n1 <queue\_limit>
È possibile assegnare una latenza di<time_interval>secondi
a un link dan0an1:
$ns delay $n0 $n1 <time_interval>
Si può assegnare a un link un costo<cost_val>scrivendo:
$ns cost $n0 $n1 <cost_val>
in cui<cost_val>è un numero intero; per default tutti i link
hanno costo pari a 1.
3.1.2
Agent e Application
A questo punto per generare e ricevere pacchetti abbiamo bisogno di dotare i nodi nodi di oggetti Agent, che inseriamo scrivendo:
#Define Agent
set udp1 [ new Agent/UDP] set sink1 [ new Agent/Null] $udp1 set packetSize_ 1500 #Attach Agent and connect $ns attach-agent $n0 $udp1 $ns attach-agent $n1 $sink1 $ns connect $udp1 $sink1
Oltre all’agente UDP sono disponibili agenti TCP che pos- siamo classificare come:
• Agenti TCP unidirezionali: si dividono ulteriormen- te in trasmettitori e ricevitori di vari tipi che imple- mentano altrettante versioni con diverse opzioni per il congestion control e il flow control;
• Agenti TCP bidirezionali: abbiamo un’unica classe TCP bidirezionale, quella Agent /TCP/FullTcp che consente
la trasmissione di dati in entrambe le direzioni e im- plementano la versione RENO del protocollo.
Entrambi gli agenti contengono diverse variabili membro che possiamo utilizzare per modificarne la configurazione.
32 Network Simulator 2
• Traffic generator: riproduce alcuni tipi di traffico, at- tualmente sono disponibili 4 classi:
(i) EXPOO_Traffic: genera traffico secondo un model-
lo ON/OFF con tempi di permanenza distribuiti esponenzialmente,
(ii) POO_Traffic: i tempi di permanza seguono una di-
stribuzione di Pareto,
(iii) CBR_Traffic: genera traffico a rate costante;
(iv) TrafficTrace: permette di generare pacchetti in
base a dati contenuti in un file di traccia.
• Simulated applications: simulano il comportamento di alcune applicazioni reali, attualmente sono implemen- tateApplication/FTPeApplication/Telnet.
Vediamo come creare un agente di traffico esponenziale:
set VBR1 [new Application/traffic/Exponential] $VBR1 set rate_ 1600 kb
$VBR1 set packetSize 1000 $VBR1 set burst_time_ 0.2 $VBR1 set idle_time_ 2.0 $VBR1 attach-agent $udp1
#Attiviamo e disattiviamo la sorgente $ns at 0.05 "VBR1 start"
$ns at 20 "VBR1 stop"
Per generare traffico di Poisson è sufficiente impostare:
$VBR1 set burst_time_ 0 $VBR1 set idle_time_ 1/lambda
conlambdapari alla frequenza di generazione dei pacchetti.
Notiamo come in NS2, per alleggerire la simulazione, un’applicazione non genera dati ma solo la dimensione del pacchetto corrispondente e il ricevitore non fa altro che scar- tare i pacchetti e inviare un eventuale riscontro.
3.1.3
Tracing
Spesso simulando una rete abbiamo bisogno di prelevare dei dati, a questo scopo NS2 mette a disposizione due tipologie di oggetti:
3.1 Creare una simulazione 33
• trace: vengono solitamente creati e inseriti tra due no- di, associando un canale è possibile annotare gli eventi avvenuti durante la simulazione;
• monitor: permette di registrare, usando dei contatori, su un qualunque canale dei parametri globali come il numero di pacchetti trasmessi o quelli ricevuti. Vediamo un esempio in cui, dopo aver creato due nodi, apriamo il file traccia.tr a cui trace_file punta. Il file di
traccia è creato con il comandotrace-all.
set ns [new Simulator] set s1 [$ns node] set d1 [$ns node]
$ns duplex-link 10Mb 10ms DropTail set trace_file [open traccia.tr w] $ns trace-all $s1 $d1 $trace_file
3.1.4
Altri comandi
Affinché simulazioni distinte diano risultati incorrelati è ne- cessario utilizzare un generatore di numeri casuali con se- me diverso per ogni simulazione. Questo si realizza con il comando:
ns-random 60
che setta il seme di numeri casuali a 60.
I file generati nella simulazione devono essere chiusi; i comandi e le operazioni che chiudono uno script vengono in- seriti nella procedurafinish{} che, ad esempio, assume la
forma:
proc finish {} {
global ns nam_file trace_file $ns flush-trace
close $nam_file close $trace_file exit 0
}
A questo punto per far partire la simulazione basta digi- tare il comando:
34 Network Simulator 2
3.2
MNS (MPLS Network Simulator)
Il modulo MNS (MPLS Network Simulator), creato dai ri- cercatori della Southern California University Gaeil Ahn e Woojik Chun [6], implementa il protocollo MPLS nelle sue funzionalità principali, in dettaglio:
• Associazioni tra classi di traffoco e label in modalità control-driven e data-driven con distribuzione down- stream in modalità control-driven e sia downstream che upstream per la modalità data-driven,
• Distribuzione independent-mode in modalità control- driven e sia independent che ordered-mode in modalità data-driven,
• Informazioni di binding di tipo conservative label re- tention mode;
• Possibilità di creare LSP espliciti.
Per gestire queste funzionalità sono stato aggiunti a NS2 gli elementi di Figura 3.3, ovvero:
3.2 MNS (MPLS Network Simulator) 35
• LDP/CR-LDP: genera e processa i messaggi del proto- collo di distribuzione delle label,
• MPLS Classifier: esegue le operazioni tipiche del label switching (swap, pop, push),
• Service Classifier: associa i pacchetti MPLS alla cor- retta reservation, processando l’header MPLS,
• Admission Control: controlla se il nodo MPLS in esame ha risorse sufficienti a garantire le specifiche di QoS richieste,
• Resource Managent: gestisce le code;
• Packet Scheduler: gestisce i pacchetti nelle code cosà ˇn da ricevere la QoS stabilita.
L’architettura di un nodo MPLS, riportata in Figura 3.4, comprende:
Fig. 3.4: Architettura di un nodo MPLS.
MPLS Classifier : se il pacchetto ricevuto ha una label vie-
ne eseguito lo switching a livello 2 (tabella LIB), in ca- so contrario (tabella PFT) se il pacchetto va associato ad un LSP gli viene aggiunto un header MPLS e inol- trato tramite switching di livello 2; altrimenti tramite routing di livello 3,
36 Network Simulator 2
Address Classifier : esegue il forwarding di livello 3; Port Classifier : se il nodo è la destinazione il pacchetto
viene passato all’agent di livello superiore.
3.3
RSVP/ns
RSVP/ns [9] è il modulo che implementa il protocollo RSVP. Creato dal ricercatore dell’Università di Bonn Marc Greis, presenta quasi tutti gli oggetti di RSVP, sia nel formato per IPv4 che per IPv6, come mostra la Tabella 3.1. Ci sono alcu- ne 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. Gli unici
Object Class-Num SESSION 1 RSVP_HOP 3 TIME_VALUES 5 ERROR_SPEC 6 STYLE 8 FLOWSPEC 9 FILTER_SPEC 10 SENDER_TEMPLATE 11 RESV_CONFIRM 15 Tab. 3.1: Oggetti di RSVP/ns.
oggetti trascurati in RSVP/ns sono INTEGRITY (nella simu- lazione non possono esserci messaggi corrotti da utenti ma- liziosi), 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
3.3 RSVP/ns 37
Fig. 3.5: Struttura di session e timer list.
reale, almeno in RSVP, è segnalare errori nati da mismatch coi numeri di porta, ma NS2 non utilizza le porte, rendendo- ne così inutile la realizzazione. Altre limitazioni in RSVP/ns sono la presenza di un solo stile di prenotazione (FF) inve- ce 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 è presente una strutturasessionper ogni sessio-
ne: essa contiene vari campi, tra cui i puntatori alle liste di
psbersb, un flag che segnala il refresh e un flag che segna-
la la volontà di inviare un ResvConf Message in risposta ad un Resv Message. Le strutturepsbersbricalcano quasi fe-
delmente la composizione indicata dall’RFC. Per le sessioni ci sono due liste, come mostra la Figura 3.5 tutte le sessio- ni sono contenute in una lista, denominatas_list e tutte
le sessioni che devono essere rinfrescate sono in unat_list,
posta in ordine cronologico di refresh. Il link per RSVP si basa su unduplex-intserv-link, al quale sono stati aggiun-
ti un oggettoRSVPChecker(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 destina- ta 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).
38 Network Simulator 2
$ns duplex-rsvp-link $n1 $n2 40Kb 10ms 0.8 1000 500 Param Null
che crea un collegamento bidirezionale tra i nodin1en2con
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ò es- sere allocata ai flussi RSVP e il restante 20% è destinato al traffico best effort. Inoltre 1000 bps sono riservati ai messag- gi di segnalazione RSVP e la dimensione del buffer del link è fissata in 500 byte. Infine sono indicati l’algoritmo di ad- mission control e lo stimatore utilizzato per tale algoritmo, selezionabili tra una lista di opzioni.
Concludiamo la descrizione del modulo RSVP/ns con un elenco di comandi messi a disposizione e una breve spiega- zione della funzione svolta da ogni comando. Tra parentesi sono riportati gli argomenti di ognuno.
1. add-rsvp-agent ( node ): carica l’agent RSVP sul nodo
indicato,
2. get-rsvp-agent(node) : restituisce un riferimento per
l’agent RSVP del nodo indicato,
3. session(rsvp_a, dst, fID): crea una sessione con i pa-
rametri indicati,
4. release(rsvp_a, sID): rilascia una sessione;
5. sender(rsvp_a, sID, rate, bucket, TTL): manda un es-
saggio di Path per segnalare la creazione di una sessio- ne e i suoi parametri,
6. reserve(rsvp_a, sID, style, flow des list): manda un
messaggio di Resv in risposta al messaggio di Path e indica, tra gli altri parametri, la banda da allocare; 7. confirm(rsvp_a, sID): manda un oggetto Resv_Conf col
successivo messaggio di prenotazione,
8. sessions(rsvp_agent): fornisce una lista di tutte le ses-
sioni nell’agent,
9. set-status(rsvp_a, sID, val): assegna un valore allo
3.3 RSVP/ns 39
10. get-status(rsvp_a, sID) : fornisce il valore dello stato
della sessione,
11. set-handle(rsvp_a, sID, obj): assegna un riferimento
a quell’oggetto di quella sessione;
12. get-handle(rsvp_a, sID): fornisce un riferimento a quel-
l’oggetto per quella sessione.
3.3.1
RSVP-TE/ns
RSVP-TE/ns [4] è un modulo, sviluppato all’università di Pi- sa che implementa il protocollo RSVP-TE. Il modulo RSVP- TE/ns introduce diverse funzionalità che possono di fatto essere suddivise in quattro categorie:
1. LSP establishment, 2. LSP release,
3. Failure Handling (notifica ed abbattimento dell’LSP); 4. Strategie di LSP recovery.
vediamo adesso piú in dettaglio le varie funzionalità, descri- vendo i comandi necessari.
LSP establishment Esistono due diversi comandi per la
creazione di un LSP; con:
<Ingress> create-erlsp-rsvpte <Egress-LSR> <SID> <FlowID> <TunnelID> <Er> <DiffServ Object> <Class Type>
si ha la possibilità di creare un LSP di tipo Explicit Route, mentre con:
<Ingress> create-erbwlsp-rsvpte <Egress-LSR> <SID> <FlowID> <TunnelID> <Er> <DiffServ Object> <Class Type>
possiamo anche effettuare una prenotazione della banda. In entrambi i casi il messaggio di Path contiene, oltre ai clas- sici oggetti RSVP, un oggetto LABEL_REQUEST utilizzato per richiedere ai nodi successivi l’allocazione delle etichet- te. Il simulatore prevede la possibilità di creare un LSP che segua un percorso esplicito specificato dal nodo di ingresso;
40 Network Simulator 2
il campo <Er> contiene proprio l’indirizzo (id) degli LSR che dovranno essere attraversati e è utilizzato per creare l’EX- PLICIT_ROUTE (ERO) da aggiungere al messaggio di Path. Quando un LSR riceve un messaggio di Path processa l’ERO e ne inserisce il contenuto nella psb per fare in modo che i successivi messaggi di Resv seguano lo stesso percorso, in senso contrario, di quelli di Path. Quando il messaggio arri- va all’egress, questo non fa altro che fissare un nuovo valore per l’etichetta da comunicare al nodo precedente e, nel caso sia stata richiesta anche l’allocazione della banda, richiama- re il Resource Manager per eseguire l’operazione di alloca- zione. Viene così creato un messaggio di Resv con il giusto campo LABEL ed inviato al nodo precedente secondo il per- corso individuato dai precedenti messaggi di Path. Quando il nodo ingress riceve il messaggio, l’LSP è stato creato.
LSP release Oltre alla creazione di un LSP viene simula-
to anche il suo abbattimento con il conseguente rilascio della banda eventualmente allocata. Questo si realizza tramite il seguente comando:
<Ingress> release-LSP <SID> <FlowID>
In questo caso il nodo di ingresso invia all’egress un messag- gio di Path Tear con il conseguente rilascio di tutte le risorse allocate per lo specifico LSP; inoltre, nelle tabelle vengono cancellate le righe relative all’LSP abbattuto.
Failure Handling All’interno di una rete è possibile che
il collegamento fra due nodi non sia piú utilizzabile a causa, ad esempio, della rottura di un link. È possibile simulare un simile evento attraverso il comando:
<Up node> break-link <Down node> <ID down node> <ID up node>
Vediamo come reagisce RSVP-TE alla caduta di un link. Un messaggio di Path Error viene spedito, per ogni LSP stabi- lito sul link rotto, in direzione upstream dall’Agent RSVP dell’<Up node>verso l’ingress LSR per comunicargli la cadu-
ta del link; stessa cosa viene fatta dall’Agent RSVP del<Down node>in direzione downstream inviando, però, un messaggio
3.3 RSVP/ns 41
uscita inviano rispettivamente un messaggio di Path Tear e Resv Tear per comunicare l’abbattimento dell’LSP e cancel- lano dalle tabelle LIB, PFT e ERB le righe relative all’LSP abbattuto.
Strategie di LSP recovery Il modulo prevede due possi-
bili strategie di rerouting consecutive alla caduta di un link: con la prima si ha una preallocazione di un LSP di backup, con la seconda il calcolo del percorso alternativo viene effet- tuato preventivamente, ma la sua allocazione è consecutiva all’abbattimento dell’LSP primario. Per selezionare la prima ipotesi si utilizza il comando:
<Ingress> reroute-prealloc <Source> <Egress> <Dst> <OldSID> <SID> <FlowID> <TunnelID> <Rate> <Bucket> <TTL> <Er>
Al contrario, se siamo interessati alla seconda possibilità il comando da utilizzare è:
<Ingress> reroute-precomp <Source> <Egress> <Dst> <OldSID> <FlowID> <TunnelID> <Rate> <Bucket> <TTL> <Er>
4
Modulo NS2 per la
creazione di LSP P2MP
In questo capitolo vediamo l’estensione che abbiamo imple- mentato al protocollo RSVP-TE per la gestione di LSP P2MP realizzata utilizzando il simulatore NS2. Descriviamo inol- tre le due euristiche utilizzate per il calcolo dell’albero multi- cast. Al fine di realizzare la nostra estensione siamo partiti dalla versione 2.26 di Network Simulator, su cui abbiamo istallato il modulo che implementa l’MPLS (MNS, versione 2 per ns 2-26) e il modulo che implementa RSVP-TE (RSVP- TE/ns, patch per ns 2-26) e quello che abbiamo fatto è sta- to estendere il modulo RSVP-TE/ns con gli oggetti introdotti dal nuovo protocollo e permettere che il modulo MNS intera- gisca con esso per la distribuzione delle label. Per realizzare il modulo sono stati modificati molti file di RSVP-TE/ns e di MNSv2, cambiando delle funzioni o aggiungendone intera- mente delle altre. Sono state anche aggiunte due funzioni al modulo che implementa il protocollo di routing OSPF co- sì da calcolare i percorsi punto-multipunto seguendo le due euristiche scelte.
Il capitolo è organizzato come segue: nella prima par- te descriviamo in termini qualitativi le modifiche apportate e tutte le parti aggiunte, rimandando all’Appendice A per la lista completa dei file modificati; nella seconda vediamo la validazione del modulo riportando dei risultati ottenuti da simulazioni su reti generate utilizzando il generatore di topologie casuali BRITE [1].
44
Modulo NS2 per la creazione di LSP P2MP
4.1
Modifiche apportate
Abbiamo costruito il modulo per LSP P2MP integrando un agent RSVP-TE e un classifier MPLS, col primo che si occu- pa principalmente della prenotazione delle risorse e della di- stribuzione delle label e il secondo che si occupa invece delle operazioni di label switching per il forwarding dei pacchet- ti, replicando gli stessi nel caso in cui il nodo in questione sia punto di ramificazione per quella sessione P2MP. Inol- tre sono state aggiunte due funzioni all’agente che imple- menta il protocollo di routing LS in modo che quest’ultimo calcoli i percorsi punto-multipunto seguendo due euristiche prestabilite.
4.1.1
I file di RSVP-TE/ns
Per quanto riguarda i file del modulo RSVP-TE/ns, tutti im- plementati in C++ [3], abbiamo principalmente aggiunto i nuovi oggetti previsti dall’estensione per LSP P2MP, inse- rito dei nuovi campi nella psbe implementato tutte le fun-
zioni per la segnalazione degli LSP introducendo una nuo- va struttura pre gestire le sessioni punto-multipunto deno- minata p2mp_session. In particolare, abbiamo aggiunto gli
oggetti di cui di seguito riportiamo l’interfaccia.