Gestione da manager Corba di agenti Cmip e Snmp

5Con l’avvento di tecnologie emergenti general purpose per il calcolo distribuito,
specificate attraverso il modello di riferimento teorico RM-ODP verso l’inizio degli anni
’90, si è pensato al loro utilizzo in ambienti di gestione di reti. In particolare lo standard
CORBA di OMG è la prima tecnologia influenzata da RM-ODP e sembra avviato ad
assumere una crescente importanza nell’unificazione dei domini dei sistemi per la
gestione di rete con i sistemi distribuiti. L’architettura di CORBA verrà descritta nel
Capitolo 4.
Poichè si prevede che comunque SNMP, CMIP e CORBA nel prossimo futuro
coesisteranno dati gli alti costi negli investimenti già avvenuti e anche perchè CORBA
non è ancora maturo per alcuni compiti specializzati, non vi sarà la presenza di un
modello di gestione predominante. E’ possibile prevedere un crescente utilizzo di
traduttori e gateway fra CORBA ed i sistemi esistenti, per un successivo e graduale
passaggio al mondo CORBA. E’ presumibile inoltre che CORBA verrà utilizzato nel
futuro per supportare servizi avanzati nelle telecomunicazioni, cioè quelli conformi
all’architettura TINA (Telecommunications Information Networking Architecture)
descritta nel Capitolo 5.
Lo scopo del progetto nell’ambito dell’XI Master CEFRIEL è fondamentalmente
quello di:
• introdurre ed analizzare i modelli predominanti nella gestione di reti, TMN e SNMP,
introducendo alcuni loro aspetti critici (capitoli 2 e 3);
• descrivere CORBA come maggiore tecnologia influenzata dal modello di riferimento
ODP (Open Distributed Processing), che sembra avviata ad assumere crescente
importanza nel contesto della gestione di rete (capitolo 4);
• analizzare l’architettura distribuita object oriented TINA (Telecommunications
Information Networking Architecture) che rappresenta una soluzione universale per
la creazione e la gestione dei nuovi servizi per le telecomunicazioni (Capitolo 5 );
• classificare il lavoro svolto nell’ambito dell’integrazione di differenti modelli di
gestione di rete, focalizzando la nostra attenzione su applicazioni CORBA-based nel
ruolo di manager (come CORBA possa accedere a entità gestite) e sul lavoro svolto
dal gruppo JIDM (Joint Inter-Domain Management) nella traduzione delle
specificazioni GDMO/ASN.1 (linguaggi formali di specifica dell’informazione in
Introduzione
6
CMIP) e IDL CORBA (linguaggio di definizione delle interfacce) e nella
conversione delle interazioni per il supporto alla costruzione di un gateway
CORBA/TMN. Scopo primario di questa fase di studio è quello di analizzare alcune
problematiche e aspetti critici  relativi al processo di traduzione (Capitolo 6);
• studiare ed analizzare la piattaforma di gestione object-oriented OSIMIS (OSI
Management Information Service) che fornisce un ambiente per lo sviluppo di
applicazioni complesse di gestione in ambiente OSI. In questo contesto si vuole
descrivere il processo di sviluppo che porta alla realizzazione di un agent TMN,
partendo dalle sue specifiche GDMO/ASN.1 e utilizzando lo stack protocollare, i tool
e i servizi messi a disposizione da ISODE, un ambiente di sviluppo OSI (Capitolo 7);
• descrivere le fasi di sviluppo e i tool coinvolti nella realizzazione pratica del
traduttore GDMO/IDL (gdmo2idl) che implementa le principali regole di
Specification Translation JIDM(Capitolo 8);
• descrivere il processo di implementazione di un prototipo di gateway che utilizzi le
API di alto livello fornite da OSIMIS per l’interazione con l’applicazione agent e le
interfacce IDL, come output della fase di traduzione gdmo2idl, per la comunicazione
Manager CORBA/Gateway;
• descrivere uno scenario implementativo del prototipo di gateway CORBA/TMN che
permetta di convertire sia il modello dell’informazione che le interazioni fra i due
domini di gestione(Capitolo 9).
7Capitolo 2 
Introduzione a SNMP
SNMP (Simple Network Management Protocol)  è un protocollo di gestione di reti
adottato come standard nel 1989 dall' Internet Engineering Task Force (IETF), come
soluzione temporanea, nell'attesa di uno strumento più completo e di lungo termine, quale
CMIP. Data però la lentezza dell'attività ISO di standardizzazione e la complessità del
nuovo standard, SNMP è diventato molto diffuso presso i produttori ed è diventato, grazie
anche alla sua semplicità, lo strumento predominante per la gestione di reti.
SNMP è un protocollo di livello applicazione, che opera sul livello di trasporto User
Datagram Protocol (UDP) dello stack di protocolli internet. Il modello di gestione di rete
è costituito fondamentalmente dai seguenti elementi:
• Stazione di gestione;
• Nodo agent;
• Management Information Base (MIB);
• Protocollo di gestione.
La stazione di gestione è tipicamente una workstation che ha la funzione di
interfacciare l'operatore con il sistema di gestione di rete e tradurre i requisiti del primo in
richieste verso elementi remoti nella rete; essa fondamentalmente contiene un'interfaccia
per il monitoraggio e controllo della rete, un set di applicazioni per l'analisi dei dati
ricevuti dagli agent ed un database di informazioni estratte dai MIB degli agent.
Un nodo agent è tipicamente un dispositivo hardware (host, router, bridge, etc.)
contenente un software agent, che ha il compito di permettere la comunicazione con la
stazione di gestione utilizzando il protocollo SNMP per rispondere ad interrogazioni del
manager o per inviare notifiche asincrone di eventi significativi.
Introduzione a SNMP
8
Una Management Information Base (MIB) rappresenta una collezione di oggetti, che
riflette lo stato delle risorse di rete gestite; essa rappresenta sia lo schema, sia l'istanza
della base di dati che contiene le informazioni di gestione. Lo schema viene utilizzato dal
Manager per garantire l'interoperabilità con i diversi agent, mentre l'istanza della MIB
viene implementata dall'agent per rappresentare lo stato delle proprie risorse.
La MIB ha una struttura ad albero le cui foglie sono le variabili che devono essere
gestite, e che sono univocamente identificate da un Object Identifier (OID), cioè dalla
sequenza di nodi numerati necessari a raggiungere l'oggetto dalla radice alla foglia.
Per specificare le regole di definizione dello schema e le regole di implementazione
delle istanze della MIB, viene utilizzata la Structure of Management Information (SMI),
specificata con la RFC1155. La SMI ha quindi il compito di fornire delle tecniche
standard al fine di:
• Definire la struttura della MIB;
• Definire sintassi, forme permissibili, modalità di accesso e range dei valori
associati alle variabili, di un particolare un oggetto della MIB.
La struttura della MIB deve essere unica, per garantire che le variabili utilizzate per
rappresentare una particolare risorsa siano le stesse in tutti gli agent; ad ogni variabile è
associato un tipo, che viene definito utilizzando delle macro con sintassi ASN.1. I tipi
permessi nella definizione di variabili, sono i seguenti:
• Tipi semplici (INTEGER, OCTECT STRING, OID, NULL);
• Tipi predefiniti (Gauge, Timetick).
Vi è inoltre un meccanismo che permette di raggruppare delle variabili di tipo
semplice in tabelle.
Un protocollo di gestione infine, consente lo scambio di informazione fra stazione e
agent sotto la forma di messaggi SNMP. E' importante precisare che il protocollo SNMP
non supporta comandi imperativi, cioè  azioni che possono essere eseguite sulle variabili;
infatti le uniche operazioni consentite sono l'alterazione e l'ispezione di variabili. Le
operazioni supportate sono fondamentalmente di tre tipi:
9• GET con la quale la stazione di gestione richiede un oggetto scalare ad un agent o
con la quale l'agent risponde (GetRequest, GetNextRequest, GetResponse);
• SET con la quale la stazione di gestione modifica un oggetto scalare di un agent
(SetRequest);
• TRAP con la quale un agent invia una notifica asincrona di un evento significativo
(Trap).
SNMP è caratterizzato da una notevole semplicità nell'architettura e nei protocolli;
tale semplicità costituisce però anche la causa dei principali limiti del modello. Fra questi,
i più evidenti sono i seguenti:
1. SNMP non è adatto a reti di grandi dimensioni su scala geografica per limitazioni
di performance, principalmente per le limitazioni introdotte dal meccanismo di
polling.
2. SNMP non è adatto a reperire grandi volumi di dati come ad esempio tabelle di
routing;
3. Le Trap in SNMP non vengono confermate in ricezione. L'agent non riceve
conferma da parte del manager, della ricezione della Trap.
4. SNMP prevede un meccanismo di autenticazione molto debole. L'unico
meccanismo infatti, è il nome della community ( che viene scambiato in chiaro fra
manager ed agent). Per questo motivo è più adatto quindi ad operazioni di
monitoring che di controllo;
5. SNMP non supporta direttamente comandi imperativi, cioè modifiche dirette alle
risorse gestite dagli agent. L'unico modo per causare un'azione in un agente è
quello di modificare un valore nella MIB;
6. Il  modello della MIB è semplificato e non permette query di tipo complesso;
7. SNMP non supporta comunicazioni manager-manager (ad esempio, non ci sono
meccanismi per comunicare le conoscenze fra i vari manager);
8. Il punto di accesso alle informazioni è sempre l'agent; questo significa che una
stazione di gestione ha l'obbligo di conoscere la locazione dell'agent per accedere
e far riferimento alle informazioni sulle risorse rappresentate da questo.
Introduzione a SNMP
10
9. SNMP non mette a disposizione meccanismi di riuso che sono invece tipici
dell'approccio Object-Oriented, poichè tutti gli oggetti della MIB sono scalari e
non includono attributi, azioni, notifiche e messaggi.
2.1  SNMPv2
Le carenze di SNMP nell'ambito della sicurezza, soprattutto  per quanto riguarda gli
aspetti di autenticazione, determinano un impiego prevalente di SNMP per applicazioni di
monitoring e non di configurazione. Per superare questo problema nel luglio del 1992
venne rilasciato un insieme di standard denominato: "secure SNMP" che si indirizzava
alla soluzione dei problemi di sicurezza di SNMP, senza introdurre miglioramenti nelle
prestazioni.
Per migliorare le prestazioni di SNMPv1 venne rilasciato, sempre nel luglio 1992, un
memorandum conosciuto come Simple Management Protocol (SMP) che però non
sarebbe mai diventato un RFC.
Iniziarono quindi le procedure per la definizione dello standard SNMPv2, con
miglioramenti funzionali e relativi alla sicurezza di SNMPv1. Nell'ottobre del 1992
furono formati due gruppi di lavoro, uno per gli aspetti di sicurezza e l'altro per quelli
funzionali. Il risultato del loro lavoro divenne un insieme di Proposed Internet standard
nel marzo del 1993. Questa versione è conosciuta come party-based SNMPv2.
I miglioramenti fondamentali apportati a SNMPv1 da SNMPv2 riguardavano:
• le prestazioni,
• la sicurezza,
• la possibilità di costruire gerarchie di manager.
SNMPv2 non è però mai diventato uno standard di mercato perché apparve troppo
laborioso da configurare ed usare, troppo costoso da sviluppare dal punto di vista
dell'agente, non sufficientemente stabile. Questi fattori sommati alla popolarità di SNMP
sconsigliarono le aziende dall'insistere su SNMPv2.
Alla fine del 1994 si riunirono nuovamente i gruppi di lavoro per studiare le variazioni
necessarie a far decollare SNMPv2, ma alla fine non si riuscì a trovare un accordo ed
emersero due soluzioni principali: SNMPv2* e SNMPv2USEC.