Ciclo di vita dei Network Service

Il ciclo di vita di un Network Service e tutte le operazioni coinvolte in esso possono essere raggruppate nelle seguenti fasi:

0. modellazione 1. on-boarding

2. creazione NS (day 0 e day 1) 3. operazioni su NS (day 2) 4. terminazione NS.

0. Modellazione

L’IM di OSM fornisce i meccanismi per la progettazione del comportamen- to di un NS a partire dalla descrizione della topologia fino a quella delle operazioni del suo ciclo di vita; oltre a ci`o, permette di includere il codice relativo alle automazioni. La composizione di pi`u NS costituisce un Network slice; per supportare la modellazione e la distribuzione di quest’ultimo, l’IM fornisce un modello specifico denominato Network Slice Template, NST. Un NST `e generalmente una composizione di diversi NSD e VLD [1.4] che inter- connettono i NS in base a una topologia specifica. Slice differenti possono condividere gli stessi NS. I NS sono a loro volta composti da Network Func- tions (VNF, PNF o HNF) aventi comportamenti differenti. Anche in questo

caso l’IM fornisce un mezzo per poter descrivere la topologia interna, le ri- sorse richieste e le operazioni del ciclo di vita delle VNF. In particolare, la progettazione di servizi e funzioni di rete avviene, rispettivamente, tramite l’uso di NS Packages e NF Packages. Un package non `e altro che una cartella compressa, .tar.gz che a seconda del tipo, NS o NF, contiene diversi file e sottocartelle. Nel dettaglio, un NF Package contiene:

• una cartella charms. Al suo interno troviamo tutto il necessario per la configurazione dinamica e il monitoring della NF (day 1 e day 2); • una cartella cloud-init. Contiene i file necessari per l’istanziazione

iniziale delle immagini Cloud su cui eseguir`a la NF; • cartelle icons, images e scripts;

• file README per documentare il pacchetto; • file descriptor, VNFD.

Il VNFD `e scritto in YAML1 _{e contiene tutti i dati necessari per modellare}

la NF. Nel dettaglio:

• informazioni di identificazione della NF come id, nome, nome breve, logo, eccetera;

• un’interfaccia di management utilizzata per configurare ed eseguire azioni sulla NF;

• punti di connessione esterni che sono esposti dal VNF verso il NS per abilitare l’interconnessione tra funzioni diverse;

• link virtuali interni usati per connettere le diverse VDU all’interno della VNF. Queste connessioni non vengono esposte verso l’esterno e vengono mappate dal VIM in reti virtuali;

• una o pi`u Virtual Deployment Unit, VDU, che corrispondono alle mac- chine virtuali che eseguiranno componenti della NF. Per ogni VDU vengono poi specificati alcuni dati di identificazione, le interfacce che possono essere collegate a punti di connessione esterni o link virtuali interni, i requisiti in termini di risorse di calcolo e di archiviazione e l’immagine del software per la VM. Inoltre, `e possibile specificare il file cloud-init da eseguire al primo avvio per configurare l’istanza.

• Profili IP, che consentono di definire parametri per le reti virtuali che interconnettono le VDU come ad esempio indirizzi di rete, parametri DHCP e server DNS;

• metriche e parametri usati per le operazioni di day 0, day 1 e day 2. Un NS Package contiene pressoch´e le stesse cartelle e file di un NF Package; in particolare, sono assenti le cartelle images e cloud-init, ma sono presenti le cartelle ns config e vnf config. Anche in questo caso, la modellazione del NS avviene tramite un file descriptor, NSD, scritto in YAML, che contiene:

• informazioni di identificazione del NS come id, nome, nome breve, logo, eccetera;

• riferimento ai VNFD che modellano le NF che compongono il servizio; • uno o pi`u descrittori VNFFG [1.4];

• punti di connessione esterni che, in maniera simile a quanto avviene per le NF, possono essere utilizzati da un NST per interconnettere tra loro diversi NS;

• VLD [1.4] che descrivono i collegamenti per l’interconnessione dei punti di connessione esterni delle VNF;

• profili IP che consentono di definire parametri per le reti virtuali che interconnettono le VNF come ad esempio indirizzi di rete, parametri DHCP e server DNS;

• metriche e parametri usati per le operazioni di day 0, day 1 e day 2. La modellazione separata di NF e NS presenta diversi vantaggi:

• la figura che modella il NS (ad esempio, il fornitore di servizio) pu`o astrarre dalla struttura interna delle NF concentrandosi esclusivamente sulle propriet`a esterne che esse forniscono;

• riutilizzo delle NF in pi`u NS senza un lavoro di modellazione extra; • miglior gestione della complessit`a delle diverse componenti.

1. On-boarding

Una volta che i packages sono pronti, tramite la CLI di OSM possono essere validati e caricati nel sistema in modo che possano fungere da template per la creazione, successivamente, di funzioni e servizi di rete. Il caricamento dei packages pu`o avvenire anche tramite GUI. Questa fase prende il nome di on-boarding. In OSM, l’unit`a minima che pu`o essere messa in esecuzione `e il NS: non `e possibile eseguire una NF singolarmente. Per ogni NS devono essere aggiunti prima tutti i packages delle NF che lo compongono e poi il package del servizio stesso.

2. Creazione NS

Una volta che i pacchetti NS e NF sono stati correttamente inseriti in OSM, possono essere usati come modelli per la creazione del NS. A tempo di crea- zione dell’istanza possono essere forniti parametri aggiuntivi a NS e alle NF che lo compongono; ci`o va a beneficio della riusabilit`a dei NS e delle NF. In questa fase, OSM interagisce con il VIM per allocare le risorse della NFVI alle VNF che compongono il NS. Questa fase pu`o essere suddivisa in due sottofasi:

• la day 0, in cui vengono istanziate le VDU appartenenti alle diver- se VNF. Le VDU sono configurate inizialmente a tempo di boot tra- mite cloud-init. Un esempio di configurazione iniziale tramite cloud- init `e l’abilitazione del servizio ssh in modo che la VDU sia gestibile dall’esterno una volta creata.

• La day 1, in cui `e possibile configurare dinamicamente le diverse VNF tramite Juju [3.1.3].

3. Operazioni su NS

Questa `e la fase di day 2 in cui si monitorano le istanze delle VNF associate al NS che sono attive e forniscono il servizio desiderato. In questa fase vengono gestite le richieste dei client, effettuate tramite apposite API, che possono riguardare il servizio di rete (ad esempio, azioni per aumentare o diminuire le risorse, per sospendere o riabilitare il servizio, eccetera) o le funzionalit`a offerte da questo (ad esempio, aggiunta di un nuovo utente). Altre azioni da gestire sono quelle invocate internamente dal ciclo di controllo definito nei packages NF e/o NS. Tipicamente queste azioni sono generate quando alcuni parametri che vengono monitorati superano certe soglie (ad esempio, definizione di politiche di scale-out automatico).

4. Terminazione NS

Questa `e la fase conclusiva del ciclo di vita di un NS. L’istanza NS viene terminata insieme a tutte le istanze VNF associate. Il VIM riceve la richiesta di rilasciare tutte le risorse virtuali allocate.