UNIVERSITÀ DEGLI STUDI DI ROMA
TOR VERGATA
CORSO DI LAUREA IN INGEGNERIA DELLE TELECOMUNICAZIONI
GESTIONE di SISTEMI & SERVIZI
di TELECOMUNICAZIONE
(Parte II)
Pietro de Santis
LEG - REG
ST&E
BUSINESS
SOCIAL
Anno Accademico 2008-2009
2
GESTIONE di SISTEMI & SERVIZI
di TELECOMUNICAZIONE
PARTE SECONDA
GLI STANDARD GESTIONALI
OSI - SM, TNM e SNMP
Durata: 24h (6h/settimana x 4 settimane)
Capitolo 1
Il modello generico di riferimento OSIRM (Open Systems Interconnection Reference Model) (3h)
Capitolo 2
Modello OSI-SM per la gestione di
sistema: (sotto)modello rganizzativo
(2h)
Capitolo 3
Modello OSI-SM per la gestione di
sistema: (sotto)modello informativo
(5h)
3
Capitolo 4
Modello OSI per la gestione di
sistema: (sotto)modello comunicativo
(5h)
Capitolo 5
Modello OSI per la gestione di
sistema: (sotto)modello funzionale
(1h)
Capitolo 6
Il Modello TMN dell’ ITU-T (3h)
Capitolo 7
Gestione di INTERNET: Modello
SNMP (Simple Network Management
Protocol) (5h)
4
CAPITOLO 1
Il modello generico di riferimento OSIRM (Open Systems Interconnection Reference Model)
1.1 Considerazioni preliminari sul modello di riferimento OSIRM (Open System Interconnections-Reference Model)
dell’ISO/ITU-T.
II modello di riferimento OSI-RM (Open System Interconnections-Reference Model)
dell’ISO/ITU-T è passato alla storia delle telecomunicazioni come il “Modello OSI a
sette strati” (la cosidetta «pila OSI») e fa normalmente parte dei corsi di insegnamento
relativi a «Reti di Telecomunicazione» o «Reti di Computers». (Ad esempio, vedi:
R.Adinolfi, “Reti di Computer” Cap.III, McGraw Hill, 1999). Per questo si ritiene che
uno studente del corso GST (secondo anno dlla laurea magistrale) già conosca il Modello
di Riferimento OSI-RM avendolo studiato in altri corsi. Qui ci limitiamo a offrirne solo
una breve descrizione enfasizzando gli aspetti rilevanti ai modelli gestionali.
Il modello OSI-RM ha goduto di vasta popolarità fra i progettisti di reti di
telecomunicazione e/o trasmissione dati ed ha costituito, nel tempo, la base di molti
standards per l’interconnessione di apparati TLC. Ci si chiede allora: “Perchè studiare il
modello OSI-RM in un corso GST?” La risposta è la seguente. Sebbene il modello OSIRM non sia un modello specificatamente gestionale esso e’ incluso in questo corso
perchè costituisce la base su cui si fondano vari modelli gestionali fra cui il modello OSISM ( Open System Interconnections – System Management) e il modello TMN
(Telecommunications Management Network) entrambi importanti nella gestione dei
sistemi TLC.
In generale i modelli di riferimento sono definiti come modelli che forniscono una
architettura di base per evidenziare le mutue relazioni fra vari standards e per facilitare lo
sviluppo di standards specifici di certe aree di interesse tuttavia essi non contengono una
normativa sufficientemente dettagliata da poter essere utilizzata direttamente per creare
standards.
Quindi il modello di riferimento OSI-RM non contiene norme specifiche per
realizzare un sistema standardizzato futuro o rispetto alle quali si vuole verificare la
5
conformità di un sistema gia’esistente, bensi’ esso offre una infrastruttura concettuale
di riferimento nell’ambito della quale possono svilupparsi vari standards (standards
OSI) contenenti specifiche dettagliate e con valore normativo. Quindi il modello OSIRM fornisce concetti architetturali e terminologia per gli standards OSI ed e’
sufficientemente generico da permettere lo sviluppo di una molteplicità di standards. Si
tratta di uno “standard di standards” o “meta-standard” per l’interconnessione di
sistemi aperti.
OSI-RM e’ stato sviluppato per vari scopi fra cui i più importanti sono menzionati
nel documento ITU-T Rec.X.200. Essi sono,
1) facilitare lo sviluppo/miglioramento di standards relativi all’interconnessione di
sistemi aperti (o “standards di interconnessione di sistemi”)
2) razionalizzare/evidenziare le mutue relazioni fra i vari standards di
interconnessione di sistemi
3) permettere a gruppi di esperti internazionali di lavorare indipendentemente allo
sviluppo di standards di interconnessione di sistemi, relativi a zone diverse
dell’infrastruttura stessa (e.g. strati diversi nel modello OSI-RM stratificato).
•
La prima versione del modello OSI-RM (Basic Reference Model, ITU-T Rec.
X.200, Aprile 1994)
Il primi risultati degli studi sui sistemi di trasmissione dati, effettuati dall’
Organizzazione Internazionale per gli Standards (ISO, International Standard
Organization), una agenzia delle Nazioni Unite, furono pubblicati per la prima volta nel
1984. Il documento era intitolato:
ISO 7498: “Information Processing Systems – Open Systems Interconnection –
Basic Reference Model”, Geneva, 1984 (Pubblicato anche come ITU-T
Recommendation X.200, Aprile 1994)
Diciamo subito che il Modello di Riferimento (Reference Model) per
l’Interconnessione di Sistemi Aperti o Modello di Riferimento OSI-RM (Open Systems
Interconnection-Reference Model) é una rappresentazione astratta delle principali
modalita’ di interconnessione fra sistemi reali remoti e cooperanti (cioé interoperanti per
il raggiungimento di uno stesso scopo). Una definizione rigorosa sara’ fornita fra poco.
Ma vediamo subito il significato dei tre termini “sistema”, “interconnessione” e
“aperto” in un contesto OSI.
6
•
Definizione dei termini che appaiono nella sigla OSI (Open System
Interconnectios, Interconnessioni fra Sistemi Aperti)
La parola “Sistema (System, in inglese)”, corrispondente alla lettera “S” nella
sigla OSI é stata definita dall’ITU come segue “un insieme di uno o piu’ computers,
terminali, operatori umani, processi applicativi, apparati per la trasmissione di
informazione etc. che costituisce un tutt’uno autonomo capace di effettuare il processing
dell’informazione e/o il trasferimento di informazione”.
Notare la differenza di questa definizione OSI di “sistema”e la definizione di
sistema TLC fornita nella prima parte del corso. Inoltre notare l’espressione “uno o piu”.
La presenza di questa espressione fa si’ che quello che viene chiamato “sistema” in un
contesto OSI puo’ rappresentare un solo “elemento di rete” isolato oppure una
moltitudine di questi elementi purche’ essa costituisca un tutt’uno autonomo.
Autonomo significa con funzionamento indipendente dal funzionamento di altri sistemi
coesistenti in rete. Ad esempio un computer, parte di una rete TLC, può considerarsi un
“sistema”.
La parola “Aperto” (“Open”) corrispondente alla lettera “O” nella sigla OSI sta
ad indicare che entrambi i sistemi che si scambiano informazione nell’ambito di una
cooperazione, rispettano le norme del modello OSI e quindi possono interagire fra di loro
cioé sono “aperti” l’uno verso l’altro. Il termine “sistema aperto” significa sistema che
soddisfa le raccomandazioni/norme OSI ed e’ quindi capace di interagire con altri sistemi
aperti.
La parola “Interconnection (Interconnessione)” corrispondente alla lettera “I”
della sigla OSI sta ad indicare uno scambio di informazione fra sistemi mutuamente
cooperanti al fine di portare a termine un “compito comune”. Un compito comune puo’
essere una transazione bancaria, lo scambio di posta elettronica, il recupero di dati da una
base dati o la gestione di una rete di telecomunicazioni: compiti realizzati con l’intervento
umano e/o con l’impiego di programmi software applicativi.
Il Modello di Riferimento OSI-RM e’, quindi, un meta-modello generico valido
per comunicazioni fra una grande varietà di applicazioni residenti in sistemi interconnessi
e cooperanti. Fra queste, come il caso particolare del modello OSI-SM, si possono
annoverare le applicazioni gestionali per la gestione dei sistemi di telecomunicazione.
Applicazioni gestionali strutturate secondo OSI-SM sono trattate nei prossimi capitoli.
7
1.2
Il Modello di Riferimento OSI-RM: rappresentazione
astratta di un insieme di «sistemi» reali interconnessi e
cooperanti.
Il Modello di Riferimento OSI-RM é stato sviluppato per facilitare lo
sviluppo di standards per l’interconnessione di sistemi (come or ora definiti!).
Letteralmente Open Systems Interconnection-Reference Model significa Modello di
Riferimento per l’Interconnessione di Sistemi Aperti. Conseguentemente il Modello di
Riferimento OSI-RM si definisce come segue: Il Modello di Riferimento OSI é una
rappresentazione astratta di un insieme di sistemi reali interconnessi e cooperanti,
del quale ritiene solo le proprietà rilevanti alle interconnessioni fra sistemi
(chiamate «proprieta’ OSI-RM»).
Come precedentemente indicato «interconnessione» significa scambio di
informazione fra sistemi cooperanti mentre un «sistema reale» puo’ essere un computer o
un terminale d’utente di una rete TLC o una postazione di operatore in una rete di
gestione di una rete TLC. In un contesto OSI-RM, il modello astratto di un sistema reale
(o di un elemento di un sistema reale) gode delle seguenti proprietà (Vedere Tav.1.2.1):
1) Il Modello ritiene quelle proprietà del sistema reale che sono rilevanti
all’interconnessione fra sistemi,
2) Il comportamento “esterno” del Modello, rilevante all’ interconnessione con altri
sistemi, é equivalente a quello del sistema reale. Ma il comportamento esterno del
Modello é legato anche al suo comportamento interno, quindi il Modello é descritto
in termini di entrambi i comportamenti.
3) Il Modello é descritto in termini di comportamento interno e comportamento
esterno, ma solo quest’ultimo é utilizzato per sviluppare standards per un sistema
reale.
É molto importante riconoscere che in un contesto OSI ci sono degli elementi
reali che sono modellati da entità astratte. Ad esempio il Modello di Riferimento OSI
parla di un “sistema reale aperto” e di un “sistema aperto” (entità astratta
corrispondente) oppure di un “processo applicativo” (elemento reale) e di una “entità
applicativa” (entità astratta corrispondente).
Ripetiamo che OSI-RM modellizza solo alcuni aspetti di un sistema reale e dei
suoi elementi (i.e. quelli relativi alla interconnessione fra sistemi cooperanti) mentre altri
aspetti non vengono modellizzati. Questi ultimi, tuttavia, sono modellizzabili con
rappresentazioni astratte non-OSI definite anche rappresentazioni “locali”.
8
Tav.1.2.1 IL MODELLO DI RIFERIMENTO
OSI
SISTEMA REALE
Il Modello ritiene quelle proprietà del
sistema reale che sono rilevanti
all’interconnessione fra sistemi,
Proprietà del sistema
reale
Proprietà del sistema
reale rilevanti a OSI
Il comportamento “esterno” del
Modello, rilevante all’
interconnessione con altri sistemi, é
equivalente a quello del sistema
reale. Ma il comportamento esterno
del Modello é legato anche al suo
comportamento interno, quindi il
Modello é descritto in termini di
entrambi i comportamenti.
MODELLO
STANDARDS
Il Modello é descritto in termini di
comportamento interno e
comportamento esterno, ma solo
quest’ultimo é rilevante allo sviluppo
degli standards di interconnessione
di sistemi. (standards OSI)
•
Terminologia OSI-RM
Esempi di quantità reali e corrispondenti quantità astratte (in corsivo) sono
riportati nelle seguenti definizioni (Raccomandazione ITU-T, X.200, 07/1994, pag.2):
1. Sistema reale (Real system). Un insieme di uno o piu’ computers (con
relativo software), terminali d’utente, operatori umani, (NOTA BENE!) apparati per la
trasmissione/commutazione/ istradamento di informazione etc. che costituisce un tutt’uno
autonomo (“autonomous whole”, nel testo inglese) capace di effettuare il processing e/o
trasferimento dell’ informazione.
2. Sistema reale aperto (Real Open System). Un sistema reale che soddisfa la
normativa OSI quando comunica con altri sistemi reali.
3. Sistema aperto (Open system). La rappresentazione degli aspetti di un sistema
reale aperto rilevanti al Modello di Riferimento OSI. (Un Sistema aperto é il modello
astratto OSI di un Sistema reale aperto)
4. Processo applicativo (Application process), Un processo applicativo e’ un
elemento in un sistema reale aperto che svolge attività di data processing/communication
relativamente ad una particolare applicazione (NOTA BENE!).
Un processo applicativo e’ costituito da un insieme di risorse reali e può essere
di diversi tipi e.g. manuale o computerizzato. Ad esempio, una Persona TLC che opera in
un terminale per transazioni bancarie e’ un esempio di processo applicativo manuale, un
9
elaboratore digitale su cui gira un programma FORTRAN per accedere a/recuperare dati
da una base dati oppure un programma “Gestore” in una applicazione gestionale tipo
“Gestore-Agente” sono esempi di processo applicativo computerizzato.
Fare attenzione a questa terminologia OSI-RM! Notare che nella terminologia
OSI-RM un processo applicativo non é un processo dinamico nel senso specificato nella
prima parte del corso e.g. sequenza temporale di attività svolte con procedure prestabilite
per il raggiungimento di uno scopo prefissato misurabile, bensì un essere umano o un
elaboratore digitale che fanno parte del sistema reale
5. Entità applicativa (Application entity), Una entita’ applicativa e’ la
rappresentazione astratta di un processo applicativo reale del quale ritiene solo gli aspetti
rilevanti al Modello di Riferimento OSI cioè all’interconnessione fra sistemi. Quindi, una
entità applicativa é il modello OSI di un processo applicativo reale.
•
Esempio di coppia “Processo Applicativo” – “Entità Applicativa”
(Applicazione “Data Retrieval”)
La Fig.1.2.1 illustra un esempio di coppia processo applicativo - entita’
applicativa. Si tratta di una Applicazione “Data Retrieval” atta a recuperare dati da una
base dati (Sistema Reale Aperto No.2) tramite terminale d’utente (Sistema Reale Aperto
No.1). I due sistemi reali sono interconnessi e cooperano tramite una rete TLC reale non
mostrata in figura. Il processo applicativo “Data Retrieval” è costituito da elaboratori
digitali su cui girano opportuni programmi. Esso è suddiviso in un processo PA No.1
residente nel terminale d’utente e un processo PA No.2 attestato sulla base dati. PA No.1
e PA No.2 effettuano data processing e cooperano scambiandosi mutuamente dati. La
parte di un processo applicativo rilevante a questo scambio di dati (process
interconnection) e’ rappresentato in figura da un ellisse con la sigla “OSI”. Essa viene
modellizzata nelle due “entita’ applicative” EA1 e EA2. Diciamo che EA (entità
astratta) è il modello OSI di PA (elemento di un sistema reale). Notare come PA
possa essere una applicazione che effettua data processing di varia natura, anche per
scopi non direttamente relazionati all’interconnessione fra sistemi. Ad esempio nel
terminale d’utente PA No.1 effettua preprocessing / formattizzazione dei dati ricevuti
dalla base dati per adattarli all’interfaccia d’utente (e.g. GUI. Graphic User Interface).
La Fig.1.2.1 mostra come le entità applicative EA1 e EA2 siano ubicate nel livello
più alto (livello No.7) della architettura OSI-RM e interagiscano con un comportamento
esterno uguale a quello dei processi applicativi PA1 e PA2.
10
TERMINALE UTENTE
BASE DATI
(SISTEMA REALE APERTO No.1)
(SISTEMA REALE APERTO No.2 )
PA No.1
SCAMBIO
DATI
OSI
ASTRAZIONE
Livello
applicativo
OSI-RM
(Livello No.7)
OSI
PA No.2
ASTRAZIONE
Sottosistema
Aperto
EA1
No.1
SCAMBIO
DATI
EA2
Sottosistema
Aperto
No.2
Ai livelli sottostanti della
pila OSI
Fig.1.2.1
6. Ambiente OSI (OSI Environment). L’ insieme di concetti, funzioni, elementi,
servizi, protocolli etc. definiti dal Modello di Riferimento OSI e relativi standards che
permettono l’interconnessione di sistemi reali aperti.
7. Ambiente locale (Local System Environment, LSE). Rappresentazione
astratta di quella parte del sistema reale che non é coperta dal modello OSI.
Purtroppo nella letteratura specializzata esiste una spiacevole confusione fra
elementi reali e entità astratte o perlomeno non ne viene evidenziata la differenza quando
invece sarebbe necessario farlo. In molte circostanze si notano delle notevoli improprietà
di linguaggio che possono generare confusione. Ad esempio, quando si parla di
«standards OSI applicati all’interconnessione fra sistemi aperti » in effetti ci si riferisce a
standards strutturati secondo OSI-RM che introducono una normativa nelle
interconnessioni di sistemi reali aperti. Altre volte si parla di “entità applicative” come se
fossero degli elementi reali dimenticando invece che sono entità astratte che
modellizzano “processi applicativi” reali, ritenendo solo quegli aspetti di quest’ultimi che
sono rilevanti al modello OSI-RM.
La Fig.1.2.2 illustra in modo schematico i costituenti principali del Modello di
Riferimento OSI. Essendo elementi di un modello astratto, si tratta ovviamente di entità
astratte. Gli elementi sono,
1. Sistemi Aperti
2. Entità Applicative che esistono all’interno di ogni Sistema Aperto.
11
3. Associazioni che interconnettono le Entità Applicative permettendo loro di
scambiare informazione.
Mezzo fisico reale
Sistema aperto (Modello OSI di Sistema reale aperto)
Entita’ Applicativa (Modello OSI di Processo applicativo)
Associazione (fra entita’ applicative in sistemi diversi)
Mezzo fisico reale (non parte del modello)
Fig.1.2.2 Elementi principali del Modello di Riferimento OSI
Mostreremo in seguito che le associazioni fra entita’ applicative si «chiudono»
attraverso il « mezzo fisico » reale che effettivamente interconnette i sistemi
aperti reali (e.g. cavo coassiale, doppino telefonico, fibra ottica) come mostrato
dalle frecce tratteggiate.
In particolare la figura mostra l’interconnessione (“associazione”) fra
entità applicative (entità astratte) come elementi di vari sistemi aperti (entità
astratte). Le entità applicative e i sistemi aperti sono ottenuti rispettivamente dai
processi applicativi (entità reali) e dai sistemi reali aperti ritenendo solo quegli
aspetti che sono rilevanti al modello OSI. Il mezzo fisico OSI fornisce il supporto
per il trasferimento di informazione fra i vari sistemi aperti.
12
1.3 L’architettura stratificata del Modello di
Riferimento OSI-RM.
La creazione del Modello di Riferimento OSI-RM ha utilizzato tecniche
di uso comune nella progettazione dei sistemi software. In particolare, il Modello
di Riferimento OSI-RM ha utilizzato la tecnica «divide et impera» di
SUDDIVIDERE un problema complesso in una serie di sottoproblemi piu’
semplici ma di piu’ facile soluzione e di AGGREGARE poi le soluzioni dei
sottoproblemi (indicandone le mutue relazioni).
Abbiamo gia’ esposto questi concetti nella parte prima del corso. Nel caso
del modello OSI-RM si tratta di suddividere il problema di come scambiare
informazione fra sistemi eterogenei e cooperanti, in una serie di problemi parziali
di più facile soluzione. Nel Modello di Riferimento OSI-RM ogni sistema aperto
(modello astratto OSI di sistema reale aperto) é suddiviso, secondo criteri che tra
poco illustreremo, in sottosistemi ordinati in una architettura gerarchica come
mostrato in Fig.1.3.1.
In Fig. 1.3.1 i sottosistemi sono ordinati in una sequenza verticale che
inizia dal sottosistema più basso (sottosistema No. 1) e finisce al sottosistema più
alto (sottosistema No.7). Un sistema aperto OSI é quindi suddiviso in sette
sottosistemi. Fra poco spiegheremo in cosa consiste il carattere gerarchico
della architettura.
Indicheremo il generico sottosistema come sottosistema (N), dove (N) sta
a rappresentare uno dei seguenti termini:
1) Physical (Fisico)
2) Data Link (Linea)
3) Network (Rete)
4) Transport (Trasporto)
5) Session (Sessione)
6) Presentation (Presentazione)
7) Application (Applicativo)
13
PROCESSO APPLICATIVO
STRATO
Sistema
Aperto A
Sistema
Aperto B
Sistema
Aperto C
Ultimo
N+1
N
N-1
Entità N
Sottosistema (N)
Primo
Mezzo Fisico
.
.
Fig.1.3.1
Ogni sottosistema (N) contiene entità (N). Ogni entità (N) svolge una
molteplicità di attivita’ e.g. 1) svolge funzioni all’interno dello strato (N)
scambiando informazione con pari-entita’(cioe’ le entità (N) residenti negli altri
sistemi aperti) utilizzando un protocollo (N) , 2) fornisce servizi (N) alla
corrispondente entità (N+1) residente nel livelli superiore dello stesso sistema,
quindi, sotto questo aspetto, una entità (N) e’ un fornitore di servizi ad una entità
(N+1) che e’ un utilizzatore di servizi, 3) riceve servizi dalla entità (N-1)
residente nello stesso sistema ma al livello inferiore (N-1)
Un insieme di sottosistemi allo stesso livello (N) costituisce uno strato di
livello N, indicato come strato (N). Notare che ogni sistema aperto ha un solo
sottosistema per strato.
Inoltre il Modello di Riferimento OSI-RM impone che i sottosistemi siano
relazionati l’un l’altro secondo il seguente criterio:
«All’interno di un sistema aperto OSI, ogni sottosistema interagisce
direttamente solo con il sottosistema adiacente sovrastante e il sottosistema
14
adiacente sottostante. La interazione si manifesta sotto forma di «servizi»
forniti da una entità del sottosistema inferiore ad una entità del sottosistema
superiore».
Ovviamente ci sono due casi speciali: il sottosistema aperto No.1 che
manca di un sottosistema inferiore e il sottosistema aperto No.7 che manca di
sottosistema superiore. Questi sottosistemi interfacciano direttamente con i
corrispondenti sottosistemi reali di cui essi sono le rappresentazioni astratte
cioè, rispettivamente, con un mezzo fisico di interconnessione e con un
processo applicativo reale. Ma trattiamo questi casi speciali separatamente.
Il sottosistema N.7, privo di un sottosistema superiore, fornisce ad un
processo applicativo (reale) l’ accesso all’ambiente OSI, cioé fornisce servizi
direttamente al processo applicativo reale. Infatti. il sottosistema No.7 in due
sistemi reali aperti remoti fornisce a due processi applicativi remoti residenti nei
due sistemi accesso a tutti i servizi (forniti dai sette sottosistemi) OSI necessari
per poter cooperare.
Nel sottosistema No.1, privo di un sottosistema inferiore, le entità fisiche
trasmettono e ricevono bits direttamente dal mezzo fisico, il quale fornisce il
supporto necessario al trasporto dei messaggi gestionali fra i sistemi reali aperti.
L’ISO ha fornito una descrizione dettagliata dei sette strati. La descrizione
di ogni strato comprende la definizione dei servizi forniti allo strato superiore e
l’insieme omogeneo di funzioni svolte all’interno dello strato in supporto di
questi servizi. Nel prossimo paragrafo parleremo delle funzioni e servizi di ogni
strato.
I criteri usati per determinare i sette strati del Modello di Riferimento
(chiamati anche “criteri di stratificazione”) sono stati i seguenti:
1) Ogni strato contiene entità che svolgono funzioni che costituiscono un
insieme funzionale omogeneo. Un insieme funzionale omogeneo è un
raggruppamento di funzioni simili per relazione logica cioè tutte le funzioni
nel raggruppamento sono tese alla realizzazione dello stesso obiettivo
(caratteristico del raggruppamento) e utilizzano la stessa tecnologia
realizzativa
2) Ogni insieme di funzioni é “localizzato” nel suo strato di appartenenza
cioé puo’ essere modificato, assieme ai servizi che esso supporta e alle
relative tecnologie, senza influenzare gli strati adiacenti.
3) Per ogni strato esistono solo due interfacce: una sopra e una sotto.
4) I raggruppamenti di funzioni “omogenee” sono effettuati in modo tale
che il modello complessivo abbia un numero di strati accettabile (sembra che
il numero sette sia stato giudicato da ISO come il numero giusto!).
15
Ovviamente tutto ciò ha un carattere convenzionale e altri modelli sono
stati creati con architetture diverse (e.g. l’architettura TCP/IP ha solo quattro
strati)
1.4. L’architettura stratificata OSI-RM: “entità” che
svolgono “funzioni” all’interno di uno strato e
forniscono/utilizzano “servizi” a/da strati adiacenti
Vogliamo ora studiare in più dettaglio alcuni concetti relativi ad una
architettura stratificata OSI-RM, caratterizzata dai seguenti elementi:
1) entità (N),
2) funzione (N),
1) protocollo (N),
2) servizio (N)
5) associazione (N)
6) connessione (N)
dove N sta ad indicare il livello di stratificazione (strato).
16
Tavola 1.3.1 MODELLO di RIFERIMENTO OSI-RM
(Funzioni & Servizi)
•
STRATO APPLICATIVO (7). Le entità applicative di questo strato offrono ai processi applicativi reali un servizio di
accesso all’ambiente OSI i.e. i processi applicativi reali residenti in sistemi reali remoti scambiano dati tramite entità
applicative nel rispetto di protocolli di comunicazione applicativi e.g. entità applicative gestionali, SMAE (System
Management Application Entity) scambiano dati secondo il protocollo CMIP (Common Management Information
Protocol)
•
STRATO di PRESENTAZIONE (6). Si occupa di 1) trasformare il linguaggio usato nello strato applicativo (sintassi locale)
in una rappresentazioni di dati adatta al trasferimento di informazione fra sistemi remoti, 2) rendere disponibile allo strato
applicativo i servizi di sessione ricevuti dallo strato sottostante (strutturazione, sincronizzazione, gestione
dell’interscambio).
•
STRATO di SESSIONE (5). Struttura e sincronizzazione dello scambio dati in modo da poterlo iniziare, sospendere,
riprendere o terminare ordinatamente. Fa, nel dominio del tempo, quello che lo strato di rete fa spazialmente (cioé sessione
vs. connessione).
•
STRATO di TRASPORTO (4). Controllo di deficienze e fluttuazioni della qualità di servizio delle connessioni di rete
(garanzia delle prestazioni richieste) e.g. in una rete internet, TCP opera a livello (4) di trasporto e IP a livello (3) rete.
•
STRATO di RETE (NETWORK LAYER) (3). Funzioni atte a instaurare, mantenere o abbattere le connessioni di rete (e.g.
protocolli orientati alla rete come protocolli di commutazione, indirizzamento e rilevamento in sistemi rappresentativi dei
nodi di rete).
•
STRATO di COLLEGAMENTO (DATA LINK LAYER) (2). Svolge funzioni atte a mitigare malfunzionamenti a livello
di strato fisico e.g. rivelazione e recupero di errori trasmissivi (error control, flow control), controllo di accesso MAC.
•
STRATO FISICO (1). Rappresenta le funzioni svolte da mezzi meccanici, elettrici, funzionali per attivare, mantenere e
disattivare le connessioni fisiche rendendo invisibile allo strato superiore le caratteristiche del mezzo fisico e.g. se cavo
coassiale più fibra ottica lo strato fisico rappresenta la funzione di conversione elettro-ottica. Trasmette a/riceve
dal mezzo fisico i bits scambiati dai sistemi interconnessi. Parametri caratteristici: Tasso d’errore BER (non
17
•
Entita’ (N)
1) Un sottoinsieme (N) é costituito da uno o più elementi attivi, ognuno dei quali,
chiamato entità (N), svolge un insieme di funzioni specifico di quel particolare sottosistema o
strato (insieme funzionale omogeneo). Avevamo già parlato in precedenza di entità
applicative, cioé entità attive nello strato applicativo. In modo analogo parleremo di entità di
Sessione, di Rete, fisiche etc. alludendo a entità attive rispettivamente ai livelli di Sessione, di
Rete, fisico etc.
•
Funzione (N)
2) Una entità (N) é un elemento attivo di un sottosistema (N) che svolge una
molteplicità di funzioni attuando funzionalità in suo possesso ed è capace di fornire/acquisire
funzionalità (servizi) a/da altre entità residenti negli strati adiacenti. Quindi una singola
funzione (N) é una parte dell’attività complessiva di una entità (N) che si svolge all’interno
dello strato (N) e che non e’ visibile dagli strati adiacenti superiore e inferiore. Ad esempio a
livello di rete una entità di rete svolge le funzioni di “ istradamento e rilegamento (routing e
relaying)“, “detezione di errori“, “correzione di errori“, “controllo del flusso di dati“ etc..
Come altro esempio, nel prossimo paragrafo (Vedi Fig.1.5.1) riporteremo le funzioni espletate
dallo strato di presentazione e le confronteremo con i servizi forniti dallo strato di
presentazione allo strato applicativo sovrastante
LIVELLO
(N+1)
Servizio (N) : E(N) offre a E (N+1) il
servizio (N-1) piu’ la capacita’ di
svolgere l’insieme di funzioni IF(N) cioe’
“aggiunge valore” al servizio (N-1).
E
(N+1)
LIVELLO
(N)
E
(N)
LIVELLO
(N-1)
E
(N-1)
Svolge un insieme di funzioni IF(N)
all’interno dello strato (N) dopo
esecuzione di IF(N-1) +IF(N-2)+ ….
+ IF(1).
Servizio (N-1): E (N-1) offre a E(N)
la capacita’ di svolgere l’ insieme di
funzioni IF(N-1) + IF(N-2)+…..IF(1).
Fig 1.4.1 Servizi, funzioni e architettura gerarchica
•
Protocollo (N)
3) La cooperazione fra pari-entità (N) cioè entità (N) residenti allo stesso livello ma in
sistemi diversi avviene con uno scambio di dati strutturati in moduli chiamati Unità Dati
(Data Units) secondo un insieme di regole chiamato protocollo (N). Due pari-entità (N) che
co-operano, cioé entità con attività mutuamente coordinate e.g. attività di Gestore e attività di
18
Agente, usano lo stesso protocollo (N). Si riconosce che il protocollo (N) e’ un protocollo di
comunicazione o protocollo comunicativo fra entità (N) residenti in sistemi diversi. In generale
l’implementazione di un protocollo comunicativo comporta l’utilizzazione di Unità Dati che
contengono dati di controllo (Protocol Control Information, PCI) che, dal punto di vista del
trasporto dati, costituiscono un «carico» aggiuntivo (overhead) oltre al carico utile dei dati
d’utente. (User Data, UD). I dati di controllo svolgono un ruolo di supporto atto a garantire
che lo scambio dei dati d’utente avvenga correttamente.
•
Servizio (N) e struttura gerarchica dell’architettura OSI-RM
4) Un servizio (N) é una “capacità/abilità funzionale” o, semplicemente, “funzionalità”
fornita dalla entità (N) alla entità (N+1) al loro confine logico, chiamato «punto di accesso al
servizio (N)» (N-SAP, N-Service Access Point). (Vedi Fig.1.6.1) . Come già detto un servizio
ha un carattere relazionale cioè implica l’esistenza di fornitori (in questo caso, le entità N) ed
utilizzatori (in questo caso, entità N+1). Ad esempio, una “entità (rete)” a livello 3, fornisce il
servizio di “notifica di errore” a una “entità (trasporto)” a livello 4. Notare la differenza fra il
servizio (rete) “notifica di errore” e le due funzioni (rete) “detezioni di errore” e “correzione
di errore”. Quindi l’attuazione del servizio (rete) rappresenta solo una parte delle attività
svolte da una entità (rete), la quale svolge anche funzioni (rete) all’interno del proprio strato,
non visibili dall’esterno. I servizi (rete) sono invece quelle attività delle entità (rete) che sono
visibili e disponibili all’interfaccia fra i livelli “rete (3)” e “trasporto(4)”.
Una entità (N) può fornire servizi su richiesta di una o più entità (N+1) residenti nello
strato sovrastante. Inoltre, una entità (N) può utilizzare servizi che essa stessa ha richiesto a
una o più entità (N-1) residenti nello strato sottostante.
Quindi in OSI-RM un “servizio (N)”, proprio perché é fornito da entità (N) inferiore a
una entità (N+1) superiore su richiesta di quest’ultima, rappresenta un meccanismo di
collegamento (la colla!) fra i vari sottosistemi in cui era stato suddiviso il sistema iniziale. Al
tempo stesso introduce un ordinamento gerarchico fra i vari stati cioè noi diciamo che “e(N)
fornisce servizi a e(N+1) e riceve servizi da e(N-1)”. Questa gerarchia è mostrata in Fig.1.4.1
La Fig. 1.4.1 mostra come e(N) aggiunga «valore» ai servizi (N-1) ricevuti da e(N-1)
aggiungendo ad essi la capacità/abilità (funzionalità) di svolgere un Insieme di Funzioni a
livello N, denominato IF(N). Tuttavia l’insieme di funzioni IF(N) può svolgersi solo dopo
l’esecuzione di tutte le funzioni contenute negli insiemi IF(N-1) + IF(N-2) +….+ IF(1)
svolte negli strati sottostanti. Questa e’ la natura della gerarchia di OSI-RM: si tratta di una
gerarchia di propedeuticità dal basso verso l’alto.
Le funzioni svolte dalle entità (N) residenti nei vari strati sono riportate nella Tavola
1.3.1.
•
Associazione (N)
19
5) Una associazione (N) é una relazione co-operativa fra entità (N). Per co-operare, le
entità (N) si accordano sull’uso dello stesso protocollo (N) e comunicano fra loro tramite i
servizi forniti dallo strato sottostante (N-1). I servizi dello strato (N-1) sono supportati dalle
funzioni svolte dalle entità (N-1) e, se necessario, da servizi disponibili provenienti dallo strato
(N-2). Ad esempio le entità applicative (7) comunicano tra loro tramite i servizi forniti dalle
entità residenti nello strato 6 sottostante. Per lo strato fisico, che non ha uno strato OSI
sottostante, le entità fisiche comunicano direttamente fra loro attraverso il mezzo fisico.
•
Connessione (N)
6) Una connessione (N) é una associazione fra pari-entità (N) (entità allo stesso livello)
effettuata su richiesta di una entità (N+1) al fine di stabilire una associazione (N+1) con un
altra pari entità (N+1) residente in un altro sistema.
1.5
Esempio: Servizi e funzioni nello strato di presentazione.
(Strato No. 6)
La Fig. 1.5.1 illustra un esempio di come le funzioni svolte all’interno dello strato di
presentazione (livello No.6) supportino i servizi forniti dallo strato di presentazione allo strato
applicativo superiore (livello No.7). Questo esempio e’ rilevante a quanto verrà detto in
seguito a proposito degli aspetti comunicativi del modello OSI-SM.
In questa figura le entità applicative sono responsabili della scelta di una sintassi
astratta di alto livello da utilizzare nelle loro comunicazioni. Lo strato (inferiore) di
presentazione viene informato di questa scelta, effettua la scelta di una sintassi di
trasferimento per lo scambio di dati fra entità di presentazione, si assicura che sia
mutuamente accettabile dalle entità di presentazione tramite negoziazione, traduce la sintassi
astratta di alto livello in sintassi di trasferimento e utilizza la sintassi di trasferimento nello
scambio dati fra entità di presentazione. In tutto questo, lo strato di presentazione si assicura
che l’informazione scambiata fra entità applicative sia mantenuta integra in quantità e qualità
durante il trasferimento dati.
In Fig.1.5.1, rilevante al caso particolare di un modello gestionale OSI-SM, due entità
applicative cooperanti utilizzano una sintassi astratta di alto livello chiamata ASN.1 (Abstract
Synthax Notation 1) per comunicare fra di loro. Tuttavia la comunicazione fra i due sistemi
interconnessi avviene in pratica attraverso una sequenza temporale di bits cioé zero e uno.
Serve quindi un meccanismo capace di implementare le seguenti funzionalità: 1) mappare la
rappresentazione ASN.1 effettuata dall’entità applicativa trasmittente in una rappresentazione a
livello di bits, 2) trasmettere i bits all’interno dello strato di presentazione (e.g. scegliendo
come sintassi di trasferimento comune la sintassi BER, Bit Encoding Rules ) e 3)
trasformare i bits ricevuti in linguaggio ANS.1 pronto per l’entità applicativa ricevente. Alcune
di queste funzionalità vengono svolte all’interno dello strato di presentazione (freccia
orizzontale inferiore), altre vengono fornite dal livello di presentazione al livello applicativo
sottoforma di servizi (frecce verticali).
20
LIVELLO APPLICATIVO
Entità
Appl.
No.1.
ASN.1
Entità di
Pres. No.1
BER
Entità
Appl.
No.2
Entità di
Pres. No.2
LIVELLO DI PRESENTAZIONE
Fig.1.5.1 Sintassi astratta ANS.1 a livello applicativo trasformata in una sintassi di
trasferimento BER a livello di presentazione. (Modello OSI-SM).
1.6. La rappresentazione del Modello di Riferimento OSI-RM in
termini di “unità dati” PDU e SDU.
Abbiamo visto come nel modello OSI-RM lo svolgimento di funzioni all’interno di uno
strato e/o la fornitura di servizi da uno strato inferire ad uno strato superiore avvenga tramite lo
scambio di dati fra entità. Lo scambio di dati può avvenire orizzontalmente fra pari-entità in
sistemi diversi (frecce orizzontali in Fig.1.5.1) o verticalmente fra entità in strati adiacenti
dello stesso sistema (frecce verticali in Fig.1.5.1).
In entrambi i casi, lo scambio di dati e’ strutturato in unità modulari o Unita’ Dati
(Data Units).
Si definisce Unità PDU(N) (Protocol Data Unit N) una unità dati specificata secondo
il protocollo (N).
D’altra parte abbiamo visto che un protocollo (N) comporta dati di controllo e dati di
utente. Entrambi questi tipi di dati sono contenuti in una PDU(N). Infatti una PDU(N) ha a sua
volta una struttura interna costituita da due altri moduli (Vedi Fig.1.6.1): un modulo PCI (N)
21
(Protocol Control Information N) relativo ai dati di controllo e un modulo UD (N) (User Data
N) relativo ai dati di utente.
Si definisce Unita’ Dati di Controllo o Unita’ PCI (N) (Protocol Control Information
N) l’unità dati scambiata fra due entità (N) per coordinare le loro operazioni cioé per far si che
esse possano co-operare e per garantire che i dati d’utente vengano scambiati correttamente. Il
trasferimento di PCI (N) fra le due entità (N) avviene all’interno di una PDU(N) tramite un
servizio (N-1) fornito dallo strato inferiore (vedi dopo).
Si definisce Unita’ Dati d’Utente o Unita’ UD (N) (User Data N) l’insieme dei dati
trasferiti fra le entità (N) per conto delle entità (N+1), alle quali le entità (N) stanno fornendo
servizi. Il trasferimento di dati fra due entità (N) avviene tramite un servizio (N-1) fornito dallo
strato inferiore.
Si definisce Unita’ Dati del Servizio (N) o Unita’ SDU (N) (Service Data Unit N) una
unita’ dati ottenuta come risultato dei servizi (N) forniti da entita’ (N) a entita’ (N+1), la cui
identità é preservata da un estremo all’altro di una connessione . La SDU(N) e’ il risultato di
un servizio (N) effettuato sui dati trasmessi da una entita’ (N+1) ad una entita’ (N) al fine di
trasferirli, tramite una connessione, alla pari entita’ (N+1). Nella Fig. 1.6.1 la SDU(N) e’
ottenuta nel modo più semplice possibile cioè il servizio (N) effettua una mappatura uno-a-uno
fra unità dati (N+1) e unità dati (N) senza effettuare operazioni di segmentazione o
assemblaggio di unità dati PDU(N+1). Quindi il servizio (N) consiste nel prendere una
PD(N+1) e farla diventare il carico utile in una PDU(N)
In particolare, la Fig.1.6.1 illustra bene il concetto di servizio fornito da entita’ N a
entita’ N+1 utilizzando le unità dati PDU(N), PDN(N+1) e SDU(N). La SDU(N) é il risultato
del servizio (N) che opera sulla PDU (N+1) fornita dalla entita’ (N+1) alla entita’ (N) al
confine logico di separazione fra le due entita’ SAP(N). Per capire meglio facciamo
riferimento al precedente paragrafo 1.5. In questo caso lo strato di presentazione trasforma una
unita’ dati a livello applicativo, PDU(A), espressa in linguaggio astratto ASN.1 in una SDU
espressa in ottetti di bits senza alterarne il contenuto informativo. La nuova unità dati risultato
del servizio di presentazione é la SDU(P) cioe’ la SDU a livello presentazione.
La figura 1.6.1 mostra come la SDU(N) costituisca il carico utile UD(N) a bordo di una
PDU(N) che contiene una Unita’ Dati Controllo PCI(N).
Le frecce nere verticali al di sotto delle entita’ (N) stanno ad indicare che il
trasferimento di dati fra entità (N) nello strato (N) avviene utilizzando i servizi di tutti gli strati
sottostanti allo strato (N) secondo un processo iterativo.
Il processo iterativo deriva dal fatto che due entità (N+1) scambiano PDU(N+1) grazie
a servizi (N) ed al trasporto dati fra entità (N) nello strato (N) sottostante. A loro volta le entità
(N) nello strato (N) scambiano dati fra di loro tramite i servizi forniti da entità (N-1) residenti
nello strato sottostante e cosi’ via fino allo strato fisico. Nello strato fisico, poiché non esiste
uno strato sottostante, le entità fisiche comunicano direttamente fra di loro utilizzando il mezzo
fisico.
22
Altrimenti detto, i dati contenuti nella PDU(N+1) viaggiano a bordo delle PDU(N), i
cui dati viaggiano a bordo delle PDU(N-1), i cui dati viaggiano a bordo delle PDU(N-2) e cosi’
via fino allo strato fisico. Tutto ciò e’ mostrato nella Fig. 1.6.2.
In questa figura le PCI(N) sono rappresentate con la lettera T (iniziale di «Testata»). Il
secondo livello (livello di linea) oltre alla testata T6 aggiunge al messaggio anche due code
costituite dagli elementi BS (Bit di Sincronizzazione) e FCS (Frame Check Sequence) per il
controllo degli errori che avvengono durante la trasmissione. Al livello piu’ basso (livello
fisico) non vengono aggiunte ulteriori testate. A questo livello la Fig. .1.6.2 mostra la trama
OSI-RM come si vede nel dominio del tempo, rispettivamente all’uscita del sistema
trasmettitore e all’entrata del sistema ricevitore. Notare la quantità di dati aggiuntivi
(«overhead», in inglese), oltre ai dati d’utilizzatore (UD), presenti in una trama OSI-RM.
Questo e’ il prezzo che si deve pagare per avere la flessibilità dei servizi offerti dal modello di
riferimento OSI-RM!
23
SISTEMA A
SISTEMA B
E(N+1)
E(N+1)
PDU (N+1)
PDU (N+1)
Servizio (N)
SAP(N)
MAPPING
PCI(N)
PCI(N)
SDU(N)
UD(N)
PDU(N)
E(N)
MAPPING
SDU(N)
PCI(N)
UD(N)
PDU(N)
E(N)
Connessione
Servizio (N-1)
LIVELLO (N-1)
Fig. 1.6.1 Il trasferimento di informazione fra pari entità avviene con l’intervento degli strati
inferiori.
24
UTILIZZATORE A
UD
UTILIZZATORE B
UD
T1 UD
7. APPLICATIVO
6. PRESENTAZIONE
T2
5. SESSIONE
T3
4. TRASPORTO
3. RETE
T4
T5
2. LINEA
BS
T6 T5 T4 T3 T2 T1 UD FCS
BS
BS
T6 T5 T4 T3 T2 T1 UD FCS
BS
1. FISICO
BS
T6 T5 T4 T3 T2 T1 UD FCS
BS
BS
T6 T5 T4 T3 T2 T1 UD FCS
BS
Tempo Trasmis.
Fig.1.6.2
Tempo Ric.
Mezzo Fisico (Linea di Trasmissione)
25
1.7
Il Modello di Riferimento OSI-RM specializzato alla gestione dei
sistemi TLC: “gestione di sistema” (OSI-SM), “gestione di strato” e
“operazione di strato”
Avevamo precedentemente indicato come il Modello di Riferimento OSI (OSI-RM) fosse del
tutto generico cioè si potesse applicare all’interscambio di informazione fra sistemi del tutto generici
ma potesse essere utilmente specializzato al caso in cui i sistemi fossero sistemi specifici dedicati alla
gestione di sistemi TLC (sistemi gestionali).
Infatti, come mostrato in Fig.1.7.1, il modello di riferimento OSI-RM puo’ essere utilizzato per
rappresentare uno scambio di messaggi gestionali fra due entità applicative residenti nelle due
componenti di un sistema gestionale composito: una entità applicativa residente in un “sistema
gestore” aperto e una entità applicativa residente in un “sistema gestito” aperto. Il sistema gestito
contiene anche un archivio di “oggetti gestiti”, rappresentazioni astratte di risorse reali gestite, non
mostrato in figura (Vedi Cap.2). La Fig.1.7.1 mostra schematicamente un modello chiamato “modello
OSI per la gestione di sistema” (OSI-SM, System Management).
Vedremo che il modello gestionale OSI-SM è uno standard gestionale costituito da 1) protocolli
comunicativi i.e. la struttura dei messaggi gestionali (Protocollo CMIP, Common Management
Information Protocol), 2) servizi forniti ad un utilizzatore esterno del sistema gestionale (Servizi CMIS,
Common Management Information Services) e 3) linguaggio di rappresentazione degli oggetti gestiti
(linguaggio GDMO/ASN.1) contenuti nel sistema gestito e tecniche di denominazione (Vedi par.2.8).
Livello
SISTEMA
APERTO
GESTORE
(A)
Protocollo per la gestione
di sistema
SISTEMA
APERTO
GESTITO
(B)
SMAE
Applicativo
Presentazione
Sessione
Trasporto
Rete
Linea
Fisico
Mezzo Fisico OSI
Fig1.7.1 Modello OSI per la gestione di sistema. Lo scambio di informazione
gestionale avviene fra SMAE con protocolli gestionali del settimo livello ed e’
supportato dai servizi di tutti gli strati inferiori.
La Fig. 1.7.1 mostra come, nella “gestione di sistema” OSI, (OSI-SM) i messaggi gestionali
siano strutturati secondo protocolli residenti nel livello più alto della pila OSI (strato No.7) e siano
scambiati fra entità applicative giustamente chiamate Entità Applicative per la Gestione di Sistema
(SMAE, System Management Application Entity) residenti nel sistema gestore A (SMAE-Gestore) e
nel corrispondente sistema gestito B (SMAE-Agente). Questo significa che in OSI-SM lo scambio di
26
messaggi gestionali fra SMAE avviene con procedure che sfruttano le funzionalità di tutti e sei gli strati
OSI sottostanti (detezione/correzione di errore, segmentazione, etc.) e, in particolare, sfruttando i
servizi di encoding/decoding del linguaggio ASN.1 offerti dallo strato di presentazione (strato No.6).
Lo scambio di messaggi gestionali a livello No.7 avviene anche se la risorsa gestita, e.g. un elemento di
rete, nella sua fase operativa svolge funzioni primarie a livelli OSI inferiori e.g. una rete LAN o uno
switch (livello 2) o un router (livello 3). Ad esempio, nella “gestione di sistema” (System
Management), un router opera a livello 3 ma è gestito a livello applicativo (livello 7).
Nel caso di gestione di una risorsa attiva in uno strato (N) inferiore al settimo si può pensare di
effettuare lo scambio di messaggi gestionali Gestore-Agente non a livello applicativo, come nella
“gestione di sistema”, ma con protocolli gestionali meno “potenti” residenti al livello (N). In tal caso si
sfruttano solo le funzionalità di tutti i livelli sottostanti questo livello (da N-1 a 1). Questo tipo di
gestione è chiamata “gestione di strato” (Layer Management). Ad esempio esistono protocolli
gestionali per la distribuzione di tavole di routing (routing tables) fra tutti i routers ubicati in un certo
dominio amministrativo utilizzando protocolli gestionali residenti nello strato OSI No.3, supportati solo
dalle funzionalità del primo e secondo strato.
Oltre alla “gestione di sistema”, basata su protocolli gestionali specializzati per il livello
applicativo, e la “gestione di strato (N)”, basata su protocolli specializzati per il livello (N), il modello
OSI-RM ha previsto una terza possibilità per lo scambio di informazione gestionale fra un sistema
aperto gestore e un sistema aperto gestito: la “operazione di strato” (Layer Operation). La
“operazione di strato” è simile alla gestione di strato con la differenza che l’informazione gestionale
viene scambiata ad un certo livello (N) utilizzando i protocolli comunicativi generici senza
sviluppo/utilizzazione di particolari protocolli gestionali.
1.8 Modello OSI-SM per la gestione di sistema e i suoi quattro
sottomodelli.
Basandosi sul modello di riferimento OSI, l’ISO effettuo’ studi sulla gestione dei sistemi di
telecomununicazione e trasmissione dati. I risultati furono pubblicati nel 1989 in un documento
intitolato:
ISO 7498 – 4: “Information Processing Systems – Open System Interconnection – Basic
Reference Model – Part 4: Management Framework”, Geneva, 1989 ( Pubblicato anche come
ITU-T Recommendation X.700)
L’informazione contenuta nel documento X.700 non fu giudicata sufficiente per sviluppare
uno standard di vasta applicabilità ma costituì una base per ulteriori studi tesi al raggiungimento di
questo scopo.
Il Modello OSI-SM (System Mangement Overview, X701)
Nel 1992 l’ISO decise di produrre “raccomandazioni/standard internazionali” più precisi e
publicarli nel documento:
27
ISO 10040: “Information Processing Systems – Open System Interconnection – System
Management Overview”, Geneva, 1992 (L’ultima versione é stata pubblicata nel 8/1997 come
ITU-T Recommendation X.701)
Le raccomandazioni contenute in questo documento, assieme ad altri standards che
individueremo fra poco, costituiscono la base di un modello gestionale di sistema chiamato il Modello
OSI-SM che si articola in quattro sottomodelli (chiamati «modelli» in letteratura) descritti nei prossimi
capitoli 3, 4, 5 e 6. I sottomodelli sono (Tav.1.8.1):
1)
MODELLO ORGANIZZATIVO. (Documento ITU-T X.701) Architettura della
gestione OSI-SM caratterizzata da un sistema aperto che riveste il ruolo di Gestore il
quale scambia a livello applicativo informazione gestionale con un sistema aperto che
riveste il ruolo di Agente.
2)
MODELLO COMUNICATIVO (Documenti ITU-T della serie X.710). Servizi e
protocolli a livello applicativo. Standards che si riferiscono al trasporto
dell’informazione gestionale scambiata a livello applicativo fra Gestore e Agente.
3)
MODELLO INFORMATIVO. Struttura della informazione gestionale. (Vedere
documenti della serie X.720). Sono standards relativi al Modello informativo OSI-SM
cioè standards che definiscono la struttura della Management Information Base (base
MIB) e le metodologie per denominare (albero dei nomi) e descrivere (linguaggio
GDMO/ASN.1) gli oggetti gestiti in essa contenuti
4)
MODELLO FUNZIONALE. Descrizione delle «funzioni per la gestione di sistema,
System Management Functions, SMF’s)» (Vedere la lista dei documenti ITU-T della
serie X.730-751 riportati nel Cap.6)
In fig.1.8.1 sono mostrati i tre sottomodelli in relazione al paradigma Gestore-Agente.
28
Tavola 1.8.1 Il Modello gestionale OSI-SM (System Management)
Il Modello OSI-SM si suddivide in quattro sottomodelli:
1. Modello organizzativo ( Architettura gestionale “Gestore/Agente”)
2. Modello informativo ( Denominazione degli oggetti gestiti, relazioni fra oggetti e.g.
ereditarietà e contenimento, linguaggio di rappresentazione degli oggetti e.g. maschere GDMO
e sintassi ASN.1)
3. Modello comunicativo ( SMAE e elementi di servizio ACSE, ROSE, CMISE, SMASE,
protocollo comunicativo CMIP)
4. Modello funzionale ( FCAPS)
29
Modello
Organizzativo
Sist. Aperto A
Ruolo Gestore
Sist. Aperto B
Ruolo Agente
Funzioni
di
Gestione MIB
Funzioni
di
MIB Gestione
Modello
Funzionale
Modello
Comunicativo
Modello
Informativo
Fig.1.8.1
1.9 Esercizi
1. Spiegare il significato delle tre iniziali O, S, I nella parola OSI
2. Cosa é un «Modello di Riferimento» OSI? Quale e’ la differenza fra il Modello di
Riferimento OSI (OSI-RM) e uno standard OSI? Quali sono gli scopi che si prefigge di
raggiungere il modello OSI-RM ?
3. Il modello OSI-RM non e’ un modello gestionale. Cosa significa questa frase e
perche’,allora, studiamo questo modello in un corso di « Gestione dei Sistemi TLC » ?
4. Spiegare la relazione fra i modelli OSI-RM (OSI-Reference Model) e OSI-SM (OSISystem Management).
5. In un contesto OSI come viene definito un «sistema reale» ?
30
6. Che differenza c’é fra la definizione dell’esercizio No.5 e la definizione da noi fornita per
un sistema TLC «osservato» dai tre punti di vista business, servizi e reti?
7. Si faccia riferimento alla definizione di «sistema reale OSI ». Puo’ un terminale d’utente
essere considerato un «sistema reale» o invece deve essere considerato un elemento di un
sistema reale?
8. In un contesto OSI cosa é un sistema reale «aperto» ?
9. Cosa é un « processo applicativo » nel modello OSI-RM? Una Persona TLC che opera in
un terminale per transazioni bancarie é forse un «processo applicativo» ?
10. Una entita’ applicativa OSI-RM è una rappresentazione astratta di un processo
applicativo OSI-RM. Spiegare.
11. Cosa significa che una entità applicativa ubicata nel livello No.7 della architettura
stratificata OSI («pila OSI») interfaccia direttamente con un processo applicativo
reale ubicato al di fuori dell’architettura stessa? (Suggerimento: l’entita’ applicativa
fornisce un servizio al processo applicativo; di che servizio si tratta?)
12. Cosa significa che due entità fisiche ubicate nello strato fisico (No.1) della «pila OSI»
stabiliscono una associazione attraverso un mezzo fisico reale ubicato al di fuori del
modello OSI-RM?
13. Nella pila OSI dove risiedono le entità applicative e quali attivita’ svolgono? Possono
comunicare fra di loro?
14. Nel modello OSI a sette strati cosa é uno strato ? Fare l’elenco dei sette strati.
15. Perché gli strati nella pila OSI sono in numero di sette ? Potrebbero essere otto o sei?
Quali sono i criteri adottati per definire i sette strati ?
16. Che relazione c’é fra strato (N), sottosistema (N) e entità (N)?
17. All’interno dello strato (N) una entità (N) svolge funzioni (N) e comunica con pari entità
tramite un protocollo (N) mentre fornisce servizi (N) alle entità (N+1) che risiedono nello
strato superiore (N+1) e utilizza servizi (N-1) forniti dalle entità (N-1) residenti nello
strato inferiore (N-1). Illustrare tutto cio’ graficamente.
18. Cosa significa che i sette strati costituiscono una struttura « gerarchica » ? Quale é la
«colla» che tiene uniti i sette strati ?
19. Spiegare quali sono i servizi forniti dalle entità di presentazione alle entità applicative nel
caso in cui le entita’ applicative comunicano con un protocollo basato su una sintassi
astratta di alto livello.
20. Cosa é una associazione (N) ? Che differenza/relazione c’é fra associazione (N) e
connessione (N)?
31
21. Spiegare la seguente frase « Una entità applicativa per comunicare con una pari entità
utilizza tutti gli strati della pila OSI». Potrebbe questa comunicazione avvenire
utilizzando solo quattro strati opportunamente scelti invece che tutti gli strati?
22. Cosa sono le unità dati PDU(N) (Protocol Data Unit) e SDU (N) (Service Data Unit) ?
Come vengono sfruttate le unità dati in una associazione fra pari entità (N+1)?
23. Una PDU(N) é costituita da due parti. Quali sono queste parti e a che cosa servono. Fare
un disegno che illustra la relazione fra le seguenti quantità: PDU(N+1), SDU(N),
PDU(N) e SDU(N-1).
24. Cosa é il Modello OSI-SM ? Quali sono le quattro architetture introdotte dall’ISO per
definire il modello OSI-SM ?
25. Esiste una relazione fra il modello di riferimento OSI-RM e il modello OSI-SM ?
32
CAPITOLO 2
Modello OSI-SM per la gestione di
sistema: (sotto)modello organizzativo
2.1 Aspetti organizzativi del Modello OSI-SM: il paradigma
di gestione «Gestore-Agente».
Il Modello OSI-SM per la gestione di sistema è stato introdotto dall’ITU-T come
una specializzazione del modello di riferimento OSI-RM al caso in cui l’ applicazione
residente al livello applicativo è di natura gestionale cioè serve a gestire le risorse di un
sistema TLC. In questo capitolo vedremo che l’applicazione gestionale è suddivisa in due
componenti: una componente “Gestore” e una componente “Agente”. Per questo si dice
anche che il modello OSI-SM adotta il “paradigma Gestore-Agente”
Il Modello OSI-SM, per descrivere le operazioni gestionali sulle risorse reali, usa
una rappresentazione astratta delle risorse stesse cioè le risorse gestite sono «viste» da un
Gestore come «oggetti gestiti» (managed objects) con caratteristiche «astratte» dalle
caratteristiche delle risorse reali Gli oggetti gestiti sono formalmente definiti e
mutuamente relazionati secondo il “formalismo dell’orientamento agli oggetti”, ben
noto nella programmazione con linguaggi di alto livello (e.g. C++).
I concetti fondamentali alla base del Modello OSI-SM sono descritti nel
documento ITU-T X.701 «Information Technology-Open Systems InterconnectionSystems Management Overview» (8/97). In questo documento sono trattati gli aspetti
organizzativo, informativo, comunicativo e funzionale del Modello OSI-SM.
Nella prima parte di questo capitolo ci occuperemo degli aspetti organizzativi
(sottomodello organizzativo).
•
La gestione OSI-SM: SMAE Gestore e SMAE Agente (Fig.2.1.1)
Il «sottomodello organizzativo» del Modello OSI-SM descrive la architettura del
modello gestionale OSI-SM cioé descrive le relazioni fra le entità che svolgono attività
gestionali. Le attività gestionali sono effettuate stabilendo “associazioni” fra “entità
applicative” residenti in due sistemi gestionali remoti interconnessi da una rete di
comunicazione dati.
Nel modello OSI-SM le entità applicative sono chiamate «Entità Applicative per
la Gestione di Sistema» o SMAE’s (Systems Management Application Entities) e
possono giocare ruoli diversi e.g. ruolo Gestore e/o ruolo Agente. Una associazione fra
due entità applicative avviene fra una SMAE Gestore e una SMAE Agente. Ricordiamo
33
che, come già detto, le entità applicative SMAE sono le rappresentazioni astratte di
processi reali chiamati Processi Applicativi per la gestione di sistema (SMAP, System
Management Application Process) e un “processo applicativo reale” (manuale o
computerizzato) e’ un insieme di risorse in un
Fig.2.1.1 MODELLO ORGANIZZATIVO OSI-SM
SISTEMA DI GESTIONE (TMN)
Sistema Gestore
Sistema Gestito
PROTOCOLLO
CMIP
G
E
S
T
O
R
E
OPER.
NOTIFICA
EVENTO
MIB
A
G
E
N
T
E
S
I
S
T
E
M
A
OPER.
NOTIF.
T
L
C
Astrazione
OGGETTI
GESTITI
RISORSE
GESTITE
PdS
Sistema Aperto reale, utilizzato per implementare una particolare applicazione
(gestionale).
Infatti il modello OSI-SM prevede che la gestione di un sistema TLC sia basata su
lo schema di Fig.2.1.1 dove è mostrato come un sistema di gestione di un sistema TLC
sia suddiviso in due (sotto)sistemi aperti interconnessi da una rete di comunicazione dati
che interagiscono scambiandosi informazione gestionale: il Sistema Aperto Gestore e il
Sistema Aperto Gestito. I due sistemi contengono SMAE’s rispettivamente chiamate
« SMAE Gestore » e « SMAE Agente » o anche semplicemente «Gestore» e
«Agente». Sulla destra di Fig.2.1.1 sono anche rappresentate, sottoforma di stelle, le
risorse reali del sistema TLC da gestire assieme ai loro modelli astratti, chiamati
«oggetti gestiti», immagazzinati in una base dati chiamata MIB (Management
Information Base) gestita dalla SMAE Agente.
34
ATTENZIONE! Notare che talvolta in letteratura tutto il sistema gestito,
costituito da SMAE Agente + MIB e’ chiamato « sistema Agente » o « applicazione
Agente ». In tal caso la MIB fa parte del sistema Agente o della applicazione Agente. Nel
nostro corso noi diremo che un sistema gestito contiene una SMAE Agente (o
semplicemente un Agente) più, separatamente una base dati MIB.
I sistemi aperti sono stati già definiti nel precedente capitolo. Ricordiamo che
l’espressione «sistemi aperti» significa che i sistemi si scambiano informazione
gestionale con regole e formati (protocolli) a norma OSI. Questi protocolli verranno
studiati in dettaglio quando ci occuperemo dell’aspetto comunicativo del Modello OSISM.
2.2 Lo scambio di informazione gestionale fra Sistema
Gestore e Sistema Gestito : operazioni gestionali e notifiche di
evento
Nel Modello OSI-SM l’interazione fra il sistema aperto Gestore e il sistema
aperto Agente ha una rappresentazione astratta in termini di 1) operazioni (management
operations), le cui richieste sono emesse dal Gestore, e 2) notifiche di evento (event
reports) occorsi negli oggetti gestiti, emesse autonomamente dall’Agente senza alcuna
sollecitazione da parte del Gestore. Piu’ precisamente l’interazione Gestore-Agente può
avvenire come segue:
OPERAZIONI (originate dal Gestore)
La SMAE Gestore può realizzare diverse funzioni di gestione appartenenti alle
diverse aree gestionali FCAPS sottoforma di una serie di funzioni CMIS
(Common Management Information Services) (vedi dopo). La SMAE Gestore
inizia col processare i dati che egli ha richiesto e ricevuto dalla SMAE Agente
dopo aver stabilito con essa una associazione (dati dinamici ricevuti a “run time”
e.g. nome di oggetto target, che egli aggiunge a dati statici a priori in suo possesso
). Sulla base del risultato di questo processo egli decide di inviare alla SMAE
Agente richieste di operazioni gestionali da effettuare sugli oggetti gestiti
target, indirizza queste richieste alla SMAE Agente e riceve le risposte dalla
SMAE Agente con i risultati delle operazioni, una volta che quest’ultime siano
state completate. Ricordare che nella gestione di elementi di rete (stampanti,
computers, servers, switches, routers etc.) interconnessi da una rete, il Gestore
può risiedere in una Stazione di Gestione (Network Management Station)
rappresentata da un host computer (computer connesso in rete) che contiene le
applicazioni FCAPS (funzioni di gestione). Altrimenti il Gestore può essere
suddiviso in «Componenti Gestore» residenti in più stazioni di gestione
interconnesse in una struttura gerarchica del tipo MoM, Manager of Managers o
una struttura di cooperazione (Vedi prima parte).
La SMAE Agente, all’interno del Sistema Gestito (o Sistema Agente), riceve le
richieste emesse dal Gestore, le accetta/respinge (e.g. verifica se le operazioni
richieste dal Gestore si possono effettuare sugli oggetti prescelti) cioè svolge un
35
ruolo di controllo di accesso alla MIB e poi esegue le richieste (e.g. legge il
valore di un certo parametro gestionale immagazzinato nella MIB). I risultati
ottenuti a fine esecuzione operazioni vengono inviati al Gestore che ne ha fatto
richiesta. In generale una molteplicità di Agenti è controllata da uno o più Gestori
e gli Agenti risiedono in prossimità degli elementi gestiti. Nell’esempio
precedente gli Agenti possono risiedere nelle stampanti, computers e servers
assieme alle loro MIB’s. Quindi un Gestore può comunicare con una molteplicità
di Agenti mentre un Agente può riportare informazione gestionale a più Gestori.
In ogni caso il numero di Agenti e’ molto più alto del numero di Gestori.
NOTIFICHE di EVENTO (originate dall’Agente)
L’ Agente invia al Gestore notifiche di evento relative ad eventi che si
verificano nelle risorse gestite senza che alcuna richiesta venga effettuata dal
Gestore. Il Gestore può rispondere alle notifiche di evento se lo ritiene opportuno.
Quindi adotteremo la seguente definizione: una « notifica » (notification) é
l’emissione spontanea di informazione da parte di un oggetto gestito ad un
Agente per segnalare un evento. Questa notifica e’ inoltrata dall’Agente al
Gestore sottoforma di « notifica di evento » (event report).
GESTORE
AGENTE
Interfaccia
SISTEMA
GESTORE
Utilizzatore
del sistema di
gestione
Funzione
Principale nel
Sistema Gestito
G
E
S
T
O
R
E
AGENTE MIB
MIB –
RIS. GEST.
SISTEMA GESTITO
A
G
E
N
T
E
M
I
B
R
I
S
O
R
S
E
G
E
S
T
I
T
E
COMUNICAZIONE
GESTIONE
ADATTAMENTO
Fig. 2.3.1 Le tre interfacce del sistema gestito
36
2.3
Le tre interfacce del sistema gestito : Gestore -Agente,
Agente –MIB, MIB - risorse gestite. (Fig.2.3.1)
Facciamo riferimento alla Fig. 2.3.1. Il sistema gestito ha due interfacce esterne:
una verso il Gestore e una verso le risorse reali gestite. Inoltre esiste una interfaccia
interna fra Agente e gli oggetti gestiti immagazzinati nella MIB. Il modello OSI-SM
standardizza l’interfaccia esterna Gestore-Agente ma non le altre due interfacce
Agente - MIB e MIB - risorse reali gestite. Le modalità con cui l’Agente interfaccia
con la MIB sono considerate un problema «locale» e non sono modellizzate dal modello
OSI e, quindi, non sono oggetto di standardizzazione. Analogamente le interazioni fra
MIB e risorse reali gestite sono al di fuori del modello OSI e, anche in questo caso, si
tratta di un problema «locale» la cui soluzione non deve soddisfare norme standardizzate.
Dire che il problema è « locale » non significa dire che il problema sia di poca o minore
importanza rispetto al problema dell’interscambio di informazione gestionale GestoreAgente. « Locale » significa solo « non a norma OSI ». Si deve quindi riconoscere che
le due interfacce non standardizzate Agente - MIB e MIB - risorse gestite presentano
importanti problemi che devono essere risolti dallo sviluppatore dell’applicazione
gestionale relativa al «Sistema Gestito» ma senza sottostare a norme OSI.
Interfaccia « Gestore – Agente ». Nel Capitolo 4 vedremo che per
l’interscambio di informazione gestionale Gestore-Agente il modello OSI-SM
prevede l’uso di un protocollo comunicativo standardizzato chiamato CMIP
(Common Management Information Protocol) associato all’ ”Elemento di
Servizio” CMISE (Common Management Information Service Element) che,
come vedremo nel Cap.4, è uno dei moduli in cui sono suddivise le SMAE
Gestore e Agente. Il protocollo CMIP stabilisce un format standardizzato per lo
scambio di informazionme gestionale al livello applicativo della pila OSI
sottoforma di PDU’s (Protocol Data Units). Come gia’ visto, nel modello OSI
tutti gli altri sei strati della pila OSI partecipano al trasferimento di informazione
fra Gestrore e Agente.
Interfaccia « Agente – MIB ». Questa interfaccia supporta lo scambio di
informazione gestionale relativa alla gestione della MIB da parte dell’Agente.
L’Agente, come minimo, deve essere capace di effettuare le seguenti operazioni
sugli oggetti gestiti indicati dal Gestore come oggetti target:
1. L’Agente verifica che le operazioni richieste dal Gestore siano
«legali» (e che quindi possano essere accettate) cioè siano incluse fra
le «caratteristiche» specificate per la classe di oggetti gestiti a cui
appartiene l’oggetto target. Le caratteristiche di un oggetto gestito (e
di tutti gli oggetti appartenenti ad una classe) rappresentano proprietà
specifiche del suo stato e del suo comportamento e verranno studiate
nel prossimo capitolo (sottomodello informativo)
2. L’Agente individua la locazione in MIB di un oggetto target sulla
base del suo nome, (chiamato DN, Distinguished Name). Il nome
37
dell’oggetto target è incluso nel messaggio inviato da un Gestore ad
un Agente.
3. Ricevuta una richiesta di operazione da parte del Gestore (e.g. leggi/
scrivi un valore di un attributo di un oggetto gestito, crea/distruggi un
oggetto gestito), l’Agente esegue l’operazione. Inoltre, in maniera del
tutto autonoma, l’Agente deve essere capace di inviare al Gestore una
«notifica di evento» a seguito della ricezione di una segnalazione da
parte di un oggetto gestito contenuto MIB, di un evento speciale (in
genere un evento anomalo e.g. il superamento di un valore di soglia da
parte del valore di una caratteristica di un oggetto gestito o il
verificarsi di un guasto).
4. L’Agente e’ capace di processare opportunamente le segnalazioni di
un evento originate da uno o piu’ oggetti gestiti e stabilire dove (i.e. a
quali Gestori) e come inviarle (i.e. sotto quale forma di «event report»
o «notifica di evento»). Notare due cose: 1) l’esistenza di oggetti
gestiti «attivi» cioè capaci di emettere notifiche in maniera autonoma
e asincrona (cioè quando vogliono!) e 2) l’abilita’ dell’Agente a
processare i dati rivevuti dalla MIB prima di ri-inviarli al Gestore
(Vedi anche il punto No.5).
5. Nel caso di richiesta di operazione su una molteplicità di oggetti (e.g.
richiesta « scoped » o con « filtri », vedi par. 4.10) l’Agente identifica
i singoli oggetti target e, su ognuno di essi, effettua le operazioni
richieste. In questo caso la richiesta da parte del Gestore e’ unica ma
l’Agente la trasforma localmente in una molteplicità di richieste
indirizzate ad una molteplicità di oggetti target (ad esempio la
richiesta potrebbe essere «leggere il numero di serie di tutti gli switch
costruiti dalla CISCO contenuti nella rete gestita»).
Corrispondentemente, nella direzione opposta cioè dall’Agente al
Gestore, l’Agente congloba i risultati di tutte le singole operazioni e li
invia sottoforma di un unica risposta al Gestore. Ovviamente quando
l’Agente implementa queste funzionalità si ottiene una compressione
di dati attraverso l’interfaccia Gestore-Agente i.e. una riduzione della
larghezza di banda (capacità) necessaria al trasporto dei dati. Nel
prossimo capitolo vedremo come tutto ciò possa farsi.
Interfaccia « MIB – risorse gestite ». Questa interfaccia del sistema gestito
deve tener conto del fatto che dalla parte delle risorse gestite (cioè dalla parte
dell’apparato reale da gestire) può esistere una interfaccia con tecnologie
proprietarie (protocolli di comunicazione e strutture dati) non a norma OSI.
Quindi in questa interfaccia il sistema gestito deve svolgere una funzione di
adattamento MIB - tecnologie proprietarie. La funzione di adattamento può
essere considerata come una mappatura fra le operazioni su oggetti gestiti (lato
MIB) e le operazioni su risorse reali gestite (lato apparato gestito).
38
2.4 Il progetto delle applicazioni «sistema gestore» e «sistema
gestito»
•
Il progetto dell’applicazione «sistema gestito»
La Fig.2.3.1.mostra il posizionamento delle tre interfacce all’interno di un sistema
di gestione (che come mostrato in Fig.2.1.1 e’ costituito da un sistema gestore e un
sistema gestito) e, allo stesso tempo, indica le principali funzionalita’ che devono essere
supportate dall’applicazione «sistema gestito» (e che devono essere incorporate dal
progettista nell’applicazione gestionale complessiva): comunicazione col Gestore,
gestione della MIB da parte dell’Agente e adattamento (mappatura) MIB – risorse
gestite.
Nello sviluppo dell’applicazione «sistema gestito» (indicata anche come
applicazione «Agente») contenente la SMAE Agente piu’ la MIB, il progettista non e’
completamente solo ma puo’ usufruire dell’aiuto di strumenti (application development
tools) che, partendo dalle definizioni degli oggetti OSI espressi nel loro linguaggio
GDMO/ASN.1 (vedi dopo) automaticamente forniscono le componenti dell’applicazione
«sistema gestito» relative alla prime due funzionalita’: comunicazione col Gestore
(CMIP/CMISE) e gestione della MIB.
•
Il progetto dell’applicazione «sistema gestore»
Le funzionalita’ supportate da un applicazione sistema gestore sono:
1. Fornire all’utilizzatore del sistema di gestione una interfaccia di
accesso (e.g. GUI, Graphic User Interface) al sistema stesso (Vedi
Fig.2.3.1)
2. Applicazioni gestionali che implementano le funzioni di gestione (e.g.
appartenenti alle cinque aree funzionali del modello FCAPS).
3. Supportare l’architettura prescelta per il gestore e.g. architettura
centralizzata oppure architettura «Manager-of-Managers».
4. Fornire una interfaccia di comunicazione con l’Agente (e.g. pila
OSI)
2.5 I «ruoli» di Gestore e Agente nel modello OSI-SM
(Fig.2.5.1)
Il modello OSI-SM per la gestione di sistema specifica una gestione costituita da
due sistemi gestionali aperti che si scambiano messaggi a livello applicativo: un sistema
aperto gestore che contiene la SMAE Gestore e un sistema aperto gestito che contiene la
SMAE Agente. Notare che in un contesto OSI questo tipo di gestione viene chiamata
gestione «distribuita». Questa terminologia sta ad indicare il fatto che le entità
39
applicative SMAE risiedono in sistemi diversi residenti in nodi elaborativi remoti
interconnessi da una rete di comunicazione. Come già detto, in questo corso il termine
“gestione distribuita” ha un significato diverso e si riferisce all’architettura del gestore.
Ora vogliamo insistere sul fatto che, nel paradigma Gestore-Agente, esistono casi
in cui i sistemi aperti gestore e agente non sono permanentemente gestori o agenti ma
giocano il ruolo dell’uno o dell’altro o di entrambi i ruoli simultaneamente, a seconda
delle esigenze. Ricordiamo che
1) Sistemi che emettono richieste di operazioni sugli oggetti gestiti e
ricevono notifiche dei risultati delle operazioni sono sistemi con ruolo
di Manager o Gestore.
2) Sistemi che hanno un ruolo duale del precedente cioè emettono
notifiche dei risultati e ricevono richieste di operazioni sugli oggetti
sono sistemi con ruolo di Agente.
Questo tipo di interazione fra entita’ gestionali con scambio di ruoli si chiama
anche “peer-to-peer” (cioé pari-a-pari) ed é diversa da altri tipi di interazioni dove i
sistemi interagenti hanno ruoli fissi e.g. una interazione gestionale tipo “master-slave”
dove ciascun sistema é sempre gestore o é sempre agente. Si puo’ pensare a vari scenari
dove due sistemi gestionali si scambiano il ruolo di gestore e di agente nell’ambito di una
interazione peer-to-peer. In precedenza si e’ parlato di sistemi gestionali multi-ruolo in
architetture gestionali di cooperazione o gerarchiche. La Fig. 2.5.1 mostra in dettaglio un
esempio di architettura gestionale di cooperazione. Questa figura si riferisce al caso di
due amministrazioni TLC che acquistano capacità l’una nel dominio di gestione
dell’altra. Ad esempio, la Telecom Italia (A) acquista capacità (eg. reti metropolitane) in
Inghilterra e la British Telecom (B) acquista capacità in Italia. I centri gestionali NMC
(Network Management Center) delle due amministrazioni indicate con A e B effettuano
un interscambio di informazioni e, a seconda di dove avvengono i guasti, fungono di
volta in volta da Agente o da Manager.
40
SCENARIO No.1
NMC
(A)
NOTIFICA
GUASTO
NMC
(B)
SCENARIO No.2
GESTORE (A)
GESTORE (B)
NMC
(A)
RETE (A)
RETE (B)
RETE (B)
RETE (A)
GESTORE (A)
GUASTO
NOTIFICA
GUASTO
NMC
(B)
GESTORE (B)
Confine
Geografico
RETE (A)
RETE (B)
RETE (B)
RETE (A)
Fig. 2.5.1 Esempio di interazione
gestionale tipo peer-to
peer.
Inversione dei ruoli di Manager e
Agente nella associazione NMC(A)
Confine
Geografico
NMC(B)
41
GUASTO
CAPITOLO 3.
Modello OSI-SM per la gestione di
sistema : sottomodello informativo
3.1 Il sottomodello informativo: linguaggio descrittivo,
struttura logica e tecniche di denominazione degli oggetti
gestiti.
In questo capitolo vogliamo illustrare gli aspetti informativi del modello OSISM cioè vogliamo fornire i dettagli di come é descritto, organizzato e strutturato
l’insieme dei dati che costituiscono la rappresentazione astratta delle risorse gestite.
Questi dati sono contenuti nelle basi dati MIB (Management Information Base) dei
sistemi gestiti. Le rappresentazioni astratte delle risorse gestite reali saranno chiamate
«oggetti gestiti». Le risorse gestite contenute in un sistema TLC che sono prese in
considerazione dal modello OSI-SM sono le risorse di utilizzazione e segnalazione
realizzate con tecnologie ICT. Tra poco mostreremo che un oggetto gestito è un caso
particolare (istanza) di una «classe di oggetti gestiti», costituita da tutti gli oggetti gestiti
dotati delle stesse caratteristiche.
Specificare gli aspetti informativi del modello OSI-SM significa specificare
1) linguaggio descrittivo adottato per rappresentare le classi di oggetti
gestiti e le loro istanze cioè gli oggetti gestiti (e.g. il linguaggio GDMOASN.1),
2) struttura logica adottata per rappresentare le relazioni fra le classi di
oggetti gestiti (e.g. relazione di ereditarietà)
3) tecniche di denominazione utilizzate per identificare ciascun oggetto
gestito in modo globalmente univoco (e.g. “albero di contenimento”).
In breve, la descrizione del modello informativo OSI-SM si articola nella
descrizione dei tre elementi: linguaggio descrittivo, struttura logica e tecniche di
denominazione adottate per gli oggetti gestiti contenuti in una MIB.
Gli aspetti informativi del modello OSI-SM sono stati standardizzati dall’ITU-T.
Gli standards sono definiti in una serie di documenti ufficial chiamati Raccomandazioni
ITU-T X.720-725 che, insieme, costituiscono la Struttura dell’Informazione Gestionale
(Structure of Management Information, SMI).
42
Gli standard SMI mostrati nella tavola 3.1.1 sono standards generici relativi alla
struttura degli oggetti gestiti ma non specificano i dettagli costruttivi e/o le tecnologie
implementative degli oggetti gestiti stessi. Gli oggetti gestiti sono stati standardizzati dai
gruppi di lavoro relativi alla struttura dei vari strati del Modello di Riferimento OSI.
Alcuni esempi di standard specifici sono mostrati nella tavola 3.1.2
TITOLO
ITU-T
Management Information Model
X.720
Definition of Management Information
X.721
Guidelines for the Definition of Managed Objects (GDMO)
X.722
Generic Management Information
X.723
Guidelines for the Definition of Conformance Pro-formas
X.724
General Relationship Model
X.725
TAVOLA 3.1.1 Standard OSI per la struttura degli oggetti gestiti (SMI).
TITOLO
ITU-T
Management Information related to the Physical Layer
X.281
Management Information related to the Data Link Layer
X.282
Management Information related to the Network Layer
X.283
Management Information related to the Transport Layer
X.284
TAVOLA 3.1.2 Standard OSI per oggetti gestiti
43
3.2
Introduzione agli «oggetti gestiti» e loro «classi»
In questo paragrafo presentiamo alcuni cenni introduttivi su “Oggetti Gestiti” e le
classi “Classi di Oggetti Gestiti” da cui essi vengono istanziati.
•
Risorse fisiche e logiche
Facendo riferimento a quanto detto nel Cap.1 riconosciamo che le risorse in un
sistema TLC possono essere classificate almeno secondo due criteri “perpendicolari”: un
criterio tecnologico le classifica in risorse ICT e non-ICT e un criterio funzionale le
classifica in risorse di gestione e risorse U & S (Utilizzazione & Segnalazione). Come già
detto, qui facciamo riferimento alla gestione delle risorse ICT/U & S (d’ora innanzi
chiamate semplicemente “risorse gestite”) che vengono gestite per mezzo di opportune
risorse di gestione e.g. OS (Operations Systems) e NSS (Network Support Systems). Qui
vogliamo anche riconoscere che le risorse gestite possono essere fisiche o logiche.
Il significato delle parole “risorse fisiche” e “risorse logiche” si spiega meglio con
alcuni esempi. Una linea di trasmissione, una rete locale, uno switch, un modem
(modulatore-demodulatore) o, piu’ in generale, gli apparati di una rete TLC sono risorse
fisiche. Un programma applicativo, un piano di istradamento, un elenco di dati o un
protocollo comunicativo sono risorse logiche. Tutti questi elementi, se gestiti in modo
opportuno, fanno sì che il sistema fornisca i servizi TLC richiesti dai clienti in maniera
efficace/efficiente.
•
L’oggetto gestito modello astratto di una risorsa gestita
Consideriamo una risorsa reale gestita, i.e. una risorsa ICT/U & S contenuta in
un sistema TLC, con caratteristiche che vogliamo siano gestite dalle relative risorse di
gestione. Nel sistema gestionale che vogliamo descrivere, ogni risorsa reale gestita viene
modellata da uno o più “oggetti gestiti” ognuno dei quali ritiene solo quelle
caratteristiche della risorsa che sono rilevanti al processo gestionale. Ad esempio,
consideriamo un modem in una rete TLC terrestre. Caratteristiche rilevanti alla gestione
possono essere la velocità di modulazione in bits/sec, la Bit Error Rate, il nome del
costruttore e la sua locazione all’interno della rete TLC. Il suo peso, il suo colore o le sue
dimensioni fisiche invece non interessano il gestore e quindi non fanno parte delle
caratteristiche del corrispondente oggetto gestito.
Tutto ciò si esprime dicendo che un oggetto gestito si ottiene dall’insieme
complessivo delle caratteristiche di una risorsa gestita tramite un processo di “astrazione”
(“astrarre” = “tirare fuori da”). Quindi la creazione di un oggetto gestito é la creazione
di un modello astratto di una risorsa reale (fisica o logica) per scopi gestionali.
Usando le definizioni OSI presentate nel Cap.1 possiamo dire che una risorsa gestita é un
elemento reale di un sistema reale, un oggetto gestito é il corrispondente elemento
astratto facente parte di un sistema gestionale aperto, modello astratto del sistema reale.
In un sistema di gestione la condizione necessaria perché una risorsa venga
gestita é la creazione di un corrispondente oggetto gestito il quale verrà
immagazzinato in una MIB sotto il controllo di un Agente.
44
•
La relazione oggetto gestito-risorsa reale gestita
Nel modello organizzativo di Fig. 2.1.1. abbiamo mostrato una relazione univoca
fra oggetto gestito e risorsa gestita cioé ad una risorsa gestita corrisponde un oggetto
gestito e viceversa. Tuttavia la relazione oggetto gestito-risorsa gestita può essere di
carattere più generale ed inoltre la natura di questa relazione non e’ oggetto di
standardizzazione cioè non fa parte del modello OSI-SM. Infatti la Fig. 3.2.1 mostra vari
tipi di relazioni possibili fra oggetti gestiti e risorse gestite, la cui scelta e’ lasciata a
discrezione del progettista. In particolare, sono mostrati i seguenti casi :
1) Un oggetto gestito rappresenta una risorsa gestita
2) Un oggetto gestito rappresenta altri oggetti gestiti, ognuno dei quali rappresenta una
risorsa gestita.
3) Una risorsa gestita é rappresentata da una molteplicità di oggetti gestiti, ognuno dei
quali rappresenta differenti gruppi di caratteristiche della risorsa.gestita.
1
2
3
Fig.3.2.1 Relazioni fra oggetti gestiti e risorse gestite
Alla luce di queste considerazioni, ed in particolare alla luce del punto 3), si capisce che
esiste per il proggettista un certo grado di arbitrarietà nella scelta della relazione
oggetto gestito-risorsa gestita. Nell’effettuare questa scelta si deve anche tener presente
che le attività di gestione si realizzano per mezzo di operazioni, piu’ o meno complesse,
sugli oggetti gestiti e che questi a loro volta devono trasferire i risultati di queste
operazioni sulle risorse reali. (Vedi interfaccia “MIB-Ris.Gest.” in Fig.2.3.1).
Ovviamente un buon progetto richiede una buona scelta delle relazioni fra oggetti gestiti
45
e risorse gestite. Nel prossimo capitolo vedremo con piu’ dettaglio la natura di queste
relazioni.
Concludiamo questo paragrafo ricordando che, come già accennato in precedenza,
le relazioni MIB -risorsa reale gestita non fanno parte del modello OSI-SM ma
appartengono ad un ambiente “locale”.
•
Le quattro “categorie di caratteristiche” dell’oggetto gestito e il suo
“confine”
Nel modello OSI-SM per la gestione di sistema un oggetto gestito é la
rappresentazione astratta di una risorsa da gestire. Esso é definito da caratteristiche
appartenenti a quattro categorie:
1) Attributi (Attributes) visibili al confine degli oggetti gestiti
2) Operazioni (Operations) effettuate su tutto l’oggetto gestito o solo sui suoi
attributi.
3) Notifiche (Notifications) emesse da un oggetto gestito e fornite a un Agente
4) Comportamento (Behaviour) esibito da un oggetto gestito
Definiremo queste caratteristiche in dettaglio fra poco. Come trucco mnemonico si
può ricordare che le iniziali dei corrispondenti termini inglesi costituiscono l’acronimo
“BANO” cognome del noto cantante Al Bano.
Si dice che le caratteristiche sono “viste” dal Gestore al “confine” dell’oggetto
gestito. Vediamo di capire cosa é il confine di un oggetto gestito e perché il concetto di
confine é importante. Prima di tutto dobbiamo capire che il “confine” di un oggetto
gestito e’ un confine opaco (cioè non-trasparente) il quale fa vedere solo ciò che giace
su di esso ma nasconde ciò che e’ contenuto all’interno dell’oggetto.
Facciamo poi riferimento alla Fig.3.2.2 (vedi anche paragrafo 5, Raccomandazione
ITU-T X.720). In questa figura si vede come solo alcune proprietà della risorsa gestita
siano di interesse da un punto di vista gestionale cioè siano visualizzate dal Gestore
mentre altre proprietà non lo siano. Ciò equivale a dire che il Gestore vede le proprietà
gestionali dall’ esterno dell’ oggetto gestito oppure “sul confine dell’oggetto gestito”
mentre le rimanenti proprietà non-gestionali sono nascoste all’interno dell’oggetto gestito
e quindi sono invisibili. Quindi. dire che esiste un confine (opaco) dell’oggetto gestito
equivale a dire che l’oggetto gestito mostra al Gestore solo quelle proprietà della risorsa
reale che sono rilevanti alla gestione della risorsa stessa ma nasconde al suo interno tutte
le altre proprietà.
Da un punto di vista pratico é importante individuare le proprietà della risorsa viste
dal Gestore, cioé introdurre il concetto di confine dell’oggetto gestito, perché queste
proprietà esterne sono definite nel modello e sono oggetto di standardizzazione.
46
Ricordare che concetti simili erano stati introdotti nel Capitolo 1 a proposito del Modello
OSI-RM.
RISORSA GESTITA
PROPRIETA’
DELLA
RISORSA
OGGETTO GESTITO
PROPRIETA’ VISTE
DAL GESTORE
PROPRIETA’ VISTE
DAL GESTORE
“INFORMATION
HIDING”
PROPRIETA’ NON
VISTE DAL GESTORE
CONFINE
DELL’OGGETTO
GESTITO
FIG.3.2.2 Rilevante alla definizione di confine di un oggetto gestito in OSI-SM
•
Le classi di oggetti gestiti: classi generiche e classi specifiche
Oggetti gestiti che hanno le stesse caratteristiche (e.g. attributi, operazioni,
notifiche e comportamento) ma differiscono per i valori specifici di queste caratteristiche
appartengono a una stessa classe di oggetti gestiti (d’ora innanzi chiamata
semplicemente “classe”). Diciamo anche che il singolo oggetto gestito è una “istanza di
una classe” oppure che esso si ottiene per “istanziazione” di una classe tramite specifica
delle caratteristiche della classe.
Nella raccomandazione M.3100 “Generic Network Information Model” (7/1995)
la ITU-T ha definito un gran numero di classi di oggetti gestiti le cui caratteristiche
rappresentano le caratteristiche gestionali generiche di varie risorse (fisiche e logiche) in
una rete TLC. Queste classi rappresentano le caratteristiche gestionali generiche
possedute dalle risorse in una rete TLC indipendentemente dalle tecnologie
implementative effettivamente utilizzate cioè si tratta di caratteristiche “technology
neutral”.
Il sottomodello informativo del modello OSI-SM presentato nella
Raccomandazione M.3100 dell’ITU-T suddivide le classi di oggetti gestiti in sei gruppi
di classi rappresentative di caratteristiche gestionali generiche (gruppi di classi generiche
o “fragments”cioè, in Italiano, “frammenti”):
47
1.
Network (Rete)
2.
Managed Element (Elemento Gestito e.g. apparecchiatura di rete)
3.
Termination Point (Terminazione di interconnessioni fra elementi gestiti
e.g. “connections” , interconnessioni fra singoli apparati di rete, e “trails”,
interconnessioni di rete end-to-end costituite da più “connections”)
4.
Switch & Transmission (Switch & Trasmissione)
5.
Cross-connection (Interconnessione fra porte d’ingresso e porte d’uscita
all’interno di un elemento gestito)
6.
Functional Area (Area funzionale nel modello FCAPS; management
support object classes)
Questi gruppi di classi generiche sono indipendenti dalla particolare tecnologia
implementativa cioè sono modelli generici ottenuti generalizzando modelli gestionali di
tecnologie specifiche (i.e. fra tutte le caratteristiche possedute dalle singole tecnologie
vengono trattenute nel modello gestionale solo le caratteristiche comuni rigettando le
caratteristiche tecnologicamente specifiche e effettuando così un processo di
“generalizzazione”). Si tratta quindi di un livello di astrazione elevato raggiunto creando
modelli gestionali generici prtendo da modelli gestionali specifici (metodologia di
modellazione “bottom up”).
Ovviamente é possibile effettuare il processo inverso cioè un processo di
specializzazione che consiste nel derivare dalle classi generiche le classi specifiche
appropriate alla gestione di tecnologie specifiche tramite aggiunta di caratteristiche
specifiche per ogni tecnologia. Ad esempio dalle classi generiche nel frammento «Rete»
e’ possibile derivare classi specifiche relative a reti realizzate con particolari tecnologie
e.g. reti SDH, ATM, Frame Relay etc.
•
Alcune classi di oggetti non rappresentano risorse fisiche ma sono necessarie
alla realizzazione delle funzioni di gestione
Nella lista dei gruppi di classi riportata in precedenza, il frammento No.6,
Functional Area, non si riferisce a risorse fisiche o logiche di un sistema TLC ma
rappresenta classi di oggetti necessari alla implementazione delle funzioni di gestione
identificate nel modello FCAPS.
Ad esempio consideriamo la funzione di gestione “registrazione allarmi”
appartenente all’area funzionale “Guasti” nel sottomodello FCAPS. Quando in un sistema
TLC si verifica un guasto viene emesso un allarme cioè viene segnalato un guasto con un
format prestabilito (e.g. indicatore codificato che appare sulla GUI nella postazione di
lavoro del gestore). La gestione del sistema richiede che le caratteristiche dell’allarme
(tempo e modalità) siano registrate in un “registro allarmi” . Questo fatto viene
modellizato tramite creazione di una classe di oggetti come segue: le caratteristiche della
funzione “registrazione allarmi” divengono le caratteristiche di una classe di oggetti
48
denominata “alarm record”. La “registrazione di uno specifico allarme” è un oggetto
istanziazione di questa classe.
Altri esempi di classi che non rappresentano risorse fisiche sono i seguenti: la
classe “alarmSeverityAssignmentProfile” si riferisce alla definizione di una classifica dei
livelli di gravita’ di un guasto, la classe “log” si riferisce ad un deposito di registrazioni di
eventi/prestazioni avvenuti nel corso dell’operazione del sistema, la classe
“objectCreationRecord” si riferisce all’immagazzinamento di dati relativi alla creazione
di un oggetto gestito.
•
Le caratteristiche degli oggetti gestiti
Le caratteristiche degli oggetti gestiti OSI-SM sono: attributi, operazioni,
notifiche e comportamento. Vediamo in dettaglio questi elementi.
1) Gli attributi rappresentano le proprietà o lo stato di una risorsa reale «viste»
dal Gestore. Ogni attributo è descritto da un “nome” che in un oggetto gestito assume un
“valore”specifico. Ad esempio, «tipo di stampante» (e.g. se la stampante é una
stampante laser, laser jet o dot matrix) è il nome di un attributo caratteristico della classe
di oggetti gestiti «stampante» che viene istanziato dalla seguente uguaglianza detta in
Italiano Specifica di Valore di Attributo (SVA) (in Inglese Attribute Value Assertion,
AVA)
tipo di stampante = laser jet
Altri esempi di attributi sono la velocità a cui la stampante opera, la località dove
essa si trova, il suo numero di serie, il nome del venditore che la ha fornita. Tutte queste
informazioni sono rilevanti alla gestione della stampante e la caratterizzeranno per
tutta la sua vita. Alcune proprietà, come la velocità, riguardano il suo funzionamento,
altre, come la località o il numero di serie, servono alla sua identificazione. Queste
proprietà permangono nell’ oggetto gestito per tutta la durata della sua vita i.e. dal
momento in cui é creato al momento in cui é soppresso.
Come già detto, in un oggetto, un attributo ha un “valore” specifico. Ad esempio,
tornando al caso della stampante, un oggetto gestito può rappresentare una stampante
capace di stampare con una velocità di cinque caratteri al secondo, si trova nell’ufficio
numero 2 ed é stata fornita dal venditore Hewlet & Packard. Abbiamo indicato in
grassetto i valori degli attributi il cui nome è “velocita’”, “numero d’ufficio” e
“venditore”..
Consideriamo poi un altro oggetto gestito che rappresenta una stampante con la
stessa velocità di stampa e stesso venditore ma é situata nell’ufficio N.13 invece che
nell’ufficio No.2. Questi due oggetti sono diversi pur avendo in comune alcuni attributi
con lo stesso valore. Solo il valore di uno degli attributi (la ubicazione della stampante) é
diverso. Una stampante si trova nell’ufficio No.2 mentre l’altra nell’ufficio No.13.
Quindi oggetti diversi possono avere gli stessi attributi ma diversi valori degli
attributi oppure possono avere alcuni attributi in comune con lo stesso valore. Più in
generale si può dire che oggetti diversi possono avere le stesse caratteristiche ma
49
diverse «specifiche» per caratteristica. Per «specifica» si intende la definizione
specifica di una caratteristica dell’oggetto. Quando si parla di un attributo, il suo valore
é la specifica.
L’identità di un oggetto è garantita dal fatto che esiste almeno un attributo
chiamato attributo di denominazione o attributo di naming (naming attribute) o
attributo distintivo (distinguishing attribute) che assume un valore diverso in ciascun
oggetto e il cui SVA si chiama Relative Distinguished Name (RDN) dell’oggetto.
Vedremo come il RDN viene utilizzato per creare un nome globalmente univoco (DN,
Distingished Name) per un oggetto specifico.
Uno stesso oggetto può avere un valore dell’attributo ad un certo tempo ed
un’altro valore dello stesso attributo in un tempo diverso. Ad esempio, la stampante può
operare a quattro velocità, ad esempio 4, 8, 16, 32 caratteri al secondo e operare col
valore 4 ad un certo istante e poi cambiare al valore 16 in un tempo successivo. In questo
caso l’oggetto gestito rimane lo stesso ma il suo attributo invece di un solo valore può
assumere un valore facente parte di un set di valori prestabiliti (in questo caso le quattro
velocità). Questi valori sono visibili al Gestore che, tramite l’Agente, li può leggere o
modificare.
2) Le operazioni rappresentano le operazioni supportate da un oggetto gestito o
dai suoi suoi attributi. Ad esempio « leggere » o « scrivere» il valore di un attributo sono
“operazioni su attributi”.
Le “operazioni su oggetti” o le “operazioni effettuate da oggetti” possono
essere di tre tipi:
CREATE (Creare un oggetto),
DELETE (Eliminare un oggetto) e
ACTION (Esecuzione di una azione da parte di o su un oggetto).
NOTA: la operazione CREATE non e’ propriamente una operazione «su» un oggetto
poichè l’oggetto non esiste prima dell’operazione.
La definizione di una azione effettuata da un oggetto gestito serve a modellare le
operazioni che una risorsa reale è capace di effettuare su richiesta di un Gestore (tramite
Agente). Una richiesta del Gestore ad un Agente perchè un oggetto gestito effettui una
azione, richiede la descrizione della azione stessa (o più precisamente della semantica
dell’azione) e talvolta l’invio di parametri necessari per portare a termine l’operazione
stessa. Facciamo un esempio. Consideriamo uno switch che contiene una unità principale
attiva e una unitò di riserva. Il Gestore vuole effettuare una operazione gestionale che
rimpiazzi l’unità principale con l’unità di riserva in caso di guasto della prima. Allora
l’operazione che l’oggetto gestito «switch » dovrà supportare, cioè essere capace di
effettuare in caso di guasto dell’unità principale è definita come segue: «In caso di
guasto nell’unità principale commutare sull’unità di riserva». Questa richiesta di azione
viene inviata dal Gestore all’Agente, dall’Agente alla MIB e dalla MIB allo switch reale.
50
Essa può poi richiedere una conferma di azione effettuata, conferma inviata dall’ Agente
al Gestore.
3) Le notifiche sono segnalazioni inviate da uno o più oggetti gestiti ad un
Agente, relative ad eventi occorsi negli oggetti gestiti stessi, indipendentemente da
richieste esterne (segnalazioni automatiche). Queste segnalazioni sono ritrasmesse, dopo
opportuno processing, dall’Agente al Gestore sottoforma di messaggi di “notifica di
evento”. (Vedi Fig.3.1.1). Un messaggio di notifica include l’informazione relativa alla
ragione per cui l’informazione é stata inviata, la locazione dove l’evento riportato si é
verificato e il gestore destinatario della notifica (ricordare che un Agente può far capo a
piu’ Gestori). Il Gestore, se vuole, può riconoscere la ricezione della notifica
¨ CIRCUIT PACK
¨
CLASSE DI OGGETTI:
(MODELLO ASTRATTO DI
¨ CHANNEL UNIT
¨)
ATTRIBUTO
No.1
(Pacco
Obbligatorio )
Stato
Operazionale
ATTRIBUTO
No.2
(Pacco
Condizionale )
Stato
di
Allarme
Interazione fra
Attributi
COMPORTAMENTO: Quando lo
stato di allarme ¨ assume il
valore ¨critico ¨ lo ¨stato
operazionale ¨ assume il valore
¨disinserito ¨ per evitare che il
guasto si propaghi .
Fig.3.2.3 Esempio di COMPORTAMENTO dove si descrive
l’interazione fra attributidi una stessa classe ma appartenenti a due
pacchi diversi .
Tutto ciò è particolarmente importante per la gestione dei guasti (la lettera F nel
modello FCAPS). In tal caso una notifica diviene la notifica di un guasto (e.g. la notifica
che un certo parametro gestionale ha superato un valore di soglia). La generazione di una
notifica da parte di un oggetto gestito mostra come nella gestione OSI-SM un oggetto sia
una entita’ attiva capace di svolgere attività in modo autonomo.
4) Il comportamento (behaviour) è molto spesso una caratteristica «relativa»,
nel senso che esso descrive testualmente (cioè in lingua piana) la variazione di una
caratteristica di un oggetto dovuta a variazioni di altre caratteristiche dello stesso oggetto
51
o di altri oggetti ad esso relazionati. La Fig.3.2.3 mostra un esempio di comportamento
relativo all’interazione di attributi di uno stesso oggetto ma appartenenti a pacchi diversi.
Questo “comportamento” richiede che nel caso di guasto, l’oggetto debba emettere una
segnalazione di allarme e essere disinserito (per evitare che il guasto si propaghi).
Usiamo il termine «allarme» per indicare l’occorrenza di un guasto in una forma
prestabilita. Altro esempio: un “comportamento” può descrivere le condizioni in cui una
notifica viene emessa da un oggetto.
CLASSE di OGGETTI
SPECIFICHE SEMPRE
PRESENTI IN TUTTI GLI
OGGETTI
Caratteristiche
PACCO No.1
PACCO No.2
PACCO No.3
(OBBLIGATORIO)
(CODIZIONALE)
(CONDIZIONALE)
B
B
B
A
B
N
O
A
A
N
O
N
A
N
O
O
OGGETTI
(ISTANZE della
CLASSE)
SPECIFICHE PRESENTI IN ALCUNI OGGETTI
SE CERTE CONDIZIONI SONO VERIFICATE
Fig. 3.3.1 Una classe di oggetti é rappresentata da caratteristiche di quattro tipi: comportamento (B),
attributi (A), notifiche (N) e operazioni (O). Gli oggetti sono istanze della classe ottenute attribuendo
valori specifici alle caratteristiche. La classe é suddivisa in pacchi con specifiche presenti in tutti gli
oggetti (Pacchi obbligatori) o in alcuni oggetti solamente quando certe condizioni sono verificate
(Pacchi condizionali) e.g. apparecchiature con riconfigurabilità o capacità di emettere allarmi.
3.3
La struttura “a pacchi” delle classi di oggetti gestiti
Nel modello OSI-SM ogni classe di oggetti gestiti è suddivisa in sottoinsiemi
ognuno dei quali rappresenta un insieme di caratteristiche chiamato «pacco »
(« package » in inglese). (Vedere Fig. 3.3.1 ). Nel caso più generale le caratteristiche di
un pacco appartengono a tutte e quattro le categorie già enunciate in precedenza:
52
comportamento (B, iniziale della parola inglese behavior), attributi (A), notifiche (N) e
operazioni (O).
I pacchi possono essere di due tipi: obbligatori o condizionali. Il pacco
obbligatorio contiene le caratteristiche presenti in tutti gli oggetti della classe. Invece le
caratteristiche contenute nei pacchi condizionali sono presenti solo se si verificano certe
condizioni particolari. Quindi un oggetto, istanza di una classe, contiene sempre le
caratteristiche del pacco obbligatorio e può contenere le caratteristiche dei pacchi
condizionali se sono verificate certe condizioni. L’utilità di suddividere una classe in
pacchi è legata al fatto che risorse simili ma non del tutto uguali possono essere
rappresentate dalla stessa classe. Una stessa classe può rappresentare risorse con certe
caratteristiche e risorse con caratteristiche extra semplicemente aggiungendo pacchi
condizionali.
Ad esempio facciamo riferimento allo switch di Fig.3.4.1, considerato come un
elemento di rete da gestire, appartenente alla classe “managed element” (vedi
Raccomandazione ITU-T M.3100). In questo switch tutte le schede circuitali (e.g.
appartenenti alla classe «circuit pack») hanno un insieme di caratteristiche obbligatorie
(pacco obbligatorio, pacco No.1 in Fig.3.3.1) mentre solo alcune hanno caratteristiche
aggiuntive di riconfigurabilità (pacco condizionale No.2) o abilità di emettere allarmi
(pacco condizionale No.3). Quest’ultimi due tipi di schede circuitali fanno parte della
stessa classe «circuit pack» a cui appartengono le schede dotate solo delle caratteristiche
obbligatorie. Si vede quindi il vantaggio della struttura a pacchi: tutte le schede circuitali
in uno stesso elemento di rete appartengono alla stessa classe «circuit pack», tutte hanno
lo stesso pacco obbligatorio ma solo quelle con caratteristiche extra utilizzano pacchi
condizionali No.2 o No.3
Notare che il concetto di pacco entra in gioco solo a livello di «classe» di oggetti e
la assenza o presenza dei pacchi condizionali viene decisa al momento della specifica
(istanziazione) di un oggetto. (Osservare bene Fig.3.3.1). Infatti al momento di creare un
oggetto, cioè istanziare una classe, il progettista verifica se le condizioni di esistenza di
un pacco condizionale sono soddisfatte. Se la risposta è positiva tutte le caratteristiche di
questo pacco sono incluse nella specifica dell’oggetto e permangono nell’oggetto per
tutta la sua vita. Se più pacchi contengono la stessa caratteritica, questa viene inclusa
nella specifica dell’oggetto una volta sola. Una volta un oggetto è stato specificato in
termini di caratteristiche B, A, N, O non ha più importanza riconoscere quali
caratteristiche vengono da quali pacchi. Quindi dopo la istanziazione di una classe in
un oggetto specifico il concetto di pacco è scomparso.
Ma ricapitoliamo quanto detto sin qui.
1)
Gli oggetti gestiti con le stesse caratteristiche (e.g. attributi) ma con
diverse specifiche (e.g. valori degli attributi) costituiscono una classe di
oggetti gestiti.
2)
Una classe di oggetti gestiti ha caratteristiche che appartengono a
quattro categorie: comportamento, attributi, notifiche e operazioni (in
53
inglese BANO, dalle iniziali delle parole behaviour, attributes,
notifications and operations)
3)
Per passare da una classe di oggetti gestiti a un oggetto gestito si
richiede la specifica dei valori degli attributi e la descrizione specifica
delle operazioni, delle notifiche e dei comportamenti, cioé la specifica
delle caratteristiche della classe stessa. Gli oggetti si chiamano
« istanze » della classe. La creazione di un oggetto da una classe cioé
il processo di specifica delle caratteristiche della classe si chiame
« istanziazione» della classe.
4)
Due oggetti diversi appartenenti alla stessa classe hanno differenti
valori di almeno un attributo chiamato attributo distintivo o di
“naming” perché usato nella definizione del nome dell’oggetto.
54
managedElementId
=ATME
1
1
2
3
1
2
EquipmentId = slot i
(i=1,2,3)
EquipmentId = j
(j=1,2,3)
EquipmentId =
Shelf 1
1
2
1
3
2
3
1
2
3
EquipmentId =
Shelf 2
EquipmentId = slot i
(i = 1,2)
EquipmentId = j
(j=1,2,3)
1
2
1
1
1
1
1
1
EquipmentId =
Shelf 3
EquipmentId = slot i
(i =1-6)
EquipmentId = 1
1
2
3
4
5
6
Fig.3.4.1 Attributi di denominazione e sintassi dei loro valori. Classi rappresentative delle
risorse contenute in un elemento di rete gestito
(e.g. switch): ripiani (shelves),
55
compartimenti (slots) e schede (cards)
Elemento
fisico
Classe di
appartenenza
(M.3100)
Ntwrk Element
Managed Element
Attributo
di Denom.
Valore Attributo
(Tipo di dato)
Managed
Element
Id
Sequenza
di lettere
Equipment
Holder
EquipmentId
Shelf +intero
(Compartimento)
Equipment
Holder
EquipmentId
Slot +intero
Card
Circuit Pack
EquipmentId
Sequenza
Alfanumerica
(Elemento Rete)
Shelf
(Ripiano)
Slot
(Scheda)
Fig. 3.4.2 Rilevante alla figura 3.4.1
3.4 Esempio di oggetti gestiti e loro classi.
Supponiamo di dover gestire uno “switch”, mostrato in Fig.3.4.1 considerato
come un “elemento di rete” costituito da 3 shelves (ripiani), 11 slots (compartimenti) e 18
cards (schede circuitali) assemblate come mostrato in figura. Le schede sono di diverso
tipo e svolgono varie funzioni: schede di processing (central processing cards), schede di
interfaccia di linea o trunk, schede di sicronizzazione (timing cards), schede matrici di
commutazione (switching matrix cards) etc. Da un punto di vista gestionale ognuno di
questi elementi fisici é rappresentato da un oggetto gestito cioé una istanza di una
classe di oggetti gestiti. Le classi di nostro interesse sono mostrate in Fig.3.4.2. Esse
sono: Managed Element (Elemento di rete), Equipment Holder (ripiano), Equipment
Holder (compartimento) e Circuit Pack (scheda circuitale). Ogni classe ha un attributo di
denominazione il cui valore viene scritto secondo le regole sintattiche mostrate in figura.
La figura 3.4.3 mostra gli attributi della classe Circuit Pack. Nella stessa figura sono
mostrate due istanze della classe cioè
56
Classe “Circuit Pack”
(rappresentativa delle schede contenute in un
elemento di rete come in Fig.3.4.1)
Oggetto gestito No.1 rappresentativo
di una unità di canale telefonico (Plain
Old Telephone Service Channel Unit,
POTS CU)
•equipment Id = “CU 1”
•administrative state = locked (Bloccato)
•alarm status = clear (Libero)
•availability status = in test (in prova)
•circuit pack type = “POTS CU”
•current problem list = Empty (Vuota)
•operational state = enabled (Abilitato)
•replaceable = yes
•serial number = “Part 1 458”
•vendor name “LGR”
•version = “1.0.5”
•equipment Id (Attributo distintivo)
•administrative state (Stato ammin.)
•alarm status (Stato di allarme)
•availability status (Disponibilità)
•circuit pack type (Tipo di scheda)
•current problem list (Lista problemi)
•operational state (Stato operativo)
•replaceable (Rimpiazzabile)
•serial number (Numero di serie)
•vendor name (Nome venditore)
•version (Versione)
Oggetto gestito No.2 rappresentativo
di una unità di canale E1 (2.4 Mbit/sec)
•equipment Id = “E1U 1”
•administrative state = unlocked
•alarm status = minor
•availability status = {Empty}
•circuit pack type = “E1Unit”
•current problem list = {Empty}
•operational state = enabled
•replaceable = yes
•serial number = “Part 7689”
•vendor name = “TLF”
•version = “2.1”
Fig.3.4.3 Esempio di creazione di due oggetti gestiti tramite Specifica del Valore
di Attributo, SVA (AVA, Attribute Value Assertion in inglese). Il processo complessivo
si chiama istanziazione di una classe di oggetti gestiti (Circuit Pack) rappresentazione astratta
delle schede contenute in un elemento di rete come in Fig. 3.4.1
57
due oggetti gestiti corrispondenti a due schede di interfaccia relative ad un canale
telefonico e ad un canale E1 (2.4 Mbit/sec).
3.5 La proprietà di ereditarietà fra classi di oggetti gestiti e
sua rappresentazione grafica: “Albero delle Classi”.
La “Metodologia dell’orientamento agli oggetti” adottata nella costruzione del
modello OSI-SM permette di specificare una classe di oggetti gestiti in maniera
particolarmente efficiente. Con ciò vogliamo alludere al fatto che questa metodologia
permette di definire una nuova classe ri-usando le specifiche di una vecchia classe già
specificata in precedenza, sfruttando il fatto che la vecchia e la nuova classe possono
essere mutuamente relazionate. Vediamo come.
Nella gestione dei sistemi TLC ci sono molte situazioni in cui una classe B può
avere le stesse caratteristiche di una classe A più altre caratteristiche cioé la classe B é
più specializzata della classe A. Si dice anche che B é una sottoclasse di A oppure che A
é una superclasse di B oppure che A é un “genitore” di B e B un “figlio” di A.
Una relazione fra classi di questo tipo è una relazione di “ereditarietà ”. Questo
termine deriva dal fatto che la sottoclasse B eredita tutte le caratteristiche dalla
superclasse A e in aggiunta a queste ne possiede delle altre. Si dice anche che la
sottoclasse B estende le specifiche di A o che B specializza A o che B ri-usa tutte le
caratteristiche di A. Ci si può sbizzarrire nella scelta dei termini! Ovviamente in
letteratura si trovano, poi, tutti i termini derivati e.g. “estendibilità “, “estensione”,
“specializzazione” etc.
Ad esempio si dice che una delle caratteristiche dell’orientamento agli oggetti é la
“estendibilità ”delle classi. Ad esempio, come già detto, le classi generiche definite nel
documento ITU-T M.3100 (Vedi par.3.2), sviluppate per un modello informativo
generico (cioé indipendente dalla particolare tecnologia implementativa) sono applicabili
a modelli informativi per tecnologie specifiche tramite aggiunta di caratteristiche
specifiche (processo di “specializzazione”).
A quanto detto sin’ora possiamo aggiungere quanto segue
1) Nel modello di gestione OSI-SM una nuova risorsa da gestire si modellizza
con un nuovo oggetto gestito istanza di una nuova classe (supponiamo la
classe “B”). La nuova classe “B” si può definire come sottoclasse di una
vecchia classe “A” già definita in precedenza ma con caratteristiche uguali
solamente ad un sottoinsieme delle caratteristiche di “B”. Per definizione,
tutte le caratteristiche di questa superclasse “A”sono ereditate dalla nuova
classe “B” e la specifica della nuova classe “B” richiede solo la definizione
delle caratteristiche aggiuntive. L’importanza pratica della proprietà di
ereditarietà fra classi, tipica della metodologia dell’orientamento agli oggetti,
é proprio questa: in molti casi specificare un nuovo oggetto (ad esempio un
apparato di nuova generazione) si riduce ad aggiungere alcune caratteristiche
alle caratteristiche di una superclasse già specificata in precedenza i.e. a
58
specializzare la superclasse. Osserviamo che le proprietà di ri-usabilità ed
estendibilità (o specializzazione) sono tipiche dell’orientamento agli
oggetti. Notare che queste stesse caratteristiche sono anche tipiche di un buon
standard gestionale che si vuole riusabile e estendibile. (Vedi Parte I del
corso)
2) Il processo di specializzazione può essere ricorsivo cioé una classe B puo’
essere sottoclasse di A e una classe C sottoclasse di B e così via. Quindi può
introdursi una struttura gerarchica graficamente rappresentabile con un albero
(“Albero delle Classi) che parta dall’ alto con una classe generica e.g. « rete
TLC » definita nella Racc. ITU-T M.3100 e si estenda verso il basso con
classi sempre più specializzate. Nell’albero delle classi si riconoscono vari
livelli. Una classe di oggetti più generica sta ad un livello superiore rispetto
ad una classe più specializzata che sta ad un livello inferiore.
La Fig.3.5.1, derivata dalla raccomandazione ITU-T M.3100 «Generic Network
Information Model »(1995), mostra un esempio di relazioni gerarchiche fra classi di
oggetti gestiti (“Albero delle Classi” o “Albero di Ereditarietà”). Si tratta di classi relative
ai “fragments” Managed Element e Termination Point. Vediamo il significato di alcune
delle classi.
PARTE FACOLTATIVA
La classe «top» é la radice dell’albero e è stata definita nella Racc. ITU-T 720.. E’ la classe al più
alto livello di astrazione cioè contiene le caratteristiche ereditate da tutte le classi sottostanti nell’albero e
quindi dai relativi oggetti. Si tratta di una classe non istanziabile con quattro attributi. “Non istanziabile”
significa che non esiste nessun oggetto gestito che possiede solo questi quattro attributi mentre è vero che
tutti gli oggetti gestiti possiedono almeno due di questi attributi (i primi due sono obbligatori mentre gli
altri due sono opzionali) (Vedi: D.K.Udupa “Telecommunication Management Network”, McGraw Hill,
1999, p. 147 oppure, L.G. Raman, “Fundamentals of Telecommunications Network Management”, IEEE
Press, 1999, p. 142). I quattro attributi della classe “top” sono:
1) object class
2) name binding (attributo di legame),
3) packages (attributo di pacco),
4) allomorphs (attributo di classi allomorfe).
. Questo significa che ogni oggetto gestito (istanza di una classe) è caratterizzato da:
1) una classe di appartenenza con un certo nome,
2) un “legame di denominazione” (name binding) che specifica un oggetto gestito “contenitore”.
(Vedi dopo). Questa informazione è necessaria per dare all’oggetto un nome globalmente univoco “DN”,
Distinguished Name.
3) se esistono pacchi condizionali, l’oggetto deve possedere un attributo che indichi gli “indicatori
di registrazione” dei pacchi
3) se esistono classi allomorfe, l’oggetto deve possedere un attributo che le indichi. (Spiegazione
di classe allomorfa: se un oggetto X della classe A è gestibile come un oggetto Y della classe
B diversa da A, la classe B è detta classe allomorfa di X).
59
In pratica, nella rappresentazione delle classi (maschere di classe) sottostanti, la “superclasse top”
viene semplicemente indicata come segue:
DERIVED FROM
“Recommendation X.721: 1992”: top;
senza ulteriori specifiche (e.g. Vedi Racc.ITU-T M.3100, pag.12)
----------------------La classe “termination point” (terminazione) é descritta nella definizione 3.3.4
della raccomandazione M.3100. Essa modellizza le terminazioni di linee di trasmissione
generiche che interconnettono elementi di rete (“connections”, connessioni fra
apparecchiature di rete) o collegamenti di piu’ “connections” chiamati “trails” (cammini
end-to-end in una rete). La classe “termination point” ha come sottoclassi le due classi
relative alle terminazioni di connessione o di cammino: classi “trail termination point,
TTP”e “connection termination point, CTP”. La classe CTP si divide nelle sottoclassi
unidirezionali “CTP source” e “CTP sink” i cui oggetti gestiti modellizzano
rispettivamente punti d’origine o di arrivo di segnali. La classe “CTP bidirectional”
(terminazione bidirezionale) é un esempio di eredità multipla derivata da due superclassi.
Ragionamenti analoghi vanno fatti per la classe TTP.
La classe “equipment” (equipaggiamento) ha due sottoclassi : “equipment
holder” (contenitore di equipaggiamento) e “circuit pack” (pacco circuitale). La classe
equipment holder rappresenta risorse fisiche, e.g. slots, compartimenti, che contengono
altre risorse fisiche, e.g. cards, carte circuitali. La classe circuit pack é stata già descritta a
proposito della Fig.3.4.3.
Le classi managed element e managed element complex rappresentano
rispettivamente un singolo elemento di rete o un insieme di elementi di rete mentre la
classe software rappresenta informazione contenuta in programmi o basi dati (risorse
logiche) immagazzinata nella apparecchiature di rete.
60
Top
Managed
Managed
Element
Element
Complex
Termination
Point
Managed
Equipment
Software
Element
Software R1
CTP
CTP
TTP
TTP
Source
Sink
Source
Sink
CTP
Bidirectional
TTP
Bidirectional
Equipment R1
Equipment
Holder
Circuit
Pack
Fig.3.5.1. “Albero di ereditarietà” fra classi di oggetti gestiti
appartenenti ai “frammenti” Managed Element.e Termination
Point (Raccomandazione ITU-T M.3100.del 1995)
61
3.6 Relazione di “contenimento” e “albero dei nomi”:
relazione gerarchica fra nomi di oggetti gestiti
Vediamo ora una relazione fra oggetti gestiti che si utilizza quando si vuole
stabilire un nome globalmente univoco per ogni oggetto gestito. Questa relazione
stabilisce che un nome globalmente univoco di un oggetto gestito é definito tramite
gli RDN di altri oggetti gestiti chiamati oggetti “contenitore”. La relazione fra un
oggetto “contenuto” e un oggetto “contenitore” si chiama “relazione di contenimento”.
Le relazioni di contenimento sono rappresentate graficamente da una architettura
denominata “Albero di Contenimento” o “Albero dei Nomi” (Fig.3.6.1). Ad eccezione
della radice dell’albero ogni oggetto gestito ha un suo oggetto contenitore.
Ad esempio, facendo riferimento alla Fig. 3.4.1, la relazione di contenimento
puo’ specificare che il nome di una carta circuitale, istanza della classe “circuit pack”, é
univocamente definito solo se riportato assieme al nome di un compartimento, istanza
della classe “equipment holder ”.
Notare come in questo esempio in cui appaiono le classi “circuit pack” e
“equipment holder ” la relazione di contenimento abbia un preciso riscontro fisico.
Infatti, facendo riferimento alla figura 3.4.1 si riconosce che all’interno di uno stesso
elemento di rete, una scheda circuitale, istanza della classe “circuit pack”, é fisicamente
contenuto in un compartimento (slot), istanza della classe “equipment holder”. Però, non
é necessario che una relazione di contenimento abbia un riscontro fisico. Infatti, le
relazioni di contenimento si usano unicamente per stabilire nomi univoci per oggetti
gestiti e non per caratterizzare situazioni in cui apparati fisici siano contenuti l’uno
nell’altro.
Quindi un nome univoco per un oggetto gestito si ottiene come segue: un oggetto
gestito (identificato dal suo RDN) é “contenuto” in un altro oggetto gestito “contenitore”
il quale a sua volta è “contenuto” in un altro oggetto “contenitore” e così via fino a
raggiungere un oggetto “radice dell’albero di contenimento” privo di contenitore.
(carattere ricorsivo delle relazioni di contenimento).
Il carattere ricorsivo delle relazioni di contenimento è apparente nell’albero dei
nomi. Come mostrato in Fig.3.6.1 l’albero dei nomi parte dall’alto da un punto di
partenza di riferimento (che é solo un punto di riferimento senza essere un oggetto
gestito) chiamato “root”, radice. L’albero estende i suoi rami verso il basso con oggetti
contenuti ( non necessariamente in senso fisico) gli uni negli altri. La Fig.3.6.1 si riferisce
ad una rete di telecomunicazione nella quale due elementi di rete (NE) sono gestiti
indipendentemente. In questo caso particolare le relazioni di contenimento fra nomi
hanno un riscontro fisico. Infatti, in ogni elemento di rete ci sono “Trail Termination
Points” (TTP) e “Shelves”. Nelle “shelves” ci sono “slots” e nelle “slots” ci sono “cards”
modellizate come “circuit packs”. Vediamo ora come dall’albero possano ricavarsi i nomi
degli oggetti.
62
3.7 I nomi degli oggetti gestiti: RDN (Relative Distinguished
Name), DN (Distinguished Name) e nome locale
In Fig. 3.6.1 il RDN (Relative Distinguished Name) di ogni oggetto gestito é
contenuto in un ellisse ed é espresso dal suo SVA (Specifica Valore di Attributo) cioè dal
nome del naming attribute uguagliato al suo valore. Il termine “relative” cioé “relativo”
deriva dal fatto che questo nome é univoco relativamente al nome dell’oggetto superiore
nella struttura gerarchica. Ad esempio un RDN é Equipment Id = “Shelf 1”. In questo
caso “Equipment Id” é l’attributo distintivo della classe “equipmentholder” e “Shelf 1” il
suo valore.
Root
Country Name = “USA ”
Oggetti non
gestiti
Organization Id = “ADC ”
Network Id
mE Id = “SRI ”
mE Id = “LGR ”
Equipment Id
Analog TTP Id = 5
= “Mama ”
=
E1 TTP Id = 7
Equipment Id
“Shelf 1”
Equipment Id
Equipment Id
Fig.3.6.1
=3
= “Slot 5 ”
Equipment Id
Equipment Id
= “Shelf 1 ”
= “Slot 2 ”
=3
Esempio di albero dei nomi basato sulla proprietà di contenimento degli oggetti gestiti
Notare come un particolare RDN non è univoco nell’ambito di tutta la struttura
gerarchica. Ad esempio nell’albero di Fig.3.6.1 ci sono due oggetti che si chiamano
entrambi Equipment Id = 3 e quindi questo nome non é univoco all’ interno di questa
struttura.
Per ottenere un nome univoco nell’ambito della struttura gerarchica (detto DN
globale, Distinguished Name globale) per un certo oggetto gestito si deve concatenare il
63
suo RDN con il DN del suo contenitore. A sua volta il DN di questo oggetto contenitore
uguaglia il suo RDN concatenato col DN del suo contenitore. Si capisce allora che il DN
di un oggetto si ottiene col concatenamento di tutti gli RDN compresi fra la radice
dell’albero e l’oggetto desiderato.
Infine é bene menzionare una variante del DN globalmente univoco o DN
globale: il DN locale. Il DN locale é come il DN globale ma invece di partire dalla radice
dell’albero parte dal DN di un altro oggetto.
Ad esempio, con riferimento alla Fig. 3.7.1 si vede che il nome DN locale
nell’ambito della rete denominata “pietro” della terza carta nel secondo compartimento
del primo livello dell’elemento di rete di Fig.3.4.1 è,
DN -> Network Id = pietro, Managed Element Id = ATME, Element Id = “Shelf
1”, Equipment Id = “Slot 2”; Equipment Id=3
ESEMPIO di DN LOCALE
Reti
NetworkId=pietro
nEId= ATME
Elementi di
Rete
EquipmentId
Ripiani
EquipmentId=
Slot1
EquipmentId=
=
Shelf 1
EquipmentId
EquipmentId
=
EquipmentId
Shelf 2
=
Slot2
1
EquipmentId
EquipmentId
=
Slot3
=2
EquipmentId
Compartiment i
=3
Fig. 3.7.1 Esempio di DN locale relative alla rete denominata “pietro”
64
=
Shelf 3
Schede
Circuitali
3.8 Le maschere GDMO: la rappresentazione grafica delle
classi e loro caratteristiche.
Le classi di oggetti gestiti e le loro caratteristiche (attributi, azioni, notifiche e
comportamento) sono rappresentati da schematizzazioni grafiche standardizzate chiamate
“maschere” (in inglese “templates”) secondo norme pubblicate nella raccomandazione
ITU-T X.722 “Guidelines for the Definition of Managed Objects” generalmente
chiamata “guida GDMO”. Per questo in letteratura si legge che il modello OSI-SM adotta
il « linguaggio GDMO » per rappresentare le classi di oggetti gestiti o le loro istanze, gli
oggetti gestiti, oppure che un oggetto gestito é rappresentato da « maschere GDMO ».
In questo corso noi diremo che gli oggetti gestiti nelle MIB sono rappresentati con
un linguaggio GDMO. Piu’ precisamente adotteremo la seguente definizione:
DEFINIZIONE DI LINGUAGGIO GDMO : il linguaggio GDMO é un
linguaggio OSI usato nel sottomodello informativo e caratterizzato da una sintassi
chiamata « ASN.1 » e da costrutti chiamati « maschere GDMO ».
Fra poco illustreremo (con un esempio pratico mostrato in Fig.4.8.1) cosa sia una
maschera. La definizione di maschera GDMO é la seguente:
DEFINIZIONE DI MASCHERA GDMO : Una maschera GDMO é uno
grafo orientato con tre tipi di nodi : 1) parole chiave, 2) caratteri tipografici di
punteggiatura e 3) nomi.
Un grafo orientato é uno schema grafico da percorrersi da “nodo” a “nodo”
seguendo un percorso predeterminato, ad esempio in Fig.4.8.1 partendo in alto a sinistra
e muovendosi verso destra dall’alto verso il basso.
La guida GDMO definisce nove tipi di maschere:
1.
2.
3.
4.
5.
6.
7.
8.
Managed Object Class (Classe)
Package (Pacco)
Attribute (Attributo)
Attribute Group (Gruppo di Attributi)
Action (Azione)
Behavior (Comportamento)
Notification (Notifica)
Name Binding (Legame)
Ad eccezione delle maschere di comportamento che usano un linguaggio naturale
(lingua piana), tutte le altre maschere usano un linguaggio standard (sintassi) chiamato
ASN.1 (Abstract Synthax Notation.1) descritto nella raccomandazione X.208. La
maschera di azione descrive una “azione”, definita precedentemente come un operazione
che un oggetto gestito é capace di compiere quando richiesto dal Gestore attraverso
l’Agente. Ricordiamo che le operazioni richieste ad un oggetto gestito si dividono in due
categorie: operazioni orientate agli attributi e orientate agli oggetti. Le operazioni
65
orientate agli oggetti sono: creazione o distruzione di un oggetto e azione (effettuata da o
su un oggetto). La specifica delle azioni viene effettuata nelle maschere di azione mentre
la specifica della creazione/distruzione di un oggetto gestito viene fatta nelle maschere di
legame.
Ogni classe di oggetti gestiti é descritte da una sequenza di maschere
incapsulate l’una nell’altra: una maschera di classe contiene maschere di pacco, ogni
maschera di pacco contiene maschere di attributo, azione, notifica e comportamento.
Una maschera di classe specifica una superclasse (da cui vengono ereditate certe
caratteristiche) più un certo numero di pacchi (un pacco obbligatorio con le caratteristiche
possedute da tutte le istanze più pacchi condizionali con caratteristiche possedute da
alcuni pacchi, vedi Fig.3.8.1). Per ogni pacco esiste una maschera di pacco che
specifica attributi, azioni, notifiche e comportamenti. Gli attributi sono descritti in
maschere di attributo, le azioni in maschere di azione, le notifiche in maschere di
notifica e i comportamenti in maschere di comportamento. Noi non studieremo tutte
queste maschere. Esempi di alcune maschere sono presentati qui di seguito.
•
Esempio di maschera di classe
Esistono due tipi principali di reti locali (LAN) con topologie a bus (Ethernet
LAN) o ad anello (Token Ring). La Fig.3.8.1 rappresenta un esempio di maschera di
classe relativa alla classe “Token Ring”e, nella parte inferiore, mostra come questa
maschera rispetti lo standard GDMO che, lo ripetiamo, é espresso da un grafo orientato
con tre tipi di nodi: parole chiave, caratteri tipografici di punteggiatura e nomi (o testo
autoesplicativo).
In una maschera di classe , la parola chiave DERIVED FROM indica che un
Token Ring è un tipo particolare di LAN e quindi la classe “tokenRing” eredita tutte le
caratteristiche della superclasse “lanNet” la quale a sua volta eredita tutte le
caratteristiche delle classi superiori (rappresentative di reti più generiche).
La parola chiave CHARACTERIZED BY indica che la classe tokenRing, in
aggiunta alle caratteristiche ereditate dalla superclasse lanNet, possiede le caratteristiche
racchiuse nel pacco obbligatorio tokenRingLan che verrà descritto in una maschera
separata (una maschera di pacco) mostrata nella figura seguente. I pacchi obbligatori
sono sempre introdotti con la parola chiave “CHARACTERIZED BY”.
La parola chiave CONDITIONAL PACKAGE rivela la presenza di un pacco
condizionale tokenRingRouter le cui caratteristiche saranno utilizzate in alcune istanze
solo se le condizioni specificate dopo la parola chiave PRESENT IF saranno verificate
cioé solo se il tokenRing sarà connesso tramite un router ad un anello dorsale in fibbra
ottica tipo FDDI (Fiber Distribution Data Interface) come avviene molto spesso nei
campus universitari americani. I pacchi condizionali sono caratterizzati dalla parola
chiave “CONDITIONAL PACKAGE” seguita dalla parola chiave “PRESENT IF”.
Infine la parola chiave REGISTERED AS fornisce l’elemento distintitivo cioé
l’identificatore (identifier) di registrazione (Vedi par.3.11). Ad eccezione delle maschere
66
di pacco obbligatorio, tutte le altre maschere si chiudono con la parola chiave
“REGISTERED AS” seguita da una sequenza alfanumerica di registrazione.
Nel paragrafo 3.11 spiegheremo come il processo di assegnazione di un valore
globalmente univoco ad ogni tipo di informazione gestionale si chiama processo di
“registrazione”. La registrazione si esprime graficamente non con un solo numero ma
con una sequenza di numeri interi opportunamente scelti. Questa sequenza di numeri é
anche chiamata «identificatore» (identifier, in inglese) proprio perché identifica in modo
univoco l’informazione gestionale a cui si riferisce.
•
Esempio di maschera di pacco
La Fig.3.8.2 mostra una maschera di pacco relativa al pacco tokenRingLan con
quattro attributi. A fianco degli attributi c’é una lista delle loro proprietà (property list)
con cui si specificano le operazioni che posso essere effettuate su di essi assieme ad altri
dettagli come valori di default, valori iniziali, richiesti o permessi. Ad esempio in
Fig.3.8.2 é specificato che il valore dell’attributo tokenRingBandwidth cioe’ la
larghezza di banda del tokenring va rimpiazzato da un valore di default nel caso nessun
valore specifico fosse indicato. L’attributo tokenRing CardPrice cioe’ il prezzo della
carta tokenring puo’ essere solamente letto (GET) ma non modificato. L’attributo
tokenRingID cioe’ l’identificatore tokenring puo’ assumere valori compresi fra i valori
limite indicati da 000000 e xxxxxx. Infine l’attributo tokenRingCounter cioe’ contatore
tokenring ha un valore iniziale di zero. La maschera token Ring Bypass è una maschera
di azione che richiede di bypassare una host station collegata con il token ring nel caso in
cui in essa si siano verificati certi errori/guasti (al fine di isolarla e evitare che gli
errori/guasti si propaghino alle altre stazioni nel ring). La maschera di notifica
tokenRingBeaconing fa riferimento all’ emissione di un allarme da parte di una stazione
del token ring perché in procinto di andare fuori servizio. Il comportamento specificato
in lingua piana dopo la parola chiave DEFINED AS fornisce l’informazione aggiuntiva
che il tokenRing in questione é connesso ad una rete LAN di cui fanno parte altri
tecnologie (e.g. Ethernet).
3.9 La sintassi Abstract Synthax Notation One (ASN.1):
descrizione sintattica dell’ informazione gestionale a livello
applicativo.
DEFINIZIONE DI ASN.1 : L’ ASN.1 (Abstract Synthax Notation. 1) é una
sintassi astratta per la rappresentazione di dati.
In particolare i dati relativi a
1) oggetti gestiti nelle MIB’s,
2) contenuti nelle PDU’s del protocllo CMIP.
Perché é necessario l’uso dell’ASN.1 ? Perché fornisce tipi di dati comuni ad
applicazioni remote come il Gestore e l’Agente permettendo loro di comunicare.
67
Le notazioni sintattiche ASN.1 sono descritte nella raccomandazione ITU X.208
(1998). L’ASN.1 usa una sintassi formale (BNF, Backus-Nauer Form) e fornisce un
insieme di tipi di dato e costrutti elementari adatti a rappresentare strutture di dati
complesse. Piu’ precisamente fornisce i seguenti tipi di dato:
1.
2.
3.
4.
5.
Simple types (e.g. INTEGER, REAL, BOOLEAN)
Structured Types (composti con tipi semplici)
Tagged Types (derivati da altri tipi con l’aggiunta di un tag)
Subtypes (puo’ assumere un sottoinsieme di valori di un tipo genitore)
ASN.1 macro (per estendere la sintassi alle necessità di una applicazione
specifica)
La sintassi ASN.1 e’ una sintassi generica che puo’ essere usata nei contesti piu’
svariati anche al difuori della gestione dei sistemi TLC. In questo corso non studieremo i
dettagli della sintassi ASN.1. Ci limitiamo a riconoscere che l’ASN.1 e’ una specie di
linguaggio di programmazione di alto livello (e.g. C++) ma senza gli strumenti per
l’elaborazione delle informazioni.
Come precedentemente indicato il linguaggio ASN.1 é usato nelle maschere
GDMO (in particolare maschere di attributo, azione, notifica).
In un contesto comunicativo OSI-SM la sintassi ASN.1 fu anche introdotta come
risposta alla necessità di trovare un linguaggio semplice atto a descrivere lo scambio di
informazione gestionale a livello applicativo. L’ASN.1 evita di adoperare una
rappresentazione a bits (zero e uno) a livello applicativo. Infatti, a questo livello l’uso di
una rappresentazione a bits comporterebbe livelli di complessità elevati a causa dell’ alto
numero di messaggi e all’accoppiamento fra messaggi in processi interattivi e.g. tipo
request/response. Quindi l’ASN.1 é un linguaggio astratto con un alto livello di
astrazione (simile a quello dei linguaggi di programmazione di alto livello) utilizzato
sia nel modello informativo i.e. descrizione degli oggetti gestiti che nel modello
comunicativo i.e. nello scambio di informazionr gestionale fra Gestore e Agente.
Quest’ultimo aspetto verrà illustrato in seguito. .
68
tokenRing
DERIVED FROM
CHARACTERIZED BY
CONDITIONAL PACKAGE
backbone Lan”;
REGISTERED AS
MANAGED OBJECT
lan Net;
tokenRingLan;
tokenRingRouter PRESENT IF “connected to an FFDI
{1 3 5 8 9 2};
c1-name
MANAGED OBJECT CLASS
DERIVED FROM
c2-name
;
CHARACTERIZED BY
p1-name
;
CONDITIONAL PACKAGE p2-name
REGISTERED AS
PRESENT IF
“
Plain Language Text
{
registration
“
;;
}
;
Fig. 3.8.1 Maschera di classe (di oggetti gestiti). Grafo orientato con nodi di tre tipi: Parole
chiave, carattere tipografico di punteggiatora, nome o frase autoesplicante.
69
tokenRingLan
BEHAVIOR
ATTRIBUTES
ACTION
NOTIFICATION
PACKAGE
tokenRingLanBeh
tokenRingBandwidth
tokenRingCardPrice
tokenRingID
tokenRingCounter
tokenRingBypass
tokenRingBeaconing
Propery List
tokenRingLanBeh
DEFINED AS
REPLACE -WITH- DEFAULT,
GET,
PERMITTED VALUES 0000-xxxx
INITIAL VALUE 0;
“ This token ring connects to other LAN segment ”;
Fig.3.8.2 Maschera di pacco. La registrazione non e’ indicata
(facoltativa per pacchi obbligatori). Attributi, gruppi di
attributi, azioni, notifiche sono ulteriormente dettagliati in altre
maschere. Le proprieta’ degli attributi (Property list) sono
incluse nella maschera.
tokenRing Bandwidth ::= INTEGER
tokenRingCardPrice ::= SET OF INTEGERS
tokenRingID ::= tokenRingAddress
tokenRingAddress ::= OCTET STRING SIZE (4)
tokenRingBandwidth
ATTRIBUTE
WITH ATTRIBUTE SYNTAX INTEGER
REGISTERED AS
(135892)
tokenRingCardPrice
ATTRIBUTE
WITH ATTRIBUTE SYNTAX SET OF INTEGERS
REGISTERED AS
(135893)
tokenRingID
ATTRIBUTE
WITH ATTRIBUTE SYNTAX tokenRingAddress
REGISTERED AS
(135894)
Fig.3.8.3 Esempio di maschera di attributo. (NOTA: i numeri di registrazione sono arbitrari)
70
3.10 La denominazione/creazione/cancellazione di un oggetto
gestito: la maschera di legame (Paragrafo facoltativo)
Il processo di relazionare fra un RDN e un altro RDN superiore si chiama “Name
Binding” (Legame di Nome). La specifica della relazione di contenimento fra due oggetti
gestiti é espressa da una “Name Binding Template” (Maschera di Legame). Quindi la
maschera di legame e’ un costrutto che specifica la relazione di contenimento fra oggetti
gestiti.
•
Esempio di maschera di legame
La Fig.3.10.1 mostra una maschera di legame relativa alla denominazione di un
oggetto gestito istanza della classe tokenRing (indicata come SUBORDINATE OBJECT
CLASS cioè CLASSE dell’OGGETTO SUBORDINATO o OGGETTO
“CONTENUTO”) contenuto in un oggetto contenitore appartenente alla classe
lanNetwork (indicata come SUPERIOR OBJECT CLASS cioè CLASSE
dell’OGGETTO SUPERIORE o OGGETTO “CONTENITORE”). Un oggetto della
classe tokenRing, ha un DN ottenuto concatenando il suo RDN “workstationID = valore
specifico” (e.g. workstationID = WS2345) con l’ RDN ottenuto attribuendo un valore
all’attributo distintivo della classe superiore lanNetwork
Inoltre la mashera di legame può utilizzarsi per specificare la creazione (parola
chiave « CREATE ») di un nuovo oggetto, istanza della SUBORDINATE OBJECT
CLASS. Il costrutto « WITH-AUTOMATIC-INSTANCE-NAMING » significa che nella
creazione di un nuovo oggetto (e.g. su richiesta da un Gestore) il suo DN verrà creato
automaticamente (e.g. dall’Agente) cioè il Gestore comanda all’Agente di creare un certo
oggetto della classe subordinata e il sistema ne stabilisce il DN (notificato poi al
Gestore).
La maschera può anche utilizzarsi per distruggere o cancellare un oggetto
esistente (parola chiave « DELETE »). Nella maschera di Fig. 4.10.1 la cancellazione di
un oggetto e’ possibile solo se l’oggetto da cancellare non contiene a sua volta nessun
altro oggetto (ONLY-IF-NO-CONTAINED-OBJECT) cioè non si possono cancellare
due oggetti con un sol colpo! Se si tenterà di effettuare una cancellazione di un oggetto
contenente un altro oggetto apparirà un segnale di errore.
71
tokenRingNaming
SUBORDINATE OBJECT CLASS
SUPERIOR OBJECT CLASS
WITH ATTRIBUTE
BEHAVIOR
CREATE
DELETE
REGISTERED AS
workstationIDnaming
DEFINED AS
NAME BINDING
tokenRing AND SUBCLASSES ;
lanNetwork ;
workstationID ;
workstationIDnaming ;
WITH-AUTOMATIC-INSTANCE-NAMING
ONLY-IF-NO-CONTAINED-OBJECTS
{ 1 3 5 8 9 20 } :
BEHAVIOR
“This is unique identifier” ;
Fig.3.10.1 Maschera di legame (Name binding) fra oggetti appartenenti alle
classi tokenRing e lanNetwork. L’attributo distintivo della classe tokenRing é
workstationID. Un valore specifico assegnato a workstationID (vedi la
relativa maschera di attributo per la sintassi) identifica il RDN dell’oggetto
inferiore o contenuto. Un nome univoco (DN) per questo oggetto si forma
concatenando il suo RDN con l’ RDN ottenuto attribuendo un valore
all’attributo distintivo della classe superiore lanNetwork. BEHAVIOR specifica
il fatto che il processo “name binding” deve produrre un nome univoco (in
ambito lanNetwork).
3.11 L’albero delle registrazioni e l’“identificatore“ di un
oggetto.
DEFINIZIONE di REGISTRAZIONE. Si chiama REGISTRAZIONE il
processo di assegnazione ad un elemento di informazione gestionale (e.g. un pacco o
un attributo o una operazione), di un valore globalmente univoco espresso come
stringa di interi.
Quindi la registrazione si esprime graficamente come una sequenza di numeri interi
opportunamente scelti secondo una procedura che spiegheremo tra poco. Questa
sequenza di numeri é anche chiamata «identificatore di oggetto» (object identifier, in
inglese) ma, in questo caso, il termine «oggetto» va inteso non come istanza di una classe
di oggetti ma come un qualsiasi «elemento di informazione gestionale» e.g. un attributo,
una azione etc. Quindi questo identificatore e’ chiamato impropriamente «identificatore
di oggetto» se per oggetto si intende un oggetto in senso OSI..
A cosa serve l’identificatore ? Nel modello informativo l’identificatore appare in
ogni maschera GDMO, dove segue il nome chiave REGISTERED AS. Ad esempio
nella maschera GDMO della classe “managedElement” che modellizza la risorsa reale
“elemento di rete” si trova il costrutto:
72
REGISTERED AS {0.0.13.3100.0.3.3}
La sequenza di numeri interi che costituisce l’identificatore viene costruita sequendo
una procedura standard basata su un “albero delle registrazioni”, accettato su base
internazionale, in modo tale da garantire una sequenza di registrazione unica per ogni
elemento di informazione. Ogni nodo dell’albero e’ caratterizzato dal nome di una
“autorita’ di registrazione” (registration authority) che assegna un numero (intero)
univoco a quel nodo. Le cosidette “autorità di registrazione” possono essere di diversa
natura e.g. possono rappresentare chi ha generato l’informazione (ente di
standardizzazione come ITU o ISO), oppure dove si trova l’informazione
(Raccomandazione emessa da uno di questi enti). La Fig.3.11.1 mostra come, seguendo
un opportuno cammino nell’ albero delle registrazioni dall’ alto verso il basso si possa
ottenere una sequenza di numeri globalmente univoca. Notare che la radice dell’albero
non possiede una caratterizzazione specifica, quindi, convenzionalmente, il punto di
partenza del cammino dall’alto verso il basso e’ uno dei tre nodi indicati con i
numeri 0, 1, 2 appartenenti al primo strato sotto la radice. Questo significa che tutti
gli identificatori sono sequenze di numeri che cominciano con 0, 1 oppure 2. Ad esempio
le sequenze di registrazione delle raccomandazioni ITU cominciano con 0 mentre le
classi, attributi etc. specificati nella serie X.700 prodotta congiuntamente da ITU e ISO
cominciano con 2.
Tornando all’esempio della classe elemento di rete specificata nella
raccomandazione ITU-T M.3100 si trova il seguente identificatore: 0 (ITU) 0
(Raccomandazione) 13 (Raccomandazioni di tipo M) 3100 (Numero della
raccomandazione) 0 (la raccomandazione è relativa a un “Modello informativo”) 3
(indica “Object Class” all’interno della raccomandazione M3100)
73
ITU (0)
Recommendation (0)
A(1) B(2)
ISO (1)
Standard (0)
JOINT ITU-ISO (2)
Member body (2)
M(13)
3100
Carta Circuitale
(Classe Circuit
Pack):
REGISTERED AS:
0.0.13.3100.0.3.30
Fig.3.11.1 Rappresentazione parziale di un albero delle registrazioni.
Ogni nodo rappresenta una “autorita’ amministrativa “ che fornisce un
numero di registrazione ai nodi nel suo sottoalbero.
3 (Managed Element, rappresentativo dell’elemento reale Network Element). Quindi
la sequenza di registrazione é: 0 0 13 3100 0 3 3. La classe circuit pack che ha numero 30
nella raccomandazione M.3100, ha sequenza di registrazione: 0 0 13 3100 0 3 30.
3.12 Operazioni di scoping e filtraggio
In un processo di gestione é importante accedere a sottoinsiemi degli oggetti
gestiti i cui nomi sono contenuti nell’albero dei nomi. Piu’ specificamente, lo scambio di
informazione gestionale fra gestore e agente talvolta prevede che una richiesta
formulata dal gestore sia rivolta simultaneamente a più oggetti gestiti.
Ad esempio, una singola operazione di lettura tipo “m-get” o di modifica di
valore di un attributo tipo “m-set” (vedi dopo) può permettere al gestore di leggere o
cambiare lo stato di tutte le interfacce in uno switch. Questa operazione é possibile e si
chiama operazione di “scoping”. L’operazione di scoping permette di selezionare gli
oggetti subordinati ad un oggetto scelto come oggetto “base” e ubicati nelle seguenti
posizioni nell’albero dei nomi:
1) livello n-esimo sotto la base
2) livelli compresi fra il livello n-esimo e il livello m-esimo sotto la base
3) tutti i livelli sotto l’oggetto base (sotto-albero).
74
L’operazione di filtraggio é analoga all’operazione di scoping ma é piu
restrittiva. L’operazione di filtraggio infatti seleziona fra gli oggetti “scoped” (rispetto ad
un cero oggetto base) quegli oggetti che soddisfano una serie di criteri aggiuntivi oltre ai
criteri di scoping. Ad esempio il filtraggio può imporre le condizioni che l’oggetto gestito
in un certo sotto-albero appartenga alla classe equipment e sia realizzato dalla
compagnia HP.
3,13 Polimorfismo e Allomorfismo
•
Polimorfismo
Polimorfismo é la proprità di assumere una molteplicità di forme. Nell’
ambito della metodologia orientata agli oggetti, polimorfismo significa che la stessa
operazione ha significato/implementazione diversa in funzione della classe (o
sottoclasse) che la esegue. Facciamo un esempio che si addice al nostro mondo
accademico. Consideriamo la classe «studenti universitari» e le sottoclassi: «studenti di
ingegneria», «studenti di medicina», «studenti di architettura». Ricordiamo che fra la
«classe» e ogni «sottoclasse» esiste una relazione di ereditarietà. Consideriamo poi la
operazione «valutazione compiti in classe» caratteristica della classe «studenti
universitari». Questa operazione deve essere effettuata per tutti gli studenti cioè studenti
di ingegneria, medicina e architettura. Diciamo che essa viene «ereditata» da tutte le
sottoclassi. Tuttavia ogni facoltà ha i suoi criteri di valutazione, quindi la stessa
operazione («valutazione compiti in classe») viene implementata in modo diverso a
seconda della sottoclasse che la effettua. Questo tipo di relazione fra una certa
“richiesta di operazione” e “metodo di operazione” (che varia a seconda di che riceve la
richiesta e effettua poi la operazione) viene chiamata polimorfismo e le sottoclassi sono
dette «polimorfiche». La Fig. 3.13.1 mostra un esempio di polimorfismo fra l’operazione
«calcolo area» caratteristica della classe «figure geometriche piane» implementata in tre
modi diversi dalle tre sottoclassi cerchio, rettangolo e quadrato.
Vediamo ora come il polimorfismo non e’ solo una curiosità tipica della
metodologia orientata agli oggetti ma e’ una proprietà molto importante con vaste
ripercussioni nello sviluppo del software gestionale. Ad esempio una applicazione
gestionale di monitoraggio di una connessione circuitale (connection monitor application)
può richiedere un'unica operazione generica di monitoraggio (definita nella classe
“connection”) ed ottenere diverse esecuzioni dell’operazione stessa da parte di istanze di
diverse sottoclassi e.g. connessione ATM, connessione X.25, connessione IP etc. Quindi
in corrispondenza di una stessa richiesta generica si ottengono più esecuzioni di
operazione specifiche.
Concludendo, la proprietà del polimorfismo posseduta da un modello informativo
orientato agli oggetti permette di fare quanto segue: Una applicazione gestionale viene
programmata in base alla semantica di una superclasse ma ottiene esecuzioni del
programma appropriate a (cioè effettuate da istanze appartenenti a) specifiche sottoclassi.
75
POLIMORFISMO
OPERAZIONE o
SERVIZIO:
Calcolo Area
CLASSI
CERCHIO
METODO o
ALGORITMO o
IMPLEMENTAZIONE
PI*Raggio*Raggio
RETTANGOLO
Altezza*Larghezza
QUADRATO
Lato*Lato
Fig. 3.13.1
•
Allomorfismo o comportamento allomorfico di un oggetto gestito.
Nella raccomandazione X.720 del 1992, l’ITU-T definisce allomorfismo come
la capacità posseduta da un oggetto gestito, istanza di una classe A, di poter essere
gestito come istanza di una classe B, diversa da A. Il particolare la classe B può essere
una superclasse di A. La classe B e’ chiamata una classe allomorfa dell’oggetto gestito.
L’allomorfismo, tipico di un modello informativo orientato agli oggetti, puo’
offrire grossi vantaggi in termini di utilizzabilità di un sistema Gestore. In pratica
permette ad un vecchio Gestore di gestire anche apparati di nuova generazione.
Ad esempio, se dico che una nuova stampante laser modello HP314 ubicata nella
stanza 456 nella Facltà di Ingegneria Elettronica dell’Università di Roma II ha un
comportamento allomorfico voglio dire che essa non solo è una istanza della sottoclasse
«Laser Printer» ma anche della superclasse «Printer» o della classe ancora superiore
«Output Device». Come si può sfruttare questa proprietà da un punto di vista gestionale?
Come segue.
Supponiamo che all’università esista una vecchia applicazione gestionale OSI-SM
capace di gestire stampanti della classe «Printer». Supponiamo ora che arrivi una nuova
stampante laser tipo HP314 con caratteristiche specificate nella sottoclasse «Laser
76
Printer». Sfruttando il comportamento allomorfico della nuova stampante posso dire che
la vecchia gestione non è inutilizzabile ma funziona nonostante il cambiamento di
classe (seppur con una gestione incompleta poichè non gestisce le caratteristiche
aggiuntive introdotte dalla stampante laser) cioè la vecchia gestione della superclasse
«Printer», e’ capace di gestire la sottoclasse «Laser Printer» nonostante la presenza
di nuove caratteristiche, a lei sconosciute.
Se non esistesse l’allomorfismo si dovrebbe semplicemente dire che, allorchè
viene introdotta la nuova stampante laser, la vecchia applicazione gestionale non è più
utilizzabile perchè si trova di fronte una nuova classe di oggetti a lei sconosciuta
Ovviamente l’allomorfismo offre una soluzione utile ma non-ottimale, migliorabile
modificando la vacchia gestione (se così si desidera).
•
Paragone poliformismo-allomorfismo
Un paragone fra polimorfismo e allomorfismo rivela nei due casi una risposta
opposta dell’istanza (di una classe). Nel polimorfismo l’istanza risponde ad una richiesta
di operazione a livello superclasse manifestando la sua appartenenza ad una sottoclasse
(risposta specifica della sottoclasse). Nell’allomorfismo l’istanza risponde ad una
richiesta di operazione a livello superclasse nascondendo la sua appartenenza ad una
sottoclasse (risposta appropriata alla superclasse)
77
3.14 Le basi di dati (MIB, Mangement Information Base)
•
Definizione di MIB
Gli oggetti gestiti sono immagazzinati in memorie chiamate “MIB” (Management
Information Base).
DEFINIZIONE di MIB : Una Management Information Base (MIB) é una base dati
che contiene un insieme di « oggetti gestiti » rappresentazioni astratte delle risorse
reali che devono essere gestite in un sistema TLC.
In particolare, si tratta di oggetti gestiti contenuti in un sistema aperto gestito
(Vedi Fig.3.1.1. A,B), sui quali possono effettuarsi operazioni gestionali richieste da un
sistema aperto gestore utilizzando messaggi strutturati secondo protocolli comunicativi
standardizzati (e.g. CMIP, Common Management Information Protocol).
Qui adottiamo il termine MIB nell’ambito di un modello «Object Oriented»
basato su collezioni di oggetti mutuamente relazionati da relazioni specifiche e.g.
« relazioni di ereditarieta’ » Tuttavia il termine MIB é anche usato in contesti che nulla
hanno a che fare con la metodologia “Object-Oriented”. Si tratta di contesti nei quali gli
oggetti sono semplicemente collezioni di dati prive delle proprietà relazionali tipiche
dell’orientamento agli oggetti. Ad esempio il termine MIB viene usato per la basi dati
nelle reti internet con protocollo SNMP (Simple Network Management Protocol).
•
Caratteristiche di una MIB
Ovviamente una MIB ha le stesse caratteristiche del modello informativo
precedentemente descritto, cioe’
1) linguaggio (GDMO/ASN.1 nel Modello OSI-SM) per descrivere gli oggetti
gestiti ,
2) struttura logica per definire l’organizzazione degli oggetti gestiti (alberi di
ereditarietà, contenimento e registrazione) e
3) denominazione degli oggetti gestiti per individuare in modo univoco ciascun
oggetto gestito (albero dei nomi)
Il letteratura si usa rappresentare una MIB con una struttura ad albero che
interconnette gli oggetti gestiti (rappresentati da piccoli ellissi o cerchi ubicati nei nodi
della struttura come in Fig.3.14.1). É bene riconoscere subito che si tratta di una
rappresentazione convenzionale che allude all’albero dei nomi precedentemente
illustrato. Cioé la MIB, di per se, é una memoria che contiene l’informazione gestionale
relativa agli oggetti gestiti e al suo interno non esiste nessuna struttura fisica a forma di
albero. Sono gli RDN degli oggetti gestiti che godono della proprietà di essere
mutuamente relazionati tramite relazioni gerarchiche rappresentabili con una struttura ad
albero (albero dei nomi).
78
Notare due aspetti importanti delle MIB :
•
1)
Finora abbiamo parlato di una MIB contenuta nel sistema gestito. In
effetti anche il sistema Gestore deve essere a conoscenza di questa
MIB, anzi di tutte le MIB che egli deve gestire. Quindi teoricamente
dovrebbe esistere una MIB Gestore unione delle MIB di tutti gli Agenti
che fanno capo a quel Gestore. Questo potrebbe richiedere una MIB
Gestore gigantesca. In pratica, ciò accade raramente e la relazione fra
MIB Gestore e MIB gestita é una relazione di tipo dinamico, cioé di
volta in volta il Gestore viene a conoscenza della MIB dell’Agente che
egli gestisce in quel momento.
2)
In pratica ogni MIB opera assieme ad un protocollo di comunicazione
gestionale specifico i.e. una MIB é «management protocol specific».
Ad esempio le MIB OSI si usano assieme al protocollo gestionale
CMIP e hanno una struttura/sintassi diversa dalle MIB SNMP
usate assieme al protocollo gestionale SNMP.
Le MIB OSI
Le MIB’s OSI sono MIB’s orientate agli oggetti che usano il linguaggio
GDMO/ASN.1, hanno una struttura basata sugli alberi di erediarietà e contenimento e gli
oggetti hanno nomi univoci definiti in base all’albero dei nomi. La ITU-T ha pubblicato
standards per MIB’s nei documenti relativi al modello informativo X.721 e M.3100.
Fig. 3.14.1 Rappresentazione simbolica di MIB
79
3.15 Analisi comparativa dei tre alberi: l’albero delle classi,
l’albero dei nomi e l’albero delle registrazioni.
In questo capitolo abbiamo parlato di strutture gerarchiche e di alberi di tre tipi
diversi: l’albero delle classi, l’albero dei nomi e l’albero delle registrazioni.
Per evitare possibile confusione vogliamo ora ricapitolare quanto detto sull’
argomento e mettere in evidenza che si tratta di strutture distinte utilizzate per diversi
scopi, sebbene, in qualche modo, relazionate l’una con l’altra.
L’ albero delle classi si basa sulla proprietà di eredità delle classi e serve a
specificare le classi di oggetti gestiti. L’albero permette la specializzazione di classi già
esistenti (classi “superiori”) in nuove classi (classi “subordinate”) tramite
specializzazione e.g. aggiunta di proprietà. Ciò equivale a dire che le proprietà di una
classe (nodo dell’ albero di ereditarietà) includono tutte le proprietà dei nodi superiori
fino ad arrivare alla radice dell’albero denominata classe “Top” (definita nella
raccomandazione ITU-T X.720).
L’albero dei nomi serve a identificare un oggetto gestito (istanza di una
classe) con un nome globalmente univoco. Il nome é definito come una sequenza di
RDN cioè attributi distintivi e loro valori. L’ubicazione degli oggetti nell’albero dei nomi
é fatta sulla base della relazione di contenimento in modo tale che un oggetto più vicino
alla radice (oggetto superiore) “contiene” un oggetto situato sotto di esso (oggetto
subordinato). Questo significa che i nomi dell’oggetto superiore e dell’oggetto
subordinato vanno menzionati congiuntamente (relazione di legame) nella formulazione
di un nome univoco per l’oggetto subordinato. Notare che la relazione di contenimento
non ha nulla a che fare con la proprietà di eredità. Ad esempio le classi “circuit pack”
e “equipment holder” sono allo stesso livello sotto la classe “equipment” nell’albero delle
classi in Fig 3.5.1 ma una istanza di “circuit pack” é subordinata a una istanza di
“equipment holder” (modellizzazione di una slot) nell’albero dei nomi in Fig..3.6.1.
L’albero delle registrazioni serve ad assegnare un valore globalmente
univoco ad ogni elemento di informazione gestionale. Il valore é una sequenza di
numeri interi.
80
3.16 La gestione orientata agli oggetti (“object-oriented”) e la
gestione basata sui messaggi (“message based”)
(Paragrafo facoltativo)
•
Gli oggetti gestiti e l’ Information Modeling
Abbiamo parlato di creazione di modelli e di entità astratte utilizzate a fini
gestionali. Ora é tempo di riconoscere che tutto cio’ é la specializzazione a problemi
gestionali di un concetto molto piu’ generale che va sotto il nome di “information
modeling” o modeling informativo o creazione di modelli informativi (“information
models”).
Nel tempo, diverse metodologie di modellazione sono state applicate per
sviluppare modelli informativi per la gestione dei sistemi TLC. Una delle metodologie
piu’ importanti é la metodologia “Orientata agli Oggetti” o “a Oggetti” che e’ stata
illustrata in questo capitolo. Quando si dice che la gestione di un sistema TLC applica
una metodologia “a oggetti”, oppure e’ basata sull’ «orientamento agli oggetti»
significa dire che si utilizzano modelli gestionali delle risorse gestite reali dotati di
una struttura logica formale «a oggetti ».
Il modeling informativo basato sull’orientamento agli oggetti parte dall’esame di
una realtà complessa come un sistema reale TLC da gestire per poi astrarre dagli
elementi reali costituitivi di questa realtà un insieme di oggetti astratti che vengono
idendificati, relazionati l’uno con l’altro e classificati in una struttura formale. Il
sistema viene poi analizzato sulla base di questa struttura formale i cui elementi
costitutivi sono gli oggetti astratti.
L’importanza e popolarità dell’ ”information modeling” nella soluzione dei
problemi gestionali dei sistemi TLC sono principalmente dovute al fatto che la
utilizzazione di modelli generici basati su processi formali di astrazione, permette di
sviluppare tecniche/standards di gestione indipendenti dal particolare venditore o
tecnologia implementativa (gestione reti) o dal particolare scenario di servizio
(gestione servizi).
•
Cenni storici sull’ information modeling in generale.
Inizialmente, lo sviluppo di modelli informativi fu introdotto per la soluzione di
problematiche relative alle basi dati ed ai sistemi di business. Ad esempio, si riconosce
facilmente che i dati da immagazzinare in una base dati non sono buttati a caso dentro un
contenitore ma devono essere opportunamente organizzati in modo tale da poter essere
facilmente identificati, immagazzinati e manipolati dal gestore della base.
Nei primi tempi i processi di modellizazione di questi sistemi erano un arte
personale basata su principi euristici, ma, col tempo, si é persa questa caratteristica di
soggettività ed é venuta sviluppandosi una disciplina ben definita che ha portato alla
formulazione di modelli molto accurati utilizzabili nei campi piu’ disparati. Ad esempio
81
abbiamo visto che nella gestione dei sitemi TLC questi modelli sono stati standardizzati
da enti internazionali.
In letteratura esiste ampia documentazione sull’argomento dell’information
modeling. Ad esempio, si puo’ vedere: Flavin,M. ” Fundamental Concepts of Information
Modeling”’ Prentice-Hall, Englewood Cliffs, NJ, 1981.
Tutto questo é vero in generale e puo’ essere specializzato al caso particolare
della gestione delle reti e dei servizi di telecomunicazione.
NOTA : Senza entrare nei dettagli ricordiamo che oggi, nella la progettazione e
analisi di sistema a livello industriale ci sono tre tipi di metodologie orientate agli oggetti
Booch 93,
OMT (Object Modeling Technique) sviluppata da Rumbaugh,
OOSE (Object Oriented Software Engineering) sviluppata da Jacobson.
Quest’ ultima é stata utilizzata principalmente per l’analisi di sistemi di business
e.g. dal Tele-Management Forum. Esiste anche una metodologia che combina le
potenzialità delle tre tecniche: Unified Modeling Language (UML) adottato dal Object
Management Group (OMG).
Le metodologie a oggetti sono ampliamente documentate in letteratura. Si
consigliano due testi sull’argomento:
G.Booch, “Object Oriented Analysis and Design with Applications”, Addison Wesley
Longman Inc., 1994,
J.Rumbaugh, “Object Oriented Modeling and Design”, Prentice Hall, 1991.
•
Metodologie gestionali «Message-based»: il linguaggio TL1 della Bellcore.
Esistono metologie gestionali che non utilizzano l’orientamento agli oggetti (OO).
Ci sono ad esempio metodologie gestionali , chiamate “Message-based” cioé “a
Messaggi”o «basate sui Messaggi» o « orientate ai Messaggi » (OM), che definiscono
direttamente i vari tipi di messaggi gestionali scambiati fra Gestore e Agente. Al
contrario, le metodologie OO, definiscono un modello informativo per gli oggetti gestiti e
un set limitato di operazioni gestionali (e.g. get, set etc.) rappresentate in forma modulare
tramite PDU (Protocol Data Units). Le PDU hanno una struttura a «zone» specificata dal
particolare protocollo comunicativo e.g. CMIP o SNMP. I messaggi gestionali si
ottengono popolando «zone» delle PDU con l’informazione appropriata contenuta
nel modello informativo. Quindi nelle metodologie OO l’enfasi e’ sulle caratteristiche
degli oggetti (che sono specificate in gran dettaglio nel modello informativo) mentre nelle
metodologie OM l’enfasi e’sull’informazione gestionale che attraversa l’interfaccia
Gestore-Agente.
82
In generale le prime sono piu’ complicate ma permettono una gestione molto piu’
dettagliata delle seconde. Facciamo un esempio. Supponiamo che un oggetto gestito entri
in uno stato di allarme a causa di un guasto. Nella metodologia OM un messaggio di
notifica verra’ inviato dall’Agente al Gestore con l’indicazione che un guasto si e’
verificato nell’oggetto gestito ma senza offrire dettagli circa la natura del guasto i.e.
modifica delle caratteristiche dell’oggetto gestito e degli oggetti ad esso relazionati
dovuta al guasto e/o le operazioni possibili per poterlo riparare. Ciò sarà invece possibile
in base all’informazione derivata dal modello informativo e contenuta in una PDU della
metodologia OO.
Gli standards gestionali “per-Messaggi” piu’ comuni sono il Transaction
Language 1 (TL1) inventato dalla Bellcore (USA) o il Man Maschine Language (MML)
presentato nella raccomandazione ITU-T Z.300.
Negli anni 80 la compagnia americana Bellcore aveva la responsabilità di stabilire
gli standards per tutti i gestori regionali del sistema telefonico nazionale (RBOC’s,
Regional Bell Operating Companies). Nel 1984 la Bellcore decise di introdurre un
linguaggio uomo-Risorsa TLC per la gestione degli elementi di rete cioe’ l’uomo
(gestore) parla alla Risorsa TLC (gestita) con un linguaggio gestionale (linguaggio uomoRisorsa TLC). Tale linguaggio, chiamato TL1 (Transaction Language 1), e’ basato su
messaggi gestionali in linguaggio ASCII (American Standard Code for Information
Interchange dell’American National Standard Institute, ANSI) che stabilisce un mapping
fra testo alfanumerico (adottato dal gestore) e ottetti di bits (trasmessi alla Risorsa TLC) e
quindi puo’ essere compreso sia dalle Risorse TLC gestite che dagli uomini gestori..
Nell’85 uscirono i primi sistemi operativi di supporto (OSS, Operation Support System)
con interfacce TL1 e in risposta, i costruttori di apparati cominciarono a introdurre lo
stesso tipo di interfacce negli elementi di rete da gestire.
Esercizi (Capitolo 3)
1.
Nel Modello OSI-SM cosa si intende per aspetti informativi ?
2.
Di che cosa tratta il Modello Informativo OSI-SM ? Cosa é la Struttura della
Informazione Gestionale (Structure of Management Information) ?
3.
Casa é un oggetto gestito ?
4.
Cosa sono le caratteristiche di un oggetto gestito ? Come si chiamano i quattro
gruppi di caratteristiche ?
5. Cosa é una classe di oggetti gestiti ?
6. Cosa é l’istanza di una classe di oggetti gestiti ? Cosa é il processo di istanziazione di
una classe ?
7. Cosa é una maschera GDMO ? Cosa significa GDMO ?
83
8.
Quanti tipi di maschere sono stati introdotti e a cosa servono ?
9.
Una maschera di classe rappresenta una classe di oggetti gestiti utilizzando un
modello informativo orientato agli oggetti. Quali sono gli elementi di una
maschera di classe che indicano chiaramente l’utilizzazione di un modello
informativo orientato agli oggetti?
10.
Cosa é un pacco e cosa é una maschera di pacco ?
11.
Che differenza c’é fra maschere di pacco condizionali e obbligatorie ?
12.
I pacchi condizionali sono stati introdotti per minimizzare il numero di sottoclassi
che é necessario definire. Spiegare come.
13.
Cosa é una azione e una maschera di azione ? Che differenza c’é fra azione e
operazione (gestionale)?
14.
16.
Cosa é la sintassi ASN.1 (Abstract Synthax Notation Number 1) e perché si
chiama astratta?
In una rappresentazione di un oggetto gestito la ASN.1 é utilizzata da sola o
assieme al linguaggio GDMO? Spiegare.
Quali sono alcuni tipi di dato definiti dalla sintassi ASN.1 ?
17.
Perché é necessario usare ASN.1 ?
18.
Quale é la differenza principale fra il linguaggio descrittivo ASN.1 e un
linguaggio di programmazione di alto livello ?
19.
Che differenza c’é fra « linguaggio » GDMO e « linguaggio » ASN.1?
20.
Il linguaggio ASN.1 tiene conto del fatto che il modello informativo é orientato
agli oggetti ?
21.
Cosa significa ereditarietà ? In un una maschera di pacco dove viene applicato il
pricipio di ereditarietà tipico di una tecnologia orientata agli oggetti? (Specificare
anche la parola chiave)
22.
Cosa é l’ albero di ereditarietà ? Si tratta di una ereditarietà fra classi di oggetti o
fra oggetti ?
23.
Il criterio di ereditarietà puo’ essere sfruttato per derivare classi «specifiche» o
classi di un modello di rete specifico (cioé rappresentativo di reti implementate
con tecnologie implementative specifiche) da classi «generiche» o classi di un
modello di rete generico (cioé rappresentative delle caratteristiche gestionali
comuni agli apparati delle reti TLC, indipendentemente dalle tecnologie
implementative della rete stessa). Spiegare come.
15.
84
24.
Cosa é un albero di contenimento ?
25.
Cosa é l’albero delle registrazioni ?
26.
Cosa é l’albero dei nomi ?
27.
Cosa é il nome univoco di un oggetto gestito ?
28.
Cosa é una MIB ?
29.
Quali sono le tre caratteristiche principali di una MIB ?
30.
31.
32.
Esistono una MIB Agente e una MIB Gestore oppure esiste solamente una MIB
Agente che contiene gli oggetti da gestire?
Quale é il linguaggio usato in una MIB OSI per rappresentare gli oggetti gestiti ?
Una MIB é una base dati che viene usata assieme ad un protocollo gestionale
quando i dati devono essere trasferiti. Posso usare lo stesso tipo di MIB assieme a due
protolli gestionali diversi ? Per esempio, posso usare una MIB OSI assieme al
protocollo gestionale OSI CMIP e al protocollo gestionale SNMP ?
85
CAPITOLO 4
Modello OSI per la gestione di sistema:
sottomodello comunicativo
4.1 Entità Applicativa per la Gestione di Sistema (System
Management Application Entitiy, SMAE) e suoi Elementi di
Servizio ACSE, ROSE, CMISE e SMASE.
•
Processi gestionali reali (System Management Application Process, SMAP) e
entità gestionali astratte (System Management Application Entity, SMAE)
Come già detto in precedenza, il Sottomodello Comunicativo del Modello OSISM modellizza/standardizza il trasferimento di informazione gestionale fra processi
applicativi gestionali (System Management Application Processes, SMAP) residenti
in nodi elaborativi remoti interconnessi da una rete dati. Un processo reale SMAP è un
elemento di un sistema reale aperto che svolge attività di data processing relativamente
ad una particolare applicazione gestionale e.g. una applicazione Gestore residente in un
sistema aperto che gioca il ruolo di gestore o una applicazione Agente residente in un
sistema aperto gestito. Lo standard “OSI-SM/sottomodello comunicativo” crea modelli
astratti di processi SMAP, modelli che ne ritengono solo le caratteristiche di
“Interconnessione fra Sistemi Aperti” (“Open Systems Interconnections”, OSI). Si tratta
quindi di modelli OSI dei processi SMAP. Le componenti di questi modelli OSI
residenti al settimo livello della pila OSI sono chiamate entità applicative gestionali
(System Management Application Entities, SMAE). Quindi le SMAE sono le entità
applicative di modelli OSI dei processi reali SMAP.
Facendo riferimento alla Fig.4.1.1 e ricordando che nel modello di riferimento
OSI-RM ogni strato fornisce servizi allo strato superiore, si riconosce subito che le entità
astratte SMAE, residenti al settimo livello della pila OSI, forniscono servizi direttamente
ai processi SMAP reali sovrastanti (convenzionalmente posizionati al di sopra della pila
OSI). Viceversa i processi reali SMAP richiedono servizi alle entità astratte SMAE
sottostanti.
•
La suddivisione delle SMAE in quattro elementi di servizio (ASE,
Application Service Element))
Nello standard OSI-SM/sottomodello comunicativo ogni entità SMAE è
suddivisa in quattro moduli chiamati Elementi di Servizio (Application Service
Element, ASE) che cooperano secondo una logica gestita da un Centro di controllo (Vedi
Fig. 4.1.1). Ogni Elemento di Servizio ASE ha un compito diverso ma tutti gli Elementi
di Servizio, assieme al sottomodello informativo descritto nel Cap.3, sono necessari e
86
contribuiscono allo scambio e all’ interpretazione dell’ informazione gestionale
scambiata fra SMAE Gestore e Agente. É importante notare che sia gli Elementi di
Servizio ASE sia il sottomodello informativo sono necessari allo scambio/interpretazione
dell’informazione fra SMAE cioè il sottomodello informativo e il sottomodello
comunicativo sono strettamente correlati. Ma torneremo su questo punto più in là.
Ma perché ogni SMAE é suddivisa in componenti modulari? La ragione di fondo
e’ sempre la stessa ed e’ basata sul principio, ben noto nell’ingegneria del software, di
suddividere un programma di elaborazione numerica complesso in una molteplicità di
componenti modulari più facili da progettare/utilizzare. Inoltre la modularità dei
componenti offre il seguente beneficio: alcuni moduli possono essere comuni a
programmi diversi e quindi uno stesso modulo può essere ri-utilizzato in programmi
diversi. Nel nostro caso una SMAE strutturata in modo modulare offre la possibilità
che alcuni suoi moduli possano essere ri-utilizzati per applicazioni gestionali diverse.
Prendendo in prestito un concetto tipico della scienza delle costruzioni possiamo
metaforicamente dire che creare moduli equivale a creare «building blocks» (blocchi
costitutivi o mattoni) utilizzabili/ri-utilizzabili per effettuare costruzioni» di vario tipo
(nel caso nostro uno stesso modulo può utilizzarsi per realizzare applicazioni gestionali di
diversi tipi). Data la grande varietà di applicazioni gestionali (basti pensare alla miriade
di funzioni di gestione contenute nel modello FCAPS) sarebbe impossibile sviluppare un
modello/standard per ogni singola applicazione gestionale mentre è molto più utile
sviluppare un modello/standard per un modulo riutilizzabile in applicazioni diverse.
Per servizi gestionali interattivi, il modello OSI-SM prevede quattro Elementi di
Servizio ASE di cui i primi tre hanno una struttura modulare e sono comuni a tutte le
funzioni gestionali mentre il quarto è specifico della funzione gestionale che di volta in
volta si vuole realizzare. I quattro Elementi di Servizio ASE sono (Vedi L.G. Raman,
“Fundamentals of Telecommunications Network Management”, IEEE Press, 1999,
pag.65):
1. ACSE (Association Control Service Element).
2. ROSE (Remote Operation Service Element)
3. CMISE (Common Management Information Service Element)
4. SMASE (System Management Application Service Element)
Come già specificato in nel modello di riferimento OSI-RM una relazione
cooperativa fra entità applicative si chiama “associazione”. La Fig. 4.1.1 mostra una
associazione fra due SMAE di cui una emette richieste (SMAE Gestore) e l’altra riceve
richieste e conseguentemente invia risposte (SMAE Agente).
Lo scambio di messaggi gestionali fra SMAE Gestore e SMAE Agente residenti
in sistemi gestionali remoti coinvolge tutti i livelli della pila OSI come già visto nel
Cap.1, inoltre coinvolge tutti e quattro gli Elementi di Servizio ASE. La Fig.4.1.1 mostra
simbolicamente come l’insieme degli elementi ACSE, ROSE, CMISE e SMASE sia
usato per costruire i messaggi gestionali scambiati fra SMAE Gestore e SMAE Agente o
87
meglio, sia usato per realizzare la struttura modulare di un messaggio gestionale MAPDU (Management Application Protocol Data Unit). Le attività dei quattro Elementi di
Servizio ASE sono coodinate da un centro di controllo “C”.
I quattro Elementi di Servizio ASE summenzionati servono per servizi interattivi
standardizzati dal Modello OSI-SM. Tuttavia l’elemento di servizio ACSE é utilizzato
per stabilire una associazione Gestore-Agente anche per servizi non interattivi come i
servizi per il trasferimemento file (“file-transfer” services) o per trasferimenti di “bulk
data”. I servizi di trasferimento file usano un ASE denominato File Transfer Access and
Management (FTAM) mentre quelli per il trasferimento di “bulk data” usano un ASE
denominato Reliable Transfer Service Element (RTSE)
•
Utilizzazione dei quattro Elementi di Servizio ASE
I quattro Elementi di Servizio ASE sono utilizzati come segue:
L’elemento ACSE, Elemento di Servizio per il Controllo d’Associazione fra
SMAE, serve ad iniziare (set-up) o terminare (release) una associazione fra SMAE.
Una volta effettuata un associazione fra SMAE, l’elemento ROSE, Elemento di
Servizio per l’ effettuazione di Operazioni Remote, stabilisce un protocollo generico
per emettere richieste e ricevere risposte fra SMAE remote (struttura “richiesta-risposta”
o “request-reply”). Si tratta quindi di un protocollo del tipo RPC (Remote Procedure Call)
ben noto nell’ingegneria del software di sistemi distribuiti i.e. in sistemi dove le
operazioni vengono effettuate in sedi remote rispetto alla sede del richiedente.
L’elemento CMISE, Elemento di Servizio per la fornitura di Informazione
Gestionale Comune (a tutte le funzioni di gestione) specializza ulteriormente la
piattaforma stabilita dall’elemento ROSE indicando il tipo di operazione/notifica di
evento che si vuole effettuare e.g. una operazione sugli attributi di un oggetto gestito (e.g.
leggi valore, scrivi valore di un attributo etc.) o una azione sull’oggetto gestito stesso o
una notifica di un evento (event report). Vedremo che l’elemento CMISE può fornire
undici tipi diversi di “servizi” (e.g. vedi servizi CMIS, Common Management
Information Service, nella Tavola 4.5.1) utilizzabili per tutte le funzioni di gestione e tutti
gli oggetti gestiti: da qui il nome “Common Management Information Service”. La
relazione fra le funzioni di gestione (specificate nel sottomodello funzionale FCAPS) e i
servizi CMIS sarà illustrata allorché parleremo del sottomodello funzionale di OSI-SM.
Infine l’elemento SMASE (Elemento di Servizio per Applicazioni Gestionali
di Sistema) specializza ulteriormente l’ informazione fornita da ROSE+CMISE
aggiungendo ad essa l’informazione specifica della funzione gestionale che si vuole
realizzare (e.g. SMF, System Management Function del modello FCAPS). A differenza
degli altri Elementi di Servizio ASE l’attività dell’ elemento SMASE non è specificata
tramite “definizione di servizi e specifica di protocolli” bensì in termini di fornitura di
informazione relativa ad una particolare SMF (Vedi L.G. Raman, “Fundamentals of
Telecommunications Network Management”, IEEE Press, 1999, pag.68). Più
precisamente l’informazione SMASE va a popolare alcune zone della MA-PDU lasciate
vuote a livello CMISE (zone “place holder” a livello CMISE). Tenendo conto di tutto ciò
forse sarebbe stato meglio adottare l’acronimo SMF-ASE piuttosto che il tradizionale
SMASE! Tutto ciò è spiegato meglio nel par. 4.7 e in Fig.4.7.1.
88
Studieremo in dettaglio gli Elementi di Servizio ASE in seguito, ma prima
vogliamo ancora una volta ricordare che uno dei vantaggi offerti da una SMAE
strutturata con Elementi di Servizio ASE modulari é la possibilità di trattare di volta in
volta un singolo modulo indipendentemente dagli altri e di ri-utilizzare uno stesso
modulo per funzioni gestionali diverse. Ad eccezione dell’elemento SMASE questo è
possibile con ACSE, ROSE e CMISE. Ad esempio una volta stabilita una associazione
fra SMAE Gestore e SMAE Agente tramite ACSE per una certa applicazione gestionale,
questa associazione può ri-usarsi per una applicazione diversa e.g. una stessa
associazione fra SMAE può utilizzarsi sia per una applicazione “gestione guasti” sia per
una applicazione “gestione sicurezza”.
Concludendo: nel formalismo OSI-SM é importante enfasizzare due concetti
fondamentali:
1)
Una volta stabilita una associazione fra SMAE Gestore e SMAE Agente
via ACSE, tutti gli altri tre Elementi di Servizio contribuiscono alla
costruzione di uno specifico messaggio gestionale MA-PDU. Infatti,
l’informazione aggiuntiva fornita da SMASE specializza l’informazione
fornita da CMISE, permettendo a un messaggio gestionale di
implementare una funzione gestionale specifica. A sua volta
l’informazione fornita da CMISE specializza l’informazione fornita da
ROSE indicando se si tratta di operazione su attributi, azione o notifica.
L’elemento ROSE stabilisce una procedura generica “request-reply” del
tipo RPC (Remote Procedure Call) fra due SMAE remote. L’elemento
ACSE stabilisce o abbatte una associazione fra SMAE. Ciò e’ illustrato
in modo simbolico in Fig. 4.1.2. dove si mostra come l’informazione
totale contenuta in una MA-PDU sia il risultato dei contributi di vari
Elementi di Servizio ASE in una sequenza temporale dal basso verso
l’alto
2)
Anche il modello informativo gioca un ruolo importante nello scambio di
informazioni (cioé scambio/interpretazione messaggi) fra SMAE Gestore
e SMAE Agente. Entrambi devono essere a conoscenza dello stesso
modello informativo. Infatti vedremo che ciò che viene effettivamente
trasferito fra le due SMAE è informazione strutturata secondo il
sottomodello informativo e.g. dati contenuti nella MIB descritti con
maschere GDMO espressi in linguaggio ASN.1. Si riconosce quindi una
relazione molto stretta fra sottomodello informativo e sottomodello
comunicativo. Questa caratteristica fa sì che il formalismo OSI-SM
differisca nettamente da altri modelli gestionali i quali usano paradigmi
chiamati “message-based” dove i messaggi gestionali sono strutturati
indipendentemente dalla struttura degli oggetti gestiti nella MIB e
vengono costruiti, trasmessi e interpretati senza l’uso di modelli
informativi. Esempi di questi paradigmi message-based sono il ManMachine Language (ITU, Z.300) o il “Transaction Language 1”
sviluppato dalla Bellcore.
89
SMAP1
SMAP 2
SMAE 2
SMAE1
MA PDU
C
SMASE 1
SMASE2
CMISE1
CMISE2
ROSE1
ROSE2
C
ACSEreq
ACSErsp
STRATO DI PRESENTAZIONE
+ STRATI 1-5
STRATO DI PRESENTAZIONE
+ STRATI 1-5
MEZZO FISICO
Fig. 4.1.1 Scambio di MA-PDU fra SMAE Gestore e Agente. C= Centro di controllo
(Figura ottenuta combinando M.Subramanian, “Network Management”, Addison-Wesley,
2000, Fig.A.11, pag.594 e L.G.Raman, “Fundamentals of Telecommunications Network
Management”, IEEE Press, 1999, Fig. 3.4, pag.67)
90
SMASE
SMASE
CMISE
CMISE
ROSE
ROSE
ACSE
ACSE
ASSOCIAZIONE fra SMAE
Fig. 4.1.2 Diversi ASE contribuiscono a formare un messaggio MA-PDU
91
4.2 I servizi forniti dagli elementi di servizio ASE (Application
Service Element) e le “Unità Funzionali” usate nelle
negoziazioni SMAE Gestore-SMAE Agente per stabilire
una associazione
•
Gli elementi di servizio ASE ….non sono elementari!
Abbiamo precedentemente parlato di Elementi di Servizio ASE come building
blocks cioè come mattoni tutti uguali e quindi utilizzabili a realizzare costruzioni (i.e.
applicazioni gestionali) diverse. Ora dobbiamo riconoscere che il singolo building block
non fornisce un solo servizio ma e’ un elemento capace di fornire una molteplicità di
servizi. Ad esempio vedremo che l’ elemento di servizio CMISE può effettuare la lettura
di alcuni attributi dell’oggetto gestito (servizio “GET”) oppure può modificarne il valore
(servizio “SET”) oppure può riportare il verificarsi di un evento particolare (servizio
“EVENT-REPORT”) etc. cioè l’elemento di servizio CMISE può a sua volta fornire una
varietà di servizi appartenenti ad un catalogo di undici servizi diversi (Vedi Tavola 4.5.1).
•
I servizi forniti da un ASE sono raggruppati in Unità Funzionali
Per facilitare le cose, in ogni elemento di servizio ASE alcuni servizi vengono
raggruppati in Unità Funzionali (Functional Units) introdotte per facilitare il processo
di negoziazione che viene svolto per stabilire una associazione fra SMAE. Questo
significa che al momento di stabilire una associazione la SMAE Gestore e la SMAE
Agente invece di negoziare servizio per servizio esse negoziano “gruppi di servizi”
chiamati “Unità Funzionali”.
Come minimo il processo di negoziazione deve risultare nella realizzazione di
una Unità Funzionale di Base (UFB), costituita da servizi obbligatori che costituiscono
il minimo indispensabile perché l’interfaccia SMAE Gestore - SMAE Agente sia a
norma OSI .
Ad esempio, le due SMAE si accordano per una associazione che garantisca per
l’Elemento di Servizio CMISE, di effettuare operazioni relative alla seguente UFB
(gruppo di servizi obbligatori):
Event-Report,
Get,
Set,
Action,
Create,
Delete.
Questo significa che ogni volta che un interfaccia Gestore-Agente supporta un
servizio CMISE, come minimo, si possono effettuare queste sei operazioni . In aggiunta
a queste, se necessario, le due SMAE associate possono negoziare altre unità funzionali
non obbligatorie come ad esempio la possibilità di effettuare la stessa operazione
92
gestionale su più oggetti diversi (“scoping” o “filtering”) o di effettuare l’autenticazione
di una richiesta originata dalla SMAE Gestore.
4.3
Elemento di Servizio ACSE (Application Control Service
Element) per stabilire una associazione fra SMAE
La gestione delle reti TLC e/o dei loro elementi si basa sullo scambio di
informazione gestionale nell’ambito di una associazione SMAE Gestore - SMAE Agente.
Le SMAE sono modelli astratti di processi gestionali reali SMAP residenti in sistemi
gestionali reali remoti interconnessi da una rete dati. Secondo l’ OSI-SM/sottomodello
organizzativo studiato nel Cap. 2 lo SMAP Gestore risiede nel sistema Gestore e gli
SMAP Agenti risiedono nei sistemi gestiti assieme alle MIB..
Primitiva di Servizio
PDU
A-ASSOCIATE-REQUEST (AARQ)
A-ASSOCIATE. req/ind
A-ASSOCIATE-RESPONSE (AARE)
A-ASSOCIATE. res/conf
A-RELEASE. req/ind
A-RELEASE REQUEST (ARRE)
A-RELEASE RESPONSE (ARRE)
A-RELEASE. res/conf
A-ABORT. Req/Ind
A-ABORT (ABRT)
(iniziata da ACSE
service user)
A-P-ABORT (APBRT)
A-P-ABORT. Ind
(Inviata dall’ACSE
alla SMAE)
Fig.4.3.1 Gli ASE sono specificati da “definizione dei servizi e specifica dei protocolli (PDU)”.
Servizi e PDU relativi all’elemento ACSE. Nel caso più generale ogni servizio ha quattro primitive :
richiesta, indicazione, risposta e conferma.
93
L’Elemento di Servizio ACSE é usato per iniziare (set-up) o terminare (release) l’
associazione fra la SMAE Gestore e la SMAE Agente. Come tutti gli altri Elementi di
Servizio, la normativa OSI descrive anche ACSE in termini di «definizione di servizi e
specifica di protocolli ». Queste descrizioni si trovano nei documenti seguenti:
1)
ITU-T Recommendation X.217. Information Processing Systems. OSI.
Service Definition for ACSE.1995.
2)
ITU-T Recommendation X.227. Information Processing Systems. OSI.
Connection-Oriented Protocol for the ACSE. Protocol Specification. 1995.
L’ACSE comprende sette primitive di servizio e sei formati PDU (Protocol Data
Unit) (Vedi Fig.4.3.1). La lettera “A” all’inizio di ogni parola sta per “ACSE”. I due
servizi A-ABORT e A-P-ABORT sono un caso particolare di A-RELEASE e servono a
interrompere una associazione in un qualsiasi momento con una interruzione di attività
improvvisa e conseguente perdita dei dati. Essi sono iniziati rispettivamente 1) da una
SMAE o da una qualsiasi altra ASE (ACSE Service User) e in questo caso la
corrispondente PDU denominata ABRT contiene il parametro “Abort Source” oppure 2)
da un ACSE (ACSE Service Provider) e in questo caso la corrispondente PDU si
chiama APBRT ed è inviata allorché si verificano errori catastrofici all’interno
dell’ACSE stessa i.e. livello di strato sette o livelli sottostanti (Vedi Fig.4.3.2)
A-ASSOCIATE req/rsp sono le primitive di servizio attraverso le quali la SMAE
Gestore e la SMAE Agente negoziano e concordano la natura e le modalità di
interscambio dell’informazione gestionale.
Ovviamente A-ASSOCIATE req/rsp come servizio di negoziazione é un servizio
eminentemente interattivo e quindi richiede sempre una risposta a ogni richiesta
effettuata dalla SMAE Gestore. Questa caratteristica viene identificata dicendo che il
servizio é del tipo “confirmed”.
La Fig.4.3.2 mostra il funzionamento del servizio A-ASSOCIATE per
l’instaurazione di una associazione fra i processi reali SMAP Gestore e SMAP Agente
residenti rispettivamente in un sistema gestore e un sistema gestito. É questo uno schema
di funzionamento del tipo «connection mode» con le quattro «primitive»:
1) richiesta,
2) indicazione,
3) risposta
4) conferma.
Vediamo la sequenza temporale delle quattro primitive (Fig.4.3.2).
1. Richiesta
Una SMAE (Requester), residente nel sistema aperto No.1 e indicata in figura
come «ACSE Service User» formula all’Elemento di Servizio ACSE una richiesta di
associazione con uno SMAE residente nel sistema aperto remoto No.2 (freccia rossa
all’estrema sinistra puntata verso il basso) . L’ ACSE come ACSE Service Provider
94
trasforma la richiesta ricevuta in una Application PDU, A-ASSOCIATE REQUEST
PDU, cioè AARQ/PDU, fornendo alla SMAE il servizio primitivo A-ASSOCIATE.req.
Secondo una procedura iterativa già illustrata in OSI-RM (Vedi Cap.1), questa
AARQ/PDU viene incapsulata come “user data” cioè come carico utile in una
Presentation PDU a livello di presentazione (livello sei) denominata PCRQ/PDU per
virtù del servizio P-CONNECT.req fornito dalle entità di sesto livello a quelle di settimo.
La PCRQ/PDU a livello di presentazione a sua volta viene incapsulata come “user
data “ in una Session PDU a livello di sessione (livello cinque) denominata SCRQ/PDU
per virtù del servizio S-CONNECT.req fornito dalle entità di quinto livello a quelle di
sesto.
2. Indicazione
Il processo continua ai livelli inferiori fino al livello fisico (livello uno).
L’informazione viene poi trasferita al sistema aperto No.2. Qui essa viene sottoposta a
un processo opposto a quello descritto, indicato in Fig. 4.3.2 dalle frecce nere verticali
puntate verso l’alto all’estrema destra. Alla fine di questo processo l’ informazione
emerge come una indicazione per virtù del servizio primitivo A-ASSOCIATE.ind.
fornito dall’ACSE Service Provider alla SMAE No.2 ( Responder, ACSE Service User
nel sistema aperto No.2).
3. Risposta
Se la SMAE.No.2 Responder accetta i termini della associazione richiesta dal
sistema No.1, il corrispondente ACSE risponde con una risposta sottoforma di una
Appl.PDU denominata A-ASSOCIATE RESPONSE (AARE/PDU) fornendo il servizio
A-ASSOCIATE.rsp. alla SMAE No.2 (la freccia rossa puntata verso il basso indica la
corrispondente richiesta di servizio proveniente dal livello 7)
4. Conferma
La AARE/PDU viene trasmessa alla SMAE richiedente seguendo il cammino
inverso della AARQ/PDU ed emerge dalla pila OSI del sistema No.1 come conferma
tramite il servizio A-ASSOCIATE.conf fornito dall ACSE Service Provider allo SMAP
No.1
NOTA BENE: Nella richiesta, il richiedente include una lista di parametri nei quali
specifica le condizioni sotto le quali dovrà avvenire la associazione. Il format di questa lista é
standardizzato: si tratta di ben 21 parametri per un funzionamento… normale ! Se il ricevente
accetta la lista, la sua risposta é positiva e la associazione viene effettuata. Se il ricevente non accetta
la lista, egli la modifica e manda indietro la “sua” lista, ovviamente diversa da quella ricevuta. A
questo punto ci sono due possibilità: o il richiedente accetta la nuova lista e la associazione si
stabilisce oppure il richiedente non accetta la lista e allora emette una richiesta di interruzione
tramite il servizio ABORT.req. I 21 parametri si trovano in D.K.Udupa, “ TMN”, Mc-Graw Hill,
1999, pag.182
La Fig. 4.3.3 riassume la struttura delle SMAE nel modello OSI-SM, costituita da
elementi di servizio ASE, servizi S, primitive P e Unita’ Fuinzionali UF.
95
SMAE No.2, Responder
(ACSE Service User)
AGENTE
SMAE No.1, Requester
(ACSE Service User),
GESTORE
Richiesta
Conferma
A-ASSOCIATE.req
Risposta
Indicazione
A-ASSOCIATE.resp
A-ASSOCIATE.ind
(fornitura di servizio)
A-ASSOCIATE.conf
(richiesta di servizio)
Appl. PDU=
AARQ/PDU
ACSE (ACSE
Service
Provider)
P-CONNECT.req
Presentation PDU =
PCRQ/PDU
Appl. PDU=
AARE/PDU
PDU
ACSE (ACSE
Service
Provider)
P-CONNECT.resp
Presentation
Layer Service
P-CONNECT.ind
Presentation
Layer Service
S-CONNECT.req.
Session PDU=
SCRQ/PDU
Session &
Lower Layer
Services
Session &
Lower Layer
Services
Fig.4.3.2 Richieste/Offerte di servizi primitivi e PDU relative al servizio A-ASSOCIATE fornito dall’ACSE.
Frecce rosse = Richieste di servizio, Frecce nere = Forniture di servizio
96
L’UNIVERSO DELLE “SYSTEM MANAGEMENT
APPLICATION ENTITIES” (SMAE’s)
SMAE
ASE
P
P
S
P
S
ASE
P
S
FU
S
S
ASE
ASE
Fig.4.3.3 La SMAE è divisa in 4 Application Service Elements (ASE) pluri-servizio (S) e ogni servizio
contiene Primitive di servizio (P)
SERVIZI
PDU
1. RO-INVOKE. req/ind
ROIV
2.
RO-RESULT. req/ind
RORS
3.
RO-ERROR. req/ind
ROER
4. RO-REJECT. U-req/U-ind
5.
RO-REJECT. P-ind
RORJ
RORJ
Tavola. 4.4.1 Servizi (5) e PDU (4) dell’elemento di servizio ROSE
97
4.4
Elemento di Servizio ROSE: paradigma generico per
stabilire una piattaforma “request-reply”.
Come detto in precedenza lo scambio interattivo di informazione gestionale fra
sistema gestore e sistema gestito utilizza tutti i sette livelli del Modello di Riferimento
OSI. A livello applicativo lo scambio avviene con messaggi costruiti con il contributo dei
quattro elementi ASE . In particolare dopo aver stabilito una associazione fra SMAE
Gestore e SMAE Agente tramite ACSE, si attiva un elemento di servizio, Remote
Operation Service Element (ROSE), che stabilisce una piattaforma/contenitore atta
a supportare uno scambio interattivo “richiesta-risposta” fra sistemi remoti. Per gli
studenti che hanno già seguito un corso elementare di informatica e’ facile riconoscere
che si tratta di una versione OSI di una Remote Procedure Call (RPC) utilizzata allorché
il paradigma Client-Server viene applicato ad un sistema distribuito dove la richiesta e la
effettuazione di un operazione avviene in sedi remote interconnesse da una rete di
trasmissione dati
. Più precisamente, il servizio ROSE offre un meccanismo che permette a un
sistema “invoker” di “invocare” operazioni su sistemi remoti (“performer”) i quali
“rispondono” a queste invocazioni secondo un paradigma «request-reply» che offre i
servizi/PDU mostrati nella Tavola 4.4.1 e in Fig. 4.4.1 utilizzando le quattro R-PDU
mostrate in Fig.4.4.1. La fig. 4.4.1 mostra la struttura delle quattro PDU relative al
servizio ROSE. (R-PDU): una di invocazione e tre di risposta (successo, errore, rigetto).
Queste quattro R-PDU sono del tutto generiche e sono contenitori usabili con un
qualsiasi tipo di applicazione interattiva che richieda l’uso di un paradigma request-reply
anche non necessariamente gestionale. L’ elemento di servizio CMISE specializzerà poi
le R-PDU al caso di applicazioni gestionali.
Le invocazioni e le risposte sono correlate con un numero identificatore (“Invoke
Id”) in modo tale che esse possano inviarsi/riceversi ad un arbitrario istante di tempo
(cioé non devono avvenire sequenzilmente una subito dopo l’altra). La seconda zona
nelle R-PDU “invoke” e “response” contiene la specifica del tipo di operazione da
effettuare. Il tipo di operazione nella R-PDU é generico e verrà specificato dall’ elemento
di servizio CMISE che specializza il servizio ROSE ad applicazioni gestionali secondo il
codice numerico mostrato nella Tavola 4.5.1 Per la specifica di “Error Value” vedi L.G.
Raman “Fundamentals of Telecommunication Network Management” IEEE Press, 1999,
p.104.
98
(a)
INVOKE
Id
OPERATION
VALUE
ARGUMENT
ROIV emessa da ROSE1 in Fig.4.1.1
(b)
INVOKE
Id
OPERATION
VALUE
RESULT
RORS emessa da ROSE2 in Fig.4.1.1
(c)
INVOKE
Id
ERROR
VALUE (*)
ERROR
PARAMETER (**)
ROER emessa da ROSE2 in Fig.4.1.1 (*) Errore verificatosi durante una operazione nel
sistema 2. Esistono 4 tipi di errore codificati (**) Ulteriori dettagli sulle cause d’errore
(d)
INVOKE
Id
PROBLEM
(invoke problem, return result
problem, return error problem)
RORJ emessa da ROSE2 in Fig.4.1.1 nel caso di impossibilità ad accettare l’invocazione
Fig.4.4.1 ROSE PDU: a) Invoke, b) Successful Response c) Error Response, d) Reject
99
4.5
Elemento di Servizio CMISE e il suo protocollo CMIP:
piattaforma “comune” a tutte le funzioni di gestione.
Il CMISE può fornire gli undici servizi mostrati nella Tavola 4.5.1. Ogni servizio
CMISE, come già detto per l’ACSE, é di tipo interattivo cioè è costituito dalle due coppie
richiesta/indicazione, risposta/conferma (Vedi Fig.4.3.2 per il caso di ACSE). Ad ognuna
di queste coppie corrisponde una PDU. Nella Tavola 4.5.1 notare come ogni servizio é
caratterizzato da un valore numerico, chiamato « Operation Value ». Ad esempio il
servizio « GET » ha un valore 3. Vedremo fra poco come questo valore venga utilizzato
in pratica in una PDU.
Il protocollo corrispondente al CMISE si chiama CMIP (Common Management
Information Protocol). Un messaggio gestionale strutturato secondo il protocollo CMIP
(Protocol Data Unit del protocollo CMIP, M-PDU) é mostrato in Fig, 4.5.1. La M-PDU
é derivata dalla R-PDU specializzando alcune zone. L’ « Operation Value »
precedentemente descritto va inserito nella seconda zona da sinistra.
Nella Fig.4.5.1 abbiamo indicato in rosso corsivo il contenuto delle ultime tre
zone a destra per evidenziare il fatto che questi dati vengono ottenuti direttamente dal
modello informativo. Quindi il protocollo CMIP di per sé non é sufficiente a definire il
contenuto di una M-PDU ma é necessario ottenere dati dal modello informativo.
Notare come la opzione « base object class » o « managed object class » lasci la porta
aperta al caso in cui sia presente una applicazione gestionale con caratteristiche di
«scoping ». La medesima osservazione vale per le istanze. La Fig.4.5.1B mostra la
struttura di una M-PDU relativa ad una notifica di evento. In questa PDU e’ importante
notare come le zone relative alla descrizione dell’evento siano ancora generiche cioè
possono essere utilizzate per ogni tipo di evento e.g. relativo ad un guasto, una violazione
delle norme di sicurezza , una variazione della configurazione di rete etc. Sarà l’elemento
di servizio SMASE che fornirà questa informazione specifica della funzione di gestione
che si vuole realizzare.
100
INVOKE
Id
OPERATION
VALUE
MANAGED/
BASE
OBJECT
CLASS
MANAGED/
BASE
OBJECT
INSTANCE
OPERATION
SPECIFIC
INFORMATION
Fig.4.5.1.A Protocollo CMIP: struttura generica di una richiesta.
INVOKE- MODE
(Conf.,
Id
Unconf.)
MANAG.
OBJECT
CLASS
MANAG.
OBJECT
INSTAN.
EVENT
TYPE
EVENT
TIME
EVENT
INFORM.
Fig. 4.5.1.B Struttura della M-PDU M-EVENT REPORT req./ind.
101
Tavola 4.5.1 I servizi (CMISE) e i valori
che appaiono nella M-PDU (CMIP)
Event Report (Notifica di Evento)
Confirmed Event Report (Notifica di Evento con Conferma)
Get (Leggere)
Set (Modificare il valore)
Confirmed Set (Modifica di valore con Conferma)
Action (Azione)
Confirmed Action (Azione con Conferma)
Create (Creare un oggetto)
Delete (Distruggere un oggetto)
Cancel Get (Annullare Lettura)
4.6
0
1
2
3
4
5
6
7
8
9
Relazione fra modello informativo e protocollo
comunicativo CMIP.
In questo paragrafo vogliamo mostrare, tramite un esempio concreto e in aggiunta
a quanto detto a proposito della Fig.4.5.1, come l’informazione contenuta nel modello
informativo e rappresentata con linguaggio GDMO/ASN.1 venga inserita nel protocollo
CMIP e quindi trasferita attraverso l’interfaccia SMAE Gestore – SMAE Agente. É un
esempio importante perché mostra come il linguaggio GDMO/ASN.1 del modello
informativo sia intimamente relazionato al protocollo comunicativo CMIP. Infatti
questo linguaggio è stato sviluppato specificatamente per il protocollo CMIP. Questa
specificità rappresenta un grosso limite del linguaggio GDMO/ASN.1 quando lo si
voglia usare assieme a protocolli diversi dal CMIP (e.g. SNMP). L’esempio si riferisce
ad una operazione gestionale generica del tipo “get” nella quale il Manager vuole
ottenere i valori di tre attributi di un oggetto appartenente alla classe “circuitpack”.
Supponiamo che l’oggetto da gestire sia la card No. 3, nella slot No.2 contenuta nella
shelf No.1 dell’ elemento di rete NetworkElementId=ACME mostrato in Fig. 4.6.1.
Gli attributi gestiti dal Manager, e specificati nel messaggio, non possono essere
arbitrari ma devono appartenere al gruppo di attributi specificati nel modello informativo
per la classe circuitpack. La verifica che questa condizione sia soddisfatta viene
effettuata dall’Agente subito dopo aver ricevuto il messaggio inviatogli dal Manager. Se
la condizione non è verificata, cioè il Manager sta effettuando richieste non permesse dal
modello informativo, l’Agente risponde al Manager con un segnale di errore. Nella figura
3.4.3 mostrammo un elenco di attributi relativi alla classe “circuitpack” con l’attributo
distintivo “equipment Id”. [ Nota : sebbene questa figura non abbia il formato di una
maschera GDMO, in realtà questo elenco di attributi é quello che appare nella effettiva
maschera GDMO della classe circuitpack.]
102
Network
ElementId=
ACME
1
1
2
3
1
2
EquipmentId = slot i
(i=1,2,3)
EquipmentId = j
(j=1,2,3)
EquipmentId =
Shelf 1
1
2
1
3
2
3
1
2
3
EquipmentId = slot i
(i = 1,2)
EquipmentID = j
(j=1,2,3)
EquipmentId =
Shelf 2
1
2
1
1
1
1
1
1
EquipmentId = slot i
(i-=1-6)
EquipmentId = 1
EquipmentId =
Shelf 3
1
2
3
4
5
6
Fig. 4.6.1 L’oggetto gestito in esame é la carta No.3 nella slot No.2 nella shelf No.1
103
Classe
(0 0 13 3100 0 3 30)
circuitPack
circuitPack
Attributi
Istanza
(0 013 3100 0 5 20)
(equipment Id =
“Shelf1”,
equipment Id =
“Slot 2”,
equipment Id =
3)
(equipment Id =
“Shelf1”,
equipment Id =
“Slot 2”,
equipment Id =
3)
circuitPackType operationalState
circuitPackType
= “LFCCLMF 1AA”
operationalState
= enabled (0)
availabilityStatus
availabilityStatus
= {}
Fig.4.6.2. Protocollo CMIP. Esempio di richiesta/risposta in una operazione “get” mandata ad una
istanza della classe “circuitPack” per ottenere i valori di tre attributi. L’attributo distintivo é
“equipment Id”. Il nome locale dell’oggetto é relativo al network element. La sequenza di
contenimento é: network element, equipment (shelf), equipment holder (slot) e circuit pack.
(L.G. Raman, “Fundamentals of Telecommunications Network Management”, IEEE Press, 1999,
p.200, Fig.6.1)
104
Supponiamo che il Manager voglia leggere tre attributi presi dall’elenco di
Fig.3.4.3. Specificatamente: circuitpackType, operationalState e availabilityStatus.
•
Descrizione delle tre zone delle PDU
La figura 4.6.2 mostra le zone della PDU che contengono informazione derivata
dal modello informativo. Le zone sono relative a: definizione della classe, definizione
della istanza, informazione specifica dell’operazione (in questo caso si tratta del nome
degli attributi «target» nella PDU di richiesta e i risultati dell’operazione di lettura del
valore degli attributi nella PDU di risposta).
La prima zona nella PDU di richiesta definisce la classe di oggetti gestiti a cui
l’oggetto in esame appartiene. Per ragioni didattiche in figura abbiamo indicato questa
classe con il suo nome “circuitpack”. In realtà quello che viene incluso in questa zona é il
valore della sequenza numerica ( chiamata anche « identificatore » o « object identifier »
in inglese) che segue la parola chiave REGISTERED AS nella maschera GDMO relativa
alla classe “circuitpack”. Come indicato nel paragrafo 4.8 relativo all’albero delle
registrazioni, il valore dell’identificatore, globalmente univoco, é ( 0 0 13 3100 0 3 30).
Questi numeri, dopo la trasformazione effettuata secondo il protocollo BER (Basic
Encoding Rules) in una sequenza di ottetti di bits, sono quelli che effettivamente
transitano attraverso l’interfaccia gestore-agente. Il protocollo BER é descritto nel
paragrafo 4.9
La seconda zona nella PDU di richiesta definisce il nome DN locale dell’oggetto
gestito riferito all’elemento di rete. Per fare ciò é necessario avere le maschere di legame
(name binding templates). Notare che si usa il nome locale riferito all’elemento di rete
poiché, in questo esempio si assume l’esistenza di un Manager che gestisce un solo
elemento di rete e quindi nell’ambito di questo processo gestionale il nome locale offre
una definizione non-ambigua dell’oggetto gestito. Se il Manager avesse gestito due
elementi di rete, invece di uno, il nome locale relativo all’elemento di rete non sarebbe
stato piu’ sufficiente a garantire la univocità dei nomi e sarebbe stato necessario riferire il
nome locale all’elemento superiore nell’ albero dei nomi cioé la rete (network)
Tutto ciò é anche mostrato nell’ albero dei nomi in Fig.4.9.1. Da questa figura si
vede che un nome locale relativo ad un elemento di rete é costituito dai tre nomi RDN
EquipmentId=Shelf1, EquipmentId=Slot2 e EquipmentId=3 relativi a shelf (equipment),
slot (equipment holder) e circuitpack. [Nota: “shelf” e “slot” sono i nomi dei
“contenitori” reali e “equipment” e “equipment holder” sono le corrispondenti classi
(modelli astratti)]. Anche in questo caso abbiamo usato esplicitamente il nome
“equipment Id” per scopi didattici. In pratica questo nome é sostituito dall’ identificatore
( 0 0 13 3100 0 5 20) dell’ attributo distintivo “equipment Id” che si trova nel costrutto
REGISTERED AS della relativa maschera GDMO. (Raccomandazione M.3100
dell’ITU-T, pag. 42)
Per specificare completamente il nome dell’oggetto, l’identificatore deve essere
seguito dal valore dell’attributo. Il valore dell’attributo deve avere un formato
compatibile con la sintassi ASN.1. In generale si può scegliere fra una sequenza
alfanumerica oppure numeri interi. Quindi il nome DN locale dell’oggetto é una sequenza
ordinata di identificatori seguiti dai rispettivi valori espressi in ASN.1.
105
Infine, nelle tre zone contenenti le specifiche degli attributi appariranno gli
identificatori che si trovano nei costrutti REGISTERED AS delle rispettive maschere
GDMO. Ad esempio circuitPackType sarà specificato dall’identificatore (0 0 13 3100 0 5
54)
Nella PDU di risposta il contenuto delle prime due zone é uguale al contenuto
della PDU di richiesta.
Le zone degli attributi invece contengono i risultati delle letture. In
particolare si legge circuitPackType = LFCCLMF1AA, in accordo con la specifica
ANS.1 che richiede per questo attributo un valore espresso come “Printable String”
cioé una sequenza di caratteri alfanumerici. Per il secondo attributo l’ANS.1
specifica un numero intero (“integer”) e, in particolare, zero significa “attivato” cioé
istallato e funzionante. Il terzo attributo, come per ANS.1, mostra due parentesi
vuote rappresentative del fatto che l’oggetto é disponibile (notare che nel
formalismo ASN.1 la non-disponibilità é catterizzata da presenza di valori fra le
parentesi).
•
Conclusioni
Alla luce di quanto detto sinora si devono trarre due conclusioni importanti:
1)
Il modello informativo gioca un ruolo fondamentale nello scambio di
informazioni Manager-Agent effettuate con il protocollo CMIP. Infatti il
protocollo CMIP identifica solo la natura dell’informazione che deve
essere inserita nelle varie zone della PDU (e.g. zona “Managed Object
Class”) ma non fornisce l’informazione specifica (e.g. il numero di
registrazione della maschera di classe contenuta nella MIB relativa
all’oggetto target, vedi Fig.4.6.2). É questa informazione specifica quella
che, sottoforma di bits, transita attraverso l’interfaccia fra sistema gestore
e sistema gestito collegati in una associazione gestionale.
2)
Il sistema gestore e il sistema gestito devono condividere lo stesso
modello informativo per poter comunicare mutuamente. Ad esempio il
sistema gestito deve conoscere il significato di quella sequenza di bits
che gli arriva dall’interfaccia con il gestore per potere poi operare sugli
oggetti e, in definitiva, sulle risorse gestite. Questa condivisione del
modello informativo fra sistema gestore e sistema gestito nella letteratura
inglese si chiama “Shared Management Knowledge, SMK”. Noi
traduciamo liberamente come: “Conoscenza Gestionale Condivisa,
CGC”. Quindi diremo che lo scambio di informazionr fra Gestore e
Agente richiede Conoscenza Gestionale Condivisa.
106
4.7
L’Elemento di Servizio SMASE specifico di ogni funzione
di gestione che si desidera realizzare
L’elemento di servizio SMASE é un elemento elusivo, tanto da non apparire in
alcuni testi. Si tratta in effetti di un elemento di servizio diverso dagli altri, specifico di
ogni funzione di gestione. Infatti esso non é descritto, come gli altri elementi, in termini
di servizi e relative PDU, ma semplicemente come un fornitore di informazioni
aggiuntive specifiche della particolare funzione di gestione da realizzare. Si tratta
quindi di informazione che specializza le informazioni CMISE comuni a tutte le funzioni
di gestione. In altre parole si può dire che lo SMASE aggiunga specificità
all’informazione CMISE. Quindi la MA-PDU scambiata fra SMAE in Fig.4.1.1 è una
PDU con la struttura imposta dal protocollo CMIP ma contenente l’informazione
aggiuntiva fornita da SMASE.
Un esempio di tutto ciò e’ mostrato in Fig.4.7.1. Questa figura illustra il caso di
un messaggio “Alarm Reporting” relativo ad un guasto in una rete di commutazione.
Riconosciamo che l’elemento CMISE non fornisce un servizio CMIS specializzato per
“Alarm Reporting” bensì si limita al più generico “Event Report” (CMIS No.0 nella
Tavola 4.5.1). Allora in questo caso CMISE fornisce una piattaforma adatta a un “Event
Report” generico (Event Type, Event Time e Event Information, vedi Fig.4.5.1B) mentre
SMASE specifica ulteriormente “Event Type” con “Equipment Alarm” (terza zona da
destra in Fig.4.7.1) e “Event Information” con “Severity” e “Probabile Cause” Il resto
dell’informazione contenuta nel messaggio di Fig.4.7.1 è informazione di istanziazione
relativa all’allarme preso in considerazione.
4.8
I servizi e protocolli al livello di presentazione e sessione
Sinora ci siamo concentrati sui servizi/protocolli relativi al livello applicativo ma
abbiamo visto che il trasferimento di informazione nell’ambito di una associazione fra
entità applicative coinvolge tutti i livelli della pila OSI. In particolare il contenuto dei
messaggi ai livelli di presentazione (No.6) e di sessione (No.5) dipende dalla
particolare applicazione scelta a livello applicativo. Sembra quindi opportuno
esaminare anche i requisiti dei protocolli ai livelli 5 e 6 allorché l’applicazione a livello
applicativo (7) é di tipo interattivo e usa il protocollo CMIP.
A livello di sessione la definizione dei servizi e le specifiche di protocollo sono
riportate nelle raccomandazioni X.215 e X.225, rispettivamente. Anche a questo livello
esiste una unità funzionale kernel obbligatoria che serve a stabilire/interrompere una
sessione. Il protocollo obbligatorio é il SPv.2 (Session Protocol version 2).
A livello di presentazione la definizione dei servizi e le specifiche di protocollo
sono riportate nelle raccomandazioni X.216 e X.226, rispettivamente. A livello di
presentazione si deve 1) raggiungere un accordo fra le due entità applicative sulle regole
per trasformare (in modo automatizzato) il linguaggio applicativo ASN.1 in sequenze di
bits e 2) implementare queste regole. La sequenza di bits risultante si dice strutturata in
accordo con una “sintassi di trasferimento”. In generale la sintassi di trasferimento é la
107
BER (Basic Encoding Rules) descritta nelle raccomandazioni X.209/X.690. Piu’ dettagli
su questo punto verranno forniti nel paragrafo seguente.
4.9 La sintassi di trasferimento “Basic Encoding Rules, BER”
al livello di Rappresentazione
Come precedentemente indicato, la sintassi ASN.1 usata a livello applicativo
opera ad un livello di astrazione elevato particolarmente adatto a rappresentare la
complessità degli oggetti gestiti e delle operazioni che si possono effettuare su di essi.
Questo permette al progettista del software applicativo di concentrarsi sugli aspetti
semantici del problema cioé sulla caratterizzazione e il comportamento degli oggetti
gestiti piuttosto che impantanarsi nei dettagli del linguaggio necessario a descrivere gli
oggetti stessi.
Tuttavia, l’informazione gestionale che viene trasferita attraverso un interfaccia
Gestore- Agente deve essere trasferita sottoforma di bits (o ottetti di bits). Serve quindi
un meccanismo capace di mappare la rappresentazione ASN.1 effettuata dalla SMAE
trasmittente in un a rappresentazione a livello di bits, trasmettere i bits attraverso
l’interfaccia e poi trasformare i bits in linguaggio ASN.1 pronto per la SMAE ricevente.
Questo meccanismo esiste ed é chiamato meccanismo di “encoding” e
“decoding”. Il linguaggio ANS.1 usato nei messaggi gestionali viene trasformato in
ottetti di bits che sono codificati secondo una Sintassi di Trasferimento caratterizzata dal
protocollo BER (Basic Encoding Rules) e trasmessi al livello di Rappresentazione (Vedi
Fig.4.9.1). Raggiunta l’entità di rappresentazione No.2 i bits vengono decodificati nel
linguaggio originario ANS.1 e presentati alla SMAE No.2 a livello applicativo.
A questo punto é bene notare come i termini “encoding” e “decoding” in questo
corso vengano usati per indicare il mapping di una sintassi astratta (e.g. ASN.1) in una
sintassi di trasferimento (e.g. BER). Lo scopo di questa operazione é la creazione di
sequenze di bits che vengono trasmesse attraverso l’interfaccia di separazione fra sistema
gestito e sistema gestore.
La Fig.4.9.2 mostra la codificazione di una ipotetica sequenza alfanumerica del
linguaggio ASN.1 “JOHN” in una sequenza di ottetti secondo il formalismo BER (Basic
Encoding Rules). Nella zona “Identifier” l’ottetto 0000 0100 corrisponde al numero 4
nella tavola degli ASN.1 Data Types (“Universal Class”). Nella zona “Length” l’ottetto
0000 0100 corrisponde al numero 4 rappresentativo del numero di ottetti contenuti nella
zona “Contents”. Nella zona “Contents” i quattro ottetti da sinistra a destra
rappresentano i numeri 10, 15, 8, 14 corrispondenti alla posizioni delle lettere J,O,H,N
nell’alfabeto
108
INVOKE
ID: 12345
OPERATION
TYPE:
“Event Report”
Managed
Managed Object
Object Instance: Event Type: Event Time:
11: 47 am
Equip.
Class: “Fabric Id
April 11, 2002”
Alarm
“Fabric” = Sri”
Event Information.
Severity: Probable Cause:
Critical Board Failure
Fig.4.7.1 Esempio di un Management Application PDU (MA_PDU) emessa da una SMAE
Agente per notificare ad una SMAE Gestore l’evento di un guasto avvenuto in una rete di
commutazione (Switch Fabric). La Funzione di Gestione realizzata e’ “Alarm Reporting”. La
scritta in caratteri neri maiuscoli rappresenta il contributo di ROSE. La scritta in blu
(caratteri minuscoli) rappresenta il contributo di CMISE. La scritta in grassetto corsivo rosso
rappresenta il contributo di SMASE. (L.G. Raman, Fundamentals of Telecommunications
Network Management”, IEEE Press, 1999, p. 71, Fig.3.6)
109
LIVELLO APPLICATIVO
Entità
Appl.
No.1.
ASN.1
Entità
Appl.
No.2
BER
Entità di
Rappr.
No.1
Entità di
Rappr.
No.2
LIVELLO DI RAPPRESENTAZIONE
Fig.4.9.1 Sintassi astratta ANS.1 a livello applicativo trasformata in una
sintassi di trasferimento BER a livello di rappresentazione.
110
IDENTIFIER
0000 0100
LENGTH
CONTENT
0000 0100
0000 1010
0000 1111
0000 1000
0000 1110
“J”
“O”
“H”
“N”
Fig.4.9.2 Codificazione della sequenza ASN.1 “JOHN” in una sequenza di ottetti secondo il
formalismo BER (Basic Encoding Rules). (Vedi, D.K Udupa, “TMN”, McGraw Hill, 1999, p. 137)
4.10 Esercizi
1. Cosa é una entità applicativa SMAE (System Management Application Entity)?
Nella gestione dei sistemi TLC quali sono i ruoli che una SMAE può giocare?
2. Il modello OSI-SM suddivide una SMAE in moduli. Nel caso di una applicazione
gestionale interattiva quanti sono i moduli e come si chiamano?
3. Quale é la ragione principale della suddivisione di una SMAE in moduli?
4. I moduli costitutivi di una SMAE si chiamano Elementi di Servizio. La scelta di
questo nome é stata giudicata poco felice. Perché? É un elemento di servizio
veramente elementare, nel senso che é privo di costituenti interni?
5. Per effettuare lo scambio/interpretazione di informazione gestionale nell’ambito di
una associazione gestore-agente si devono usare tutti gli Elementi di Servizio
oppure qualche volta se ne possono usare solo alcuni?
6. Ogni Elemento di Servizio ha un format standard (protocollo) per i suoi messaggi
gestionali (PDU’s, Protocol Data Units). É la conoscenza dei protocolli relativi agli
111
Elementi di Servizio sufficiente a garantire lo scambio/interpretazione di
informazione gestionale fra SMAE gestore e SMAE agente?
7. Esistono modelli gestionali, diversi dal modello OSI-SM, che non utilizzano il
modello informativo nello scambio/interpretazione di informazione gestionale fra
gestore e agente?
8. Spiegare a cosa serve l’Elemento di Servizio ACSE.
9. Quali sono i servizi costitutivi dell’elemento di servizio ACSE? Quali sono le
primitive di un servizio ACSE?
10. Cosa sono le Unità Funzionali e perché sono state introdotte?
11. Cosa é una Unità Funzionale di Base (Kernel Functional Unit)? Cosa garantisce la
fornitura dei servizi contenuti in una Unità Funzionale di Base?
12. Spiegare le relazioni fra 1) SMAE, 2) Elemento di Servizio, 3) Servizio fornito da
un Elemento di Servizio, 4) Unità Funzionale e 5) Primitiva di un Servizio. Fare un
disegno schematico che illustra queste relazioni.
13. Spiegare a cosa serve l’Elemento di Servizio ROSE,
14. Disegnare i quattro tipi di PDU relativi a ROSE.
15. Cosa é l’Elemento di Servizio CMISE e quale é il protocollo corrispondente?
16. Una PDU CMIP di richiesta é derivata da una PDU ROSE specializzando alcume
zone. Spiegare come.
17. Facendo riferimento ad una PDU CMIP illustrare la relazione fra modello
informativo e il protocollo CMIP.
18. Cosa é un Elemento di Servizio SMASE? Quali sono le sue PDU’s?
19. Cosa é la sintassi di trasferimento BER (Basic Encoding Rules)? A quale livello
della pila OSI si applica?
112
CAPITOLO 5
Modello OSI-SM per la gestione di
sistema: sottomodello funzionale
5.1 Introduzione
•
Il modello FCAPS è il “sottomodello funzionale” del modello OSI-SM
Nella Parte I del corso abbiamo introdotto il modello gestionale funzionale
FCAPS, così chiamato perché comprende cinque Aree Funzionali (SMFA, System
Management Functional Area): Fault, Configuration, Administration, Performance
e Security (Vedi Tavola 5.1.1). Questo modello costituisce il “sottomodello funzionale”
del modello OSI-SM. Esso definisce il contenuto delle attività svolte dalle coppie
Gestore-Agente contenute in un sistema gestionale atto a gestire un sistema TLC. Più
precisamente il modello FCAPS specifica le Funzioni di Gestione (System
Management Functions, SMF) che un sistema gestionale deve svolgere per gestire un
sistema TLC. Si tratta di un modello gerarchico che, dal basso verso l’alto, è costituito
da: SMF, Insiemi di SMF, Gruppi di Insiemi di SMF e Aree Funzionali. Quindi le SMF,
situate alla base della gerarchia FCAPS, sono percepite da un utilizzatore del sistema
gestionale come le componenti elementari di un Servizio di Gestione offerto dal sistema
stesso. Si dice anche che le SMF sono i “mattoni” (building blocks) che servono a
“costruire” un Servizio di Gestione
•
OSI-SM/sottomodello funzionale è utilizzato nel modello TMN
Il sottomodello funzionale di OSI-SM (modello FCAPS), come del resto tutto il
modello OSI-SM, è stato adottato dall’ITU-T in un modello architturale per reti di
gestione denominato “Modello TMN” (TMN, Telecomunication Management Networks)
che verrà descritto nel prossimo capitolo. Quindi se si vogliono conoscere i dettagli
dell’ultima versione del modello FCAPS si deve far riferimento a documenti ITU-T della
serie M.xxxx dedicata alle reti TMN (in particolare alla Raccomandazione M.3400 del
2/2000). In un contesto TMN le funzioni di gestione SMF sono state chiamate “TMN
Management Functions” mentre i servizi di gestione sono denominati “TMN
Management Services”.
5.1.1 Tecnoservizi di gestione, funzioni di gestione e servizi CMIS: accoppiamento
fra sottomodello funzionale e sottomodello comunicativo
Un tecnoservizio di gestione è una funzionalità che un insieme di risorse
gestionali (sistema gestionale) dedicato alla gestione di risorse TLC (e.g. sistema
113
gestionale parte di un sistema TLC come uno o più “sistemi di supporto” OS, NSS o
OSS) offre ai suoi utilizzatori per soddisfare certi loro bisogni/esigenze di gestione. Si
tratta quindi di un “Tecnoservizio”, come definito nella Parte I del corso, offerto da
risorse gestionali ai loro utilizzatori (e.g. i gestori di una rete TLC). “Traffic
Management”, “Quality of Service and Network Performance Administration”,
Security Administration” e Network Provisioning Management” sono esempi di
servizi di gestione. .
Aree Funzionali
Gruppi di Insiemi di Funzioni (SMFSG)
1. RAS Quality Assurance (6)
2. Alarm Surveillance (10)
3. Fault Localization (5)
FAULT
4. Fault Correction (5)
5. Testing (11)
(44)
6. Trouble Administration (7)
7. Network Planning & Engineering (11)
8. Installation (12)
CONFIGURA- 9. Service Planning & Negotiation (10)
TION
10. Provisioning (29)
11. Status & Control (8)
(70)
12. Usage Measurement (17)
ACCOUN13. Tariffing/Pricing (8)
TING
14. Collection & Finance (21)
(57)
15. Enterprise Control (11)
16. Performance Quality Assurance (7)
17. Performance Monitoring (10)
PERFORMANCE
18. Performance Management Control (6)
(34)
19. Performance Analysis (11)
20. Prevention (5)
21. Detection (10)
SECURITY
22. Containement and Recovery (16)
23. Security Administration (24)
(55)
Tavola 5.1.1 – Aree Funzionali di Gestione (5) e Gruppi di Insiemi di Funzioni di Gestione (23) secondo
la Raccomandazione ITU-T M.3400 del 2/2000. I numeri fra parentesi indicano il numero di “Insiemi di
Funzioni” contenuti nei vari gruppi.
114
Serviziodi
di Gestione
Gestione
Servizi
(Sotto-modello Funzionale)
SMFA1
SMF
SMFA3
SMFA2
SMF
SMF
SMF
SMFA4
SMF
SMF
SMFA5
SMF
SMF
Servizi forniti da CMISE + SMASE
CMIS
(Sotto -modello Comunicativo)
Fig. 5. 1. 1 Relazione fra sottomodello funzionale e sottomodello comunicativo in OSI -SM
Ogni SMF include una mappatura della funzione di gestione (come percepita dall ’utilizzatore
del sistema di gestione) in servizi CMIS.
Come già detto, un servizio di gestione è supportato da una molteplicità di SMF.
appartenenti ad aree funzionali diverse. La relazione fra Management Services e System
Management Functions (SMF) è discussa nell’Appendice I della Raccomandazione M3400 (Vedi par.5.2 e Fig.5.2.1). Notare che, come si può riconoscere leggendo la
Raccomandazione ITU-T M.3400, ogni funzione di gestione SMF è formulata in maniera
tale da rendere facile una sua mappatura in servizi forniti dagli elementi CMISE e
SMASE, stabilendo così una relazione fra sottomodello funzionale e sottomodello
comunicativo precedentemente descritto. (Vedi Fig.5.1.1). In particolare le funzioni di
gestione SMF sono state descritte dall’ITU-T secondo un formato del tipo «Gestore
richiede Agente di effettuare una certa operazione su un certo oggetto gestito». Si tratta
di un formato particolarmente adatto ad essere interpretato in chiave CMIS. Ricordiamo
che l’elemento di servizio CMISE fornisce dieci servizi CMIS diversi (fra cui GET, SET,
CREATE e DELETE). Nella Fig. 5.1.1 notare come uno stesso «mattone» SMF possa
apparire in aree funzionali diverse. Questo equivale a dire che SMFA diverse possono
contenere lo stesso insieme/gruppo di insiemi di funzioni e quindi, da un punto do vista
grafico, i domini ellittici rappresentativi delle SMFA possono mostrare una parziale
sovrapposizione.
Inoltre ricordiamo che in un messaggio gestionale MA-PDU scambiato fra SMAE
Gestore e SMAE Agente l’informazione relativa ad una specifica SMF e’ incapsulata nel
contributo informativo fornito da SMASE (Vedi Fig.4.1.2 e 4.7.1).
Ora spieghiamo il significato delle cinque aree funzionali FCAPS facendo
riferimento al documento ITU-T M.3400 “TMN Management Functions” del 02/2000.
115
5.1.2 Gestione “Guasti” (Fault Management)
La Gestione “Guasti” è un insieme di funzioni SMF che permette la detezione,
isolamento e correzione di funzionamenti anomali di un sistema TLC. Esso fornisce
anche i mezzi per effettuare sia la manutenzione del sistema che le misure necessarie per
offrire una garanzia di qualità “RAS”, in termini di Reliability (Fidatezza), Availability
(Disponibilita’) e Survivability (Sopravvivenza).
5.1.3
Gestione “Configurazione” (Configuration Management)
La Gestione “Configurazione” è un insieme di funzioni SMF per controllare,
identificare, raccoggliere/fornire dati da/a elementi di rete (Network Elements, NE)
5.1.4
Gestione “Amministrazione” (Accounting Management)
La Gestione “Amministrazione” è un insieme di funzioni SMF per effettuare la
misura dell’utilizzo dei servizi, la determinazione dei relativi costi per i fornitori di
servizio e dei prezzi per i clienti.
5.1.5
Gestione “Prestazioni” (Performance Management)
La Gestione “Prestazioni” è un insieme di funzioni SMF per valutare/registrare
il comportamento della rete TLC o dei suoi elementi. Il suo scopo è
1) la raccolta/analisi di dati statistici al fine di gestire il comportamento/efficienza
della rete TLC o dei suoi elementi
2) aiutare a pianificare, realizzare, manutenere (QoS) la rete TLC o i suoi elementi.
5.1.6
Gestione “Sicurezza” (Security Management)
La Gestione “Sicurezza” è un insieme di funzioni SMF che identificano
1) attività di autenticazione, controllo di accesso, controllo confidenzialità/integrità
dati, relative a comunicazioni fra sistemi (in senso OSI), fra sistemi e clienti, fra
utilizzatori interni e sistemi,
2) attività di detezione di violazioni della sicurezza e.g. presenza di clienti non
autorizzati, manomissione di equipaggiamento etc.
116
5.2 Esempio di come utilizzare le Funzioni di Gestione
(SMF) per realizzare un Servizio di Gestione TMN.
La Fig. 5.2.1 (da Racc. M.3400, pag.86) é un diagramma di flusso (di
informazione gestionale) che mostra come insiemi di SMF appartenenti a varie aree
funzionali FCAPS contribuiscano ad effettuare un “Controllo Traffico di Rete”,
sottoinsieme del Servizio di Gestione TMN “Traffic Management (Gestione del
Traffico)”. Il controllo traffico di rete cambia gli schemi di instradamento del
traffico in rete in risposta a una possibile causa primaria e.g.
1) Carenza di capacità disponibile (trasporto o switching) dovuta ad un sovraccarico in
una certa zona della rete (risposta realizzata con SMF dell’Area funzionale
“Performance”)
o in risposta alle cause secondarie,
2) Cambiamenti nella domanda d’utente che richiede una riconfigurazione di rete
(risposta nell’ Area funzionale “Configuration”)
3). Guasto in rete (risposta nell’ Area funzionale “Fault”)
In Fig.5.2.1 il flusso di dati rappresentato dalla freccia No.1 serve solo a mostrare
che, prima di ogni altra cosa, nel sistema gestionale si deve installare la funzionalità
dell’insieme SMF “Traffic Control” (Vedi sotto) tramite svolgimento dell’insieme SMF
.”Network Traffic Management Policy” (Vedi sotto) che specifica le politiche
gestionali del sistema stesso. La sequenza temporale secondo cui le varie SMF
vengono effettivamente svolte inizia con un segnale di ingresso (No. 2) che notifica
l’esistenza di un sovraccarico di traffico in una zona della rete. Quindi in effetti in
Fig.5.2.1 la sequenza di SMF inizia con il flusso di dati No.2.
In Fig.5.2.1 l’area funzionale maggiormente utilizzata é la “5. Performance
Management” (cioè la “P” in FCAPS) di cui sono utilizzati i due gruppi di insiemi
SMF comprensivi dei seguenti insiemi di SMF
i) Insiemi SMF appartenenti al Gruppo di Insiemi “5.3 Performance Management
Control” (Gestione delle Operazioni di rete) (Quattro rettangoli gialli a sinistra nella
figura)
5.3.1 Network Traffic Management Policy = Politiche di controllo di traffico in varie
parti della rete (sottoreti) e piani per controllare eventuali situazioni di congestione di
traffico
5.3.2 Traffic Control = Crea e/o modifica schemi di instradamento del traffico in rete
al fine di rimuovere congestioni di traffico (Applicazione/modifica o rimozione dei
controlli)
117
5.3.3 Traffic Administration = Definizione/Cambio/Rimozione dei programmi di
misura (measurement schedules) del traffico in rete (tipo, tempi, periodicità delle
misure, etc.) o dell’informazione contenuta nelle tabelle di instradamento (routing
tables)
5.3.5 Execution of Traffic Control = Comandi di esecuzione del controllo di traffico
e accesso ai risultati delle operazioni di controllo.
(Le sequenze numeriche prima del nome indicano la classifica in Racc. M.3400)
ii) Insiemi SMF appartenenti al Gruppo di Insiemi “5.2 Performance Monitoring”
(Raccolta continua di dati relativa alle prestazioni di elementi di rete o di sottoreti)
(Due rettangoli verdi in basso a destra nella figura)
5.2.10 Detection, counting, storage and report = Rapporto sui risultati di misura,
raccolta e immagazzinamento dati relativi alle prestazioni dei singoli elementi di rete
5.2.6 Traffic Performance Monitoring = Monitoraggio del traffico in sottoreti.
5.2.5 Traffic Status = Fornitura di informazione relativa allo stato del traffico in una
sottorete
In risposta alle cause secondarie vengono usate SMF appartenenti alle aree
funzionali “Configuration” e “Fault”. (Rettangoli tratteggiati)
Nell’area funzionale “7. Configuration Management” appaiono i seguenti
Gruppo di Insiemi e Insiemi SMF,
7.5 Status & Control
7.5.5 Transport Network Status = Supporto di richieste di cambiamento di stato di
una rete di trasporto o suoi elementi multiplexer, rigeneratore, autocommutatore etc.)
7.4 “Provisioning”
7.4.9 Interexchange Circuit Design = Supporto di richieste di selezione di circuiti
“interexchange” e.g. message trunks (progetto delle risorse e demand forecasting)
Nell’area funzionale “6. Fault Management” appaiono i seguenti Gruppi di
Insiemi e Insiemi SMF,
6.2 Alarm Surveillance
6.2.2 Network Fault Event Analysis Including Correlation and Filtering = Analisi
dei guasti includendo correlazione e filtraggio
118
5.3 La serie X730-X750 delle raccomandazioni ITU-T
(System Management Functions, SMF’s).
Per completezza e per coloro interessati a visionare i documenti originali,
vogliamo ricordare che già nel documento X.700 l’ITU-T aveva suddiviso le funzioni
per la gestione di sistema in cinque aree funzionali : Fault (Guasti), Configuration
(Configurazione), Accounting (Fatturazione), Performance (Funzionamento) e
Security (Sicurezza). (Modello FCAPS). Riportiamo qui di seguito l’elenco
bibliografico delle funzioni per la gestione di sistema come pubblicate nella serie di
documenti OSI dall’X.730 all’X.752. Queste funzioni sono funzioni gestionali
generiche che sono state poi usate dalle funzioni di gestioneTMN (TMN Management
Fuctions) riportate nel documento ITU-T M.3400 a cui abbiamo fatto cenno in
preceenza.
FUNZIONI per la GESTIONE di SISTEMA (System Management Functions)
RACCOMANDAZIONI ITU-T (Serie ISO/IEC 10164)
X.730
- Object Management Function
X.731
- State Management Function
X.732
– Attributes for Representing Relationships
X.733
– Alarm Reporting Function
X.734
– Event Report Management Function
X.735
– Log Control Function
X.736
– Security Alarm Reporting Function
X.740
– Security Audit Trail Function
X.741
– Objects and Attributes for Access Control
X.742
– Accounting Meter Function
X.739
– Workload Monitoring Function
X.745
– Test Management Function
X.738
- Measurement Summarization Function
X.737
– Confidence and Diagnostics Test Classes
X.746
– Scheduling Function
X.750
– Management Knowledge Management Function
119
X.743
– Time Management Function
X.744
– Software Management Function
X.747
– General Relationship Model
X.748
– Response Time Monitoring Function
X.749
– Management Domain Management Function
X.751
– Changeover Function
X.752
- Enhanced Event Control Function
120
Performance
Mngmt
Control
Performance
Monitoring
CONFIGURATION
Status & Control (SMFSG)
Network Traffic Management
Policy (*)
- Transport network status
10
CONFIGURATION
Provisioning (SMFSG)
1
- Inter-exchange circuit design
9
Traffic Control (4SMF)
8
3
4
6
Network fault event analysis
including correlation & filtering
- Traffic performance
monitoring (12SMF)
-Traffic status (9SMF)
Traffic Administration
(5SMF)
5
Execution of Traffic Control (*)
FAULT
Alarm Surveillance (SMFSG)
2
7
SEGNALAZIONE DI SOVRACCARICO
Detection, counting,
storage & reporting (*)
Fig. 5.2.1 Potenziale scenario per “Controllo Traffico di Rete” (parte di un Servizio di Gestione
“Gestione di Traffico”). Aree Funzionali: Performance (Bordo continuo), Fault e Configuration
(Bordo tratteggiato). Gruppi di insiemi: Performance Management Control (giallo), Performance
Monitoring (verde). L’asterisco indica assenza di SMF in M.3400.
121
CAPITOLO 6
Il Modello TMN dell’ ITU-T
6.1 Introduzione
Nei precedenti capitoli abbiamo mostrato come il modello OSI-SM fu sviluppato
per facilitare l’interconnessione fra sistemi aperti che giocano i ruoli di Gestore e
Agente in ambienti eterogenei cioè, come si suole dire in forma abbreviata, fu sviluppato
per risolvere il problema della “interoperabilità eterogenea” nelle reti di gestione. Il
modello/standard TMN (Telecomunications Management Network, Rete di Gestione per
Telecomunicazioni) fu sviluppato dall’ITU-T con lo scopo di fornire ai gestori di reti
TLC una architettura di sistema atta a gestire una qualsiasi rete TLC (e.g. reti SDH,
ATM, Frame Relay, telefonia fissa e mobile etc.) utilizzando il modello OSI-SM.
OS
OS
OS
OS
OS
Altra TMN
OS
RETE COMUNICAZIONE DATI
(DCN)
WS
Interfaccia
uomo-macchina
TMN
RETE DI TELECOMUNICAZIONE
OS
SISTEMA d' ESERCIZIO
ELEMENTO DI RETE (NE)
WS
STAZIONE DI
LAVORO
Fig.6.1.1 La rete di gestione TMN (Telecommunications Management Network)
122
Quindi i modelli OSI-SM e TMN, pur rivolgendosi a problematiche diverse i.e.
rispettivamente interoperabilità eterogenea e architettura di un sistema gestionale, sono
strettamente relazionati. L’utilizzazione dei concetti OSI-SM per risolvere i problemi di
scambio di informazione gestionale all’interno di una rete TMN ha portato a parlare
addirittura di modello TMN/OSI.
Il modello TMN, fu introdotto inizialmente dal CCITT (Comitè Consultatif
International Telegraphique et Telephonique) e dal ETSI (European Telecommunication
Standard Institute) e poi dall’ITU (International Telecommunication Union). La
definizione di TMN fornita dall’ ITU è del tutto generica (Raccomandazione M.3010 del
2/2000):
DEFINIZIONE DI TMN (ITU-T): La TMN è una architettura per la gestione
(pianificazione, installazione, attivazione, mantenimento, operazione e
amministrazione) di apparati, reti e servizi di telecomunicazione.
Il modello TMN prevede che la TMN sia concettualmente separata dalla rete
TLC sulla quale opera. Per questo la TMN è mostrata in Fig.6.1.1 contenuta in un piano
verticale perpendicolare ad una rete TLC gestita, posta in un piano orizzontale. Come
mostrato in Fig. 6.1.1 all’interno della TMN lo scambio di informazioni gestionali
avviene essenzialmente fra i Sistemi d’Esercizio (OS, Operations Systems), che espletano
il ruolo gestionale di Gestore nei confronti di Elementi di Rete (NE, Network Elements),
che espletano un duplice ruolo: il ruolo gestionale di Agenti e il ruolo primario di
elaborazione di informazione U & S e.g. come autocommutatori o mezzi di trasporto
elettromagnetico in una rete TLC. Per questo gli Elementi di rete appartengono sia alla
TMN che alla rete TLC e sono mostrati in Fig.6.1.1 a cavallo del confine della TMN
(cioè sono in parte interni in parte esterni alla TMN). Lo scambio di informazione
gestionale Gestore-Agente avviene tramite una rete dati (DCN, Data Communication
Network) che può comprendere una combinazione LAN, MAN, WAN mentre l’accesso
all’informazione gestionale da parte di un utilizzatore umano (faccia sorridente) avviene
tramite una postazione di lavoro (Work Station, WS). La figura mostra anche come
l’interfaccia uomo-macchina non faccia parte dello standard TMN e quindi anche la
postazione di lavoro è ubicata a cavallo del confine TMN.
Talvolta la separazione concettuale rete TMN-rete TLC corrisponde ad una
separazione fisica. La separazione fisica offre vantaggi e svantaggi. Un vantaggio è
certamente l’abilità della TMN a gestire guasti anche quando la rete TLC non funziona.
Uno svantaggio è l’aumento dei costi e la complessità aggiuntiva. Inoltre la TMN stessa
puo’ malfunzionare e quindi serve in ogni caso che la rete di gestione abbia un suo
sistema di gestione. Il modello TMN prende in considerazione anche la gestione della
TMN, tuttavia, in questo corso noi non ci occuperemo della gestione della rete di gestione
(il gestore del gestore!).
123
6.2
La storia della TMN: raccomandazioni ITU-T relative
alla serie M.3xxx
Il modello TMN è descritto nelle raccomandazioni ITU-T appartenenti alle serie:
M (TMN and Network Maintenance),
X (Data Networks and Open System Communications),
Q (Switching and Signalling),
G (Transmission Systems and Media, Digital Systems and Networks)
ma principalmente nella serie M. (Vedi Fig.6.2.1)
Il processo di standardizzazione TMN inizio’nel 1985 e la prima
raccomandazione (M.30) fu pubblicata nel “blue book” del CICTT nel 1988. Nel 1992
una versione completamente revisionata della TMN fu pubblicata come raccomandazione
M.3010. Caratteristica di questa nuova versione fu l’inclusione di un certo numero di
concetti presi in prestito dal modello OSI di gestione reti sviluppato indipendentemente
dall’ ISO (International Standard Organization) e definito nelle seguenti
raccomandazioni:
ISO 9595: ”Information Processing Systems - Open Systems Interconnections –
Common Management Information Service Definition”, Geneva, 1990.
ISO 9596: ”Information Processing Systems – Open Systems Interconnections –
Common Management Information Protocol”, Geneva, 1991.
ISO DIS 10165-1: “Information Processing Systems – Open Systems Interconnections –
Part1: Management Information Model”, Geneva 1993. (Noto come “OSI
Management Information Model” e pubblicato anche come raccomandazione
CICTT X.720)
I concetti principali presi in prestito dalla TMN erano il paradigma “GestoreAgente” e l’approccio “Object-oriented”. Tuttavia la TMN conservò due caratteristiche
che il modello OSI non possedeva e cioè la molteplicità delle architetture di riferimento
(il modello OSI ha una sola architettura di riferimento, quella a sette strati) e la netta
separazione fra rete di gestione e rete gestita.
La raccomandazione M.3010 del 1992 fu ulteriormente modificata e apparve nel
1996 con la stessa numerazione (“CCITT. Recommendation M.3010 “Principles of
Telecommunication Management” Gennaio 1996). I cambiamenti piu’ importanti
rispetto alla versione del ’92 erano relativi alla inclusione di una architettura stratificata
chiamata “ TMN Logical Layered Architecture”.
La M.3010 del ’96 è stata abrogata nel Febbraio 2000 e sostituita con l’ultima
versione “Principles for a telecommunication management network”, Febbraio 2000.
Nella descrizione della TMN noi faremo riferimento sia alla versione 1996 che alla
versione 2000 indicando di volta in volta di quale versione si tratta.
Altre raccomandazioni della serie M sono state aggiornate nel 2000. Esse sono la
M.3000, M.3013, M.3020, M.3100, M.3200, M.3400. La Fig. 6.2.1 mostra le principali
124
raccomandazioni della serie M.3xxx e le relazioni che intercorrono fra di esse. Nella
stessa figura sono mostrate anche raccomandazioni della serie X e Q che contengono
informazioni utilizzate nella serie M. La Tavola 6.2.2 mostra le raccomandazioni piu’
importanti della serie M.3xxx aggiornate al 2000.
6.3 Importanza dello standard TMN
Le ragioni principali per cui a fine anni 90 il modello TMN ha giocato un ruolo
importante nell’ambito della gestione di reti e elementi di rete TLC sono:
1) Architettura di riferimento condivisa da molti operatori del settore La TMN,
seppur criticata da molte parti, rappresenta pur sempre una architettura di
riferimento condivisa da numerosi operatori del settore, facilitando così una
cooperazione nella valutazione e sviluppo dei sistemi di gestione per reti e
elementi di rete TLC (non tanto per i servizi TLC e ancor meno per la gestione di
impresa),
2) Completezza di rappresentazione. Sebbene appesantito da molti elementi
normativi e rilevante a scenari “tecnologicamente neutri” talvolta troppo astratti (e
quindi potenzialmente distanti dalla realtà pratica delle reti TLC), il modello
TMN è non solo una elegante architettura concettuale ma anche un poderoso
strumento per avere una visione completa delle complessità fisiche e funzionali
inerenti ai sistemi di gestione per reti TLC generiche.
3) Base di partenza per nuove generazioni di sistemi gestionali. La TMN ha
costituito la base di partenza per sviluppare nuove generazioni di sistemi
gestionali da parte di numerose organizzazioni (e.g. modello TMF del TeleManagement Forum). In pratica, possiamo riassumere quanto detto come segue.
Inoltre, la conoscenza della TMN fa sì che:
1) alcune funzionalità gestionali importanti non vengano “ignorate”
2) permette (in particolare il modello TMN stratificato) di capire meglio i modelli
gestionali più recenti molti dei quali sono basati proprio sul modello TMN e.g. il modello
e-TOM (enhanced-Telecommunications Operation Map) del TMF (Tele-Management
Forum)
3) la sua popolarità permette di poter discutere di gestione di sistemi TLC con
colleghi appartenenti ad altre unità organizzative all’interno della stessa azienda sulla
base di un modello comune di riferimento
125
Overview of TMN
Recommendations
M3000
TMN Terminology and
Definitions
M60
Principles of a TMN
M3010
TMN Interface
Specification
Methodology
M3020
Abstract Synthax
Notation No.1
(ASN.1) X.208
Fig.6.2.1
Manag. Inf. Model X.720
Definition of Manag. Inf.
X.721
Guidelines for the Definition
of Managed Objects X.722
Generic Network Inform.
Model for TMN M.3100
TMN Management
Service Introduction
M.3200
TMN Management
Capabilities at FInterface M.3300
TMN Management Services
M.32xx
Managed Object
Conformance Statement
M.3101
Catalogue of TMN
Management
Information M.3180
Management of ISDN
M.36xx
TMN Management
Functions M.3400
SS n.7 Management
Q.75x
Management of Transport
Networks G.7xx
126
Stage 1,2 and 3
Description for Q3
Interface
Q.821 / Q.822 / Q.82x
Tavola 6.2.2: Raccomandazioni TMN della Serie M.3xxx
NUMERO
Titolo
Overview of TMN Recommendations
M.3000
Principles for a TMN
M.3010
TMN interface specification methodology
M.3020
Generic network information model
M.3100
Managed object conformance statements for the generic network inf.
M.3101
model
Catalogue of TMN management information
M.3180
TMN Management Services: Overview
M.3200
TMN management Services: Maintenance aspects of B-ISDN
M.3207.1
management
TMN management Services: Fault and performance mgt. of the ISDN
M.3211.1
access
TMN management capabilities presented at the F interface
M.3300
Management requirements framework for the TMN X-interface
M.3320
TMN management functions
M.3400
DATA
02/00
02/00
02/00
02/00
07/95
10/92
02/00
05/96
05/96
10/92
04/97
02/00
6.4 Le quattro architetture TMN
Il “modello TMN” offre uno standard per le Reti di Gestione dei sistemi TLC. Il
modello TMN si articola in “architetture” di diversa natura. Le diverse architetture sono
modelli della TMN «osservata» da diversi punti di vista fra loro complementari.
Abbiamo già illustrato il concetto di «punto di vista » da cui «osservare» un sistema nella
prima parte del corso. Ad esempio se si esamina la rete di gestione dal punto di vista
delle sue caratteristiche fisiche, il modello TMN descrive una “architettura fisica”.
Analogamente, le varie funzioni gestionali espletate dalla TMN sono modellizzate da una
“architettura funzionale”. Le modalità degli scambi di informazione gestionale
all’interno della TMN o fra TMN e rete gestita sono descritte da una “architettura
informativa” che avviene secondo OSI-SM (e non verrà ulteriormente trattata in questo
capitolo). Le tre architetture, fisica, funzionale e informativa, ottenute osservando la
TMN dai corrispondenti punti di vista, sono complementari e mutuamente indipendenti e
l’aggregazione delle tre architetture permette di ottenere una descrizione/specifica
completa della TMN.
La gestione della rete e dei servizi si può anche esaminare e strutturare sulla base
delle fasce di responsabilità e obiettivi da raggiungere esistenti all’interno
dell’organizzazione del gestore. Come già indicato nei paragrafi precedenti la
raccomandazione TMN M.3010 del 1996 ha introdotto una architettura stratificata in
quattro “livelli logici”, chiamata “Architettura Stratificata a Livelli Logici (Logical
Layered Architecture, LLA)” (da noi chiamato il modello TMN stratificato) che riflette
127
proprio questo punto di vista. Come già spiegato in precedenza i livelli logici, (così
chiamati perchè rappresentativi di attività gestionali e non di oggetti fisici), si riferiscono,
in ordine di astrazione decrescente , rispettivamente alla gestione di 1) impresa, 2)
servizi, 3) rete e 4) elementi di rete, riflettendo la struttura organizzativa del gestore . La
architettura stratificata LLA è quindi la quarta architettura introdotta dal modello TMN.
6.5 L’ architettura funzionale TMN (Fig. 6.5.1 e 6.5.2)
•
I quattro elementi dell’architetture funzionale
L’architettura funzionale della TMN descrive come le funzionalità gestionali sono
distribuite in una rete TMN. Essa contiene quattro elementi fondamentali (Vedi
Fig.6.5.1)
1. Blocco Funzionale. L’architettura funzionale possiede una struttura
modulare con moduli costituiti da “Blocchi Funzionali” che a loro volta
contengono “Componenti Funzionali” realizzabili con pacchi software
commercialmente disponibili. Lo standard TMN del 1996 prevedeva cinque
blocchi funzionali (OSF, NEF, WSF, MF, QAF, vedi dopo) mentre nello
standard TMN 2000 i due blocchi funzionali di mediazione e adattamento,
rispettivamente MF e QAF, sono conglobati in un unico blocco di
trasformazione (TF) e quindi TMN 2000 contiene solo quattro blocchi
funzionali. Un blocco funzionale, sebbene non monolitico, è definito come “la
più piccola unità di funzionalità gestionale che può essere installata in una
rete TMN”. Ogni blocco funzionale svolge una “Funzione Applicativa di
Gestione, MAF”, specifica. Inoltre comprende componenti funzionali di
supporto fra cui “Data Communication Function, DCF” (strati OSI 1-3) e
“Message Communication Function, MCF” (strati OSI 4-7) che servono a
trasferire informazione gestionale fra i vari blocchi. (Vedi Fig. 6.5.3 per il
blocco OSF). Lo scopo della suddivisione di un blocco in componenti è far sì
che questi possano essere realizzati come pacchi software commercialmente
disponibili e facilmente assemblabili.
2. Funzione Applicativa di Gestione (Management Application Function,
MAF) chiamata brevemente Funzione MAF. Abbiamo detto che all’interno
di un blocco funzionale esiste una Funzione MAF specifica del blocco. Essa
è definita anche come “una componente della funzionalità di un Servizio di
Gestione fornito dalla TMN ai suoi utilizzatori”, tecnoservizio definito dal
modello FCAPS (vedi par.5.1).
128
Punto di vista Utilizzatore
Servizi di Gestione TMN
(M-3200)
Punto di vista del Progettista rete
TMN
Servizio
Gestione
TMN
OSF
MAF
MCF
WSF
MAF
MCF
Insieme o
Gruppo di
insiemi di FG
NEF
MAF
MCF
Funzione di
Gestione
(SMF)
)
MCF
TF
MAF
L’interazione cooperativa delle MAF nei blocchi
funzionali realizza una Funzione di Gestione (SMF).
Fig.6.5.1 L’architettura funzionale M.3010 (02/2000) contiene quattro blocchi funzionali: OSF
(Funzione sistema d’esercizio), WSF (Funzione postazione di lavoro), TF (Funzione di trasformazione)
e NEF (Funzione elemento di rete). I Servizi di Gestione TMN sono definiti dall’ ITU-T nella
raccomandazione M-3200 (vedi anche par. 6.8). La componente MCF (Message Communication
Function) realizza il processing end-to-end degli strati 4 -7 della pila OSI. La componente DCF (Data
Communication Function) realizza il processing relativo agli strati 1-3 della pila OSI. Due blocchi
funzionali comunicano via MCF (Message Communication Function) ma con l’ausilio di DCF nel caso
appartengano a blocchi fisici diversi i.e, il punto di riferimento fra loro è una interfaccia.
Ciò è mostrato in Fig.6.5.1. La Fig.6.5.1 mostra come un Servizio di Gestione
sia costituito da un insieme di funzioni di gestione SMF (System
Management Function) e come ogni SMF venga realizzata nella TMN da
MAF svolte da blocchi funzionali di quattro tipi (modello TMN 2000).
3 Funzione di Gestione TMN (SMF), é la più piccola parte di un Servizio di
Gestione come percepita da un utilizzatore della rete TMN. Dal punto di vista
129
di un progettista di una rete TMN una SMF è il risultato di una interazione
cooperativa fra MAF appartenenti a blocchi funzionali diversi (Fig.6.5.1).
4 Punto di Riferimento, definito come “concetto architetturale usato per
delineare blocchi funzionali”, in pratica si tratta del punto di separazione
fra blocchi funzionali.
Ogni funzionalità gestionale della TMN può essere descritta in termini di questi
quattro elementi che sono mutuamente relazionati (come specificato nella architettura
funzionale).
La Fig.6.5.1 mostra come 1) i blocchi funzionali sono separati da punti di
riferimento (cerchi rossi), 2) ogni blocco funzionale implementa un tipo particolare di
Management Application Function, MAF, 3) una interazione cooperativa fra MAF
di blocchi funzionali diversi realizza una SMF (Punto di vista del progettista della TMN).
4) Una SMF è un elemento costitutivo di un Servizio di Gestione come definito in
FCAPS (Punto di vista dell’utilizzatore di TMN cioè del Gestore della rete TLC).
Inizialmente (1996) il modello TMN prevedeva cinque blocchi funzionali (Vedi
Fig.6.5.2):
1.
Blocco funzionale Sistema d’Esercizio (OSF, Operations Systems
Function) contiene una Management Application Function (MAF) tipica di un
“Gestore” di elementi di rete, reti, servizi e impresa TLC (Vedi Fig.6.7.1). Nel
caso in cui il Gestore interagisca con altri Gestori (e.g. architettura “Manager-ofManagers”, vedi Fig. 6.1.1) questo blocco funzionale può contenere anche MAF
nel ruolo “Agente”. Notare che nel modello TMN la ITU-T non distingue fra OS
(Operations System, Sistema di Esercizio), OSS (Operation Support System,
Sistema di Supporto alla Operativita’), NSS (Network Support System, Sistemi di
Gestione Reti) o BSS (Business Support System) come invece avviene nella
gestione di sistemi TLC non a norma TMN.
2.
Blocco funzionale Elemento di Rete (NEF). Due tipi di funzioni vengono
espletate all’interno di un elemento di rete: 1) funzioni primarie relative allo
scambio di messaggi TLC fra elementi di rete e 2) funzioni di gestione relative
allo scambio di dati gestionali con i sistemi operativi di gestione (OS). Le prime
non fanno parte dello standard TMN. Per questa ragione parte del blocco
funzionale NEF è graficamente rappresentato fuori dal dominio (rettangolo) TMN
in Fig.6.5.2 La funzione di gestione principale svolta da questo blocco è quella di
“Agente” che interagisce con il “Gestore” identificato nel blocco OSF. In
Fig.6.5.2 “NS” significa “Non Standard”.
3.
Blocco funzionale di Mediazione (MF). Serve a far sì che NEF con punti
di riferimento standard (e.g. indicati con il simbolo qx) possano comunicare con
altri blocchi funzionali con diversi punti di riferimento (e.g. OSF con q3 oppure
WSF con f). Più precisamente i blocchi MF fanno sì che le informazioni
gestionali originate da vari tipi di NE e ricevute dagli OSF (o fra OSF e QAF nel
caso di NE non a norma) siano comprensibili al blocco OSF che le riceve. Un
130
blocco MF può espletare una varietà di funzioni di mediazione come
immagazzinamento temporaneo dei dati per evitare fenomeni di congestione
(buffering), conversione di protocollo, filtrare, sintetizzare dati gestionali (i.e. più
messaggi gestionali provenienti da più NEF possono essere correlati e il risultato
inglobato in un unico messaggio a OSF), risolvere problemi di sicurezza (e.g.
NEF e OSF possono avere criteri di accesso con formati diversi) etc.
4.
Blocco funzionale Postazione di Lavoro (WSF). Fornisce i mezzi
necessari per interpretare/rappresentare le informazioni TMN da parte degli
“addetti” alla TMN. Inoltre fornisce le funzioni di supporto per l’interfaccia
uomo-Risorsa TLC (punto di riferimento “g”). Tuttavia queste ultime non fanno
parete dello standard TMN. Per questa ragione, il punto di riferimento “g” è
rappresentato graficamente al di fuori del dominio TMN.
5.
Blocco funzionale Adattamento di Interfaccia Q o Q-Adattatore (QAF).
Questo blocco rappresenta le funzioni necessarie a connettere NE non a norma
TMN alla rete TMN. Il traffico gestionale attraverso il punto di riferimento “m”
non è standardizzato e quindi il punto “m” è situato fuori del dominio TMN.
In tempi più recenti (anno 2000) nell’ultima versione della raccomandazione
M.3010 i blocchi funzionali MF e QAF sono stati consolidati in un unico blocco
funzionale di Trasformazione (TF) il cui scopo è quello di permettere la connessione
fra due blocchi funzionali che operano in ambienti diversi. Questi «ambienti» possono
essere protocolli comunicativi e/o modelli informativi. Il blocco TF puo’ essere posto
all’interno del dominio TMN (rettangolo tratteggiato in Fig.6.5.2) come un blocco
MF o sul confine della TMN come il blocco QAF.
I blocchi funzionali sono separati da “punti di riferimento” che rappresentano i
punti attraverso i quali fluiscono le informazioni gestionali scambiate fra due blocchi
funzionali coinvolti in una associazione. In Fig.6.5.2 sono mostrati sei punti di
separazione fra blocchi funzionali (punti di riferimento) individuati con le lettere
minuscole q3, qx, f, x, m, g.
•
Modello funzionale dell’anno 2000
Questo modello è quello del 1996. Recentemente (2000) ma con l’introduzione
del blocco funzionalt TF in sostituzione dei due blocchi QAF e MF, i due punti di
riferimento q3 e qx sono stati consolidati in un unico punto “q” cosicchè il numero dei
punti di riferimento si riduce ora a cinque: tre interni al dominio TMN (i.e. q, x, f ) e due
esterni (m, g).
131
TMN
x
OSF
q3
x
OSF
OSF=Blocco Funzionale
Sistema d’ Esercizio
f
f
g
WSF=Blocco
Funzionale
Postazione di Lavoro
WSF
q3
f
f
MF
MF=Blocco Funzionale
Sistema di Mediazione
q3
QAF
m
NS
NEF
qx
q3
NEF
MF
qx
qx
NEF
QAF
NEF=Blocco Funzionale
Elemento di Rete
QAF=Blocco Funzionale
Adattatore Interfaccia Q
m
NS
NEF
Fig.6.5.2. TMN: Architettura funzionale (1996). I cerchi verdi rappresentano i punti di riferimento
attraverso i quali avviene lo scambio di informazione gestionale fra blocchi funzionali.
132
•
Struttura interna di un blocco funzionale (Fig.6.5.3)
Ogni blocco funzionale non e’ monolitico ma, come il termine suggerisce,
costituisce un “blocco” di funzioni, chiamate componenti funzionali , appartenenti a due
categorie: le funzioni applicative di gestione MAF (Management Application Function) e
le funzioni di supporto che aiutano le funzioni MAF a interagire con altre funzioni MAF
residenti in blocchi funzionali remoti. Le funzioni MAF all’interno di ogni blocco (Vedi i
documenti della serie ITU-T M.32xx) supportano le applicazioni gestionali specifiche di
quel blocco. L’argomento verrà ripreso nel paragrafo 6.8. La Fig.6.5.3 mostra un blocco
.
TMN
OSF
WSSF
DSF
x
MCFx /
DCFx
SF
OSF-MAF Agent
f
MCFf /
DCFf
WSF
DBF
UIF
f
OSF-MAF Manager
MF
MCFq /
DCFq
q3
q3
NEF
qx
QAF
Fig.6.5.3 Struttura interna di un blocco funzionale sistema d’esercizio (OSF). Il blocco può contenere solo
una funzione MAF nei due ruoli di gestore e agente. Le altre sono funzioni di supporto.
133
con le due MAF’s (Gestore e Agente) più le funzioni di supporto: DSF (Directory System
Function), DBF (Data Base Function), WSSF (Work Station Support Function), SF
(Security Function), UISF (User Interface Support Function). La MCF (Message
Communication Function) si riferisce ai tre strati più alti della pila OSI (4-6) mentre il
componente funzionale DCF (Data Communication Function) si riferisce ai rimanenti
strati inferiori (1-3)
6.6 Architettura fisica TMN
L’architettura fisica identifica la pratica realizzazione dell’ architettura funzionale
tramite “blocchi fisici” separati da “interfacce” standardizzate. Una stessa architettura
funzionale puo’ essere realizzata da diverse architetture fisiche con diverse topologie
(infatti ogni blocco fisico può contenere uno o più blocchi funzionali). In generale la
topologia della architettura fisica della TMN viene scelta in base a criteri stabiliti dal
Gestore. Ad esempio, si possono adottare architetture fisiche centralizzate o distribuite
ognuna delle quali usa diversi tipi di sistemi elaborativi con caratteristiche diverse e.g.
diverse capacità di processing. La Fig. 6.6.1 mostra un architettura fisica generica
introdotta nel 1996 costituita da varie tipologie di sistemi di gestione OS (Sistema
d’Esercizio), WS (Postazione di Lavoro), MD (Dispositivo di Mediazione) e QA (QAdattatore cioè Adattatore d’Interfaccia Q), due reti di distribuzione dati (locale e
dorsale) ed infine i sistemi gestiti NE (Elementi di Rete). L’architettura fisica definisce
anche interfacce di separazione fra i vari componenti attraverso le quali avviene lo
scambio di informazione gestionale secondo protocolli standardizzati che al livello
applicativo adottano il modello OSI-SM. Le interfacce fra blocchi fisici sono indicate con
lettere maiuscole (e.g. Q3) invece delle lettere minuscole (e.g. q3) usate per i punti di
riferimento fra blocchi funzionali.
Notare che, mentre l’ architettura fisica mostra chiaramente come i sistemi
d’esercizio OS svolgano funzione di gestione sugli elementi di rete NE, essa non mostra
il fatto che gli stessi sistemi d’esercizio OS gestiscono anche la rete nel suo insieme, i
servizi e l’impresa. Ovviamente questi aspetti non sono presi in considerazione nelle due
architetture TMN, funzionale e fisica, precedentemente illustrate ma verranno poi trattati
nel modello TMN stratificato, sebbene in modo del tutto marginale.
Nel Febbraio 2000 l’architettura fisica è stata aggiornata come segue.
1)
Come già fatto per i punti di riferimento nell’architettura funzionale, le
interfacce QX e Q3 sono state consolidate in un unica interfaccia Q.
2)
Gli apparati di mediazione MD (che forniscono una trasformazione di
protocollo e/o format di messaggi fra blocchi fisici TMN con
meccanismi di comunicazione incompatibili) sono stati sdoppiati in
blocchi fisici QMD in supporto di interconnessioni fra blocchi
all’interno di una TMN e blocchi fisici XMD in supporto di
interconnessioni fra OS in TMN diverse.
3)
I blocchi QA (Fig.6.6.2), Q-Adattatori cioè “adattatori” che forniscono
una trasformazione di protocollo e/o di modello informativo
134
TMN
OS
X, Q3, F
F
X
WS
WS
DCN (BACKBONE)
Q3, F
MD
Qx
Q3
Q3
DCN (LOCAL)
Qx
QA
QA
NE
Fig.6.6.1. Architettura fisica generica di TMN (1996).
135
Qx
NE
ADATTATORE DI INTERFACCIA Q3
CON RUOLO DI AGENTE (TNM)
QA
ELEMENTO DI RETE
00101001 t=t*
MNGMT DATA
COLLECTION
POINTS (e.g.
voltage data)
000
001
010
011
100
101
110
111
A
D
A
T
T
A
T
O
R
E
R/W
R/W
PROPRIETARY
DATA BASE
11001011 t=t*
CMIP-OSI
STACK
(AGENTE/MIB/
ADATTATORE)
M
I
B
G
D
M
O
A
G
E
N
T
E
Q3
EMLOS
INTERFACCIA
PROPRIETARIA (e.g.
TL1)
Fig. 6.6.2 L’ adattatore é l’elemento cruciale nello sviluppo del sistema gestito. Richiede la conoscenza
dell’interfaccia e della struttura dati proprietaria del NE (e.g. criteri di filtraggio dell’ agente e del NE diversi).
(TL1= Translation Language 1, Bell Operating Companies)
136
PdS
4)
fra blocchi fisici non-TMN e.g. NE e un OS all’interno della TMN.
sono stati sdoppiati in QA (Q-Adaptor) e XA (X-Adaptor). I blocchi
fisici QA si riferiscono ai punti di riferimento “m” e adattano
all’interfaccia Q o X.
Un blocco fisico può contenere più blocchi funzionali. La denominazione di un
blocco fisico è effettuata sulla base della funzionalità prevalente.(Vedi
Fig.6.6.3,4)
Punto di Rif.
a
BF
2
Interfaccia
c
BF
1
b
BF
Blocco
Funzionale
BF
3
BLOCCO FISICO
a
BF
1
BF
2
C
BLOCCO
FISICO No.2
B
BLOCCO
FISICO No.1
Fig.6.6.3
137
PdS
A
B
C
D
OSF
OSF
OSF
OSF
MF
MF
MF
MF
NEF
NEF
NEF
NEF
Fig.6.6.4
6.7 Architettura TMN stratificata (Logical Layered
Architecture, LLA)Fig. 6.7.1
La Logical Layered Architecture (LLA) della TMN è nata per soddisfare
l’esigenza di avere un modello gestionale adatto alla struttura organizzativa del
gestore (Telco). Infatti un ente di gestione di un sistema TLC ha diverse unità
organizzative (e.g. dipartimenti, sezioni, reparti etc.) con responsabilità gestionali
diverse e obiettivi da raggiungere di diversa natura (strategica, amministrativa, tecnica
ecc.). Ad esempio, alcune unità organizzative (in genere collegate direttamente con il
“senior management”) sono responsabili della gestione di impresa , altre unità di natura
commerciale sono responsabili della erogazione e mantenimento dei servizi e delle
relazioni con i clienti, altre unità tecniche sono responsabili della gestione di rete e del
funzionamento/manutenzione degli apparati e così via.
La LLA è una struttura stratificata gerarchica che rispecchia queste realtà. Essa è
costituita da cinque livelli gestionali (livelli logici) ordinati in una struttura gerarchica
come specificato nella Parte I del corso. Ogni livello dall’ 1 al 4 si riferisce a una
funzionalità OSF con una responsabilità gestionale specifica (Vedi Fig.6.7.1):
1) OSF-B, Gestione di impresa (“B” è la iniziale di Business) ha la responsabilità di
gestire l’impresa nel suo complesso e.g. politiche aziendali, analisi dei mercati,
formulazione obbiettivi strategici e strategie per raggiungerli, utilizzazione ottimale di
nuove risorse etc.). Per «politiche aziendali» si intendono gli insiemi di raccomandazioni
138
che definiscono le procedure/condizioni/limitazioni che caratterizzano la realizzazione di
varie attività aziendali. Questo strato tipicamente rappresenta funzionalità gestionali
proprietarie non-standardizzate ed è il regno del «senior upper management »
dell’azienda. Esso è stato incluso solo per indicare che nella gestione complessiva
d’impresa la sua presenza è necessaria e per ricordare che esso direttamente o
indirettamente interagisce con tutti gli altri strati.
2) OSF-S, Gestione dei servizi (e.g. offerta, assegnazione, erogazione, controllo QoS,
fatturazione di servizi TLC),
3) OSF-N, Gestione di rete (e.g. gestione degli instradamenti, supervisione
connessioni end-to-end). Questo strato offre allo strato superiore SML una vista
tecnology-independent
4) OSF-E, Gestione degli elementi di rete (e.g. configurazione e prestazioni di ogni
singolo elemento di rete) ha, su delega dello strato superiore NML, la
responsabilita’ di gestire ogni singolo elemento di rete. Inoltre i sistemi d’esercizio
OSF-E devono supportare l’interazione fra lo strato superiore NML e quello
inferiore NEL, processando opportunamente l’informazione gestionale scambiata
fra OSF-N e NEF. Questo strato offre allo strato superiore NML una vista
“vendor-independent”.
Al disotto del livello gestionale 4) contenente i blocchi funzionali OSF-E esiste un
quinto livello relativo ai blocchi funzionali NEF (Network Element Function) che
contengono una applicazione gestionale che svolge un ruolo di Agente (residente
nell’elemento di rete stesso). Il blocco funzionale NEF è il punto di contatto fra la rete
TMN e la rete TLC ed è suddiviso in funzionalità gestionali (parte della TMN) e
funzionalità primarie di telecomunicazione (parte della rete TLC e quindi al di fuori della
TMN). I blocchi funzionali NEF sono gestiti almeno dagli OSF-E e OSF-N
Negli anni, il concetto di gestione stratificata è diventato uno dei concetti più
importanti contenuti nel modello TMN. Questo concetto, introdotto inizialmente dalla
British Telecom nel 1989 (Boyd R.T., Brodrick K.J.: “Operational Support Systems for
the future Local Network”, BT Technology Journal, Vol. 7, No. 2, April 1989, page 136150) apparve come appendice nella prima versione (1992) del modello TMN dove venne
presentato come un generico “modello funzionale gerarchico di OSF”. Nel 1996 fu
trasportato nel testo principale della raccomandazione TMN M.3010. Scopo del “modello
funzionale gerarchico di OSF” era quello di individuare diversi livelli di OSF’s, senza
restrizione sul numero e caratteristiche dei livelli ma con una dipendenza gerarchica fra
due livelli contigui.
Notare che, sebbene non mostrato in figura, a ogni livello il Manager può essere
suddiviso in una serie di managers mutuamente interagenti, secondo una architettura di
cooperazione come illustrato nella Partre I del corso.
La ITU-T ha sviluppato standards per le interfacce fra livelli al fine di favorire
l’interoperabilità delle procedure di management ai vari livelli. Il piu’ grosso vantaggio di
139
IMPRESA
OSF-B
q3
SERVIZI
OSF-S
x
q3
X
RETE
OSF-N
q3
ELEM. RETE
OSF-NE
X
q3
ELEM. RETE
NEF
Fig. 6.7.1
xxxx
140
questo modello è quello di offrire una razionalizzazione completa di tutti i processi di
gestione che entrano in gioco nella gestione delle TLC e quali sono le loro relazioni
reciproche. Uno dei problemi di questo modello è che esso enfasizza la gestione degli
elementi di rete a scapito degli altri tipi di gestione e.g. reti, servizi e business. Potremmo
dire un modello piu’ ingegneristico che commerciale. In particolare il modello TMN
perde di vista il cliente cioè non è “customer centric”.
Queste argomentazioni sono particolarmente importanti per il Fornitore di Servizi
che interfaccia direttamente con l’utente e che è interessato principalmente a
modernizzare e rendere più efficiente il suo business. Per questo è di comune uso nel
campo delle telecomunicazioni un’altro modello, il modello sviluppato dal TeleManagement Forum noto come il modello TMF
6.8
Servizi di Gestione TMN, Funzioni di Gestione TMN e
Funzioni Applicative di Gestione (Funzioni MAF)
•
Servizio di Gestione TMN e sua suddivisione in Funzioni di Gestione TMN
elementari
Sinora abbiamo descritto la rete TMN in termini di architetture fisiche, funzionali
e informative le quali illustrano come avviene la distribuzione delle funzionalità,
dell’informazione gestionale e degli apparati all’interno della rete di gestione. Tuttavia la
rete TMN può essere vista anche come un sistema capace di fornire Servizi di Gestione
TMN (tecnoservizi) ai suoi utilizzatori cioè ai gestori di reti TLC.
Ma quali sono i servizi effettivamente disponibili ai gestori e.g. attraverso le
postazioni di lavoro WSF? Ad esempio se si vogliono gestire la “manutenzione” e i
“guasti” di una rete TLC, la TMN possiede le funzionalità necessarie alla fornitura di
questi servizi?
Un Servizio di Gestione TMN è definito nella raccomandazione M.3200 come
segue:
“Un Servizio di Gestione TMN é un area specifica di attività gestionale TMN relativa
ad un particolare aspetto della gestione di una rete TLC che viene utilizzata da un
utilizzatore della TMN”
Questo significa che la gestione complessiva di una rete TLC avviene utilizzando
vari Servizi di Gestione TMN. Ad esempio la gestione del traffico TLC è un servizio di
gestione TMN, la gestione dei guasti che si verificano nella rete TLC è un servizio di
gestione TMN, la gestione della TMN è anch’essa un servizio di gestione TMN.
L’ITU-T fornisce (Vedi Raccomandazione ITU-T M.3200) la seguente lista di 11
Servizi di Gestione (lista dichiaratamente non esaustiva e aggiornabile):
1. Customer Administration (Amministrazione Clienti)
2. Network Provisioning Management (Gestione Approvvigionamento
Rete)
141
3. Work Force Management (Gestione Forza Lavoro)
4. Tariff. Charging and Accounting Administration (Amministrazione
Tariffe e Addebiti)
5. Quality of Service (QoS) and Network Performance Administration
(Amministrazione della qualità di servizio QoS e della Prestazioni di
Rete)
6. Traffic Measurement and Analysis Administration (Amministrazione
Misura e Analisi Traffico)
7. Traffic Management (Gestione del Traffico)
8. Routimg Administration (Amministrazione degli Instradamenti)
9. Maintenance Management (Gestione Manutenzione)
10. Security Administration (Amministrazione Sicurezza)
11. Logistics Management (Gestione della Logistica)
Nel modello TMN, ogni Servizio di Gestione TMN offerto dalla TMN ai suoi
utilizzatori è decomposto in unità funzionali progressivamente sempre più specifiche fino
a funzionalità non ulteriormente decomponibili: le “Funzioni di Gestione TMN”. (Vedi
Fig.6.8.1 e Fig.6.5.1).
Quindi le Funzioni di Gestione TMN come già mostrato in Fig.6.5.1,
rappresentano l’ultimo gradino del processo di decomposizione dei Servizi di Gestione
TMN cioé l’utilizzatore della TMN residente in una postazione di lavoro non può
richiedere funzioni piu’ specializzate delle Funzioni di Gestione (funzioni atomiche non
ulteriormente divisibili).
Percorrendo in senso inverso il processo di suddivisione di un servizio di
gestione, cioè partendo dalle Funzioni di Gestione e aggregando progressivamente
funzioni fino a raggiungere i Servizi di Gestione (Vedi Fig. 6.8.1) si vede che le
Funzioni di Gestione si possono raggruppare in 260 “Insiemi di Funzioni” i quali a loro
volta possono raggrupparsi in 23 “Gruppi di Insiemi di Funzioni di Gestione i quali a loro
volta appartengono a cinque aree funzionali FCAPS (Vedi Tavola 5.1.1)
•
Il carattere elementare delle Funzioni di Gestione
Abbiamo detto che l’utilizzatore della rete TMN cioè il gestore della rete TLC
vede le Funzioni di Gestione come funzioni elementari messe a sua disposizione dalla
TMN. Per apprezzare questo fatto si raccomanda di leggere la Raccomandazione M.3400
e notare che ogni Insieme di Funzioni di Gestione é costituito da Funzioni di Gestione
che coprono i minimi dettagli dell’attività gestionale. Ovviamente il prezzo che si paga
per una specifica così dettagliata é l’alto numero di Funzioni di Gestione….si parla di
142
qualche migliaio. Ad esempio la specifica di una Funzione di Gestione é del tipo:
«Agente riporta a Manager………..su richiesta di un Operatore » oppure « Su richiesta di
Operatore, Manager richiede a Agente……… » e le operazioni richieste o gli eventi
notificati sono specificati nei minimi particolari. In questo contesto i termini Manager e
Agente vanno intesi come processi applicativi cooperanti nei ruoli di chi invoca
l’esecuzione di una operazione e chi risponde a questa invocazione. Ricordare che una
Funzione di Gestione, vista dal punto di vista della sua realizzazione all’interno di una
TMN, è stata definita come interazione cooperativa fra MAF in blocch funzionali diversi.
•
Relazione fra le Funzioni di Gestione TMN e le MAF.
E’ importante capire bene quale sia la relazione fra le Funzioni di Gestione
TMN e le Funzioni Applicative di Gestione MAF (Funzioni MAF) identificate nella
architettura funzionale TMN. Ribadiamo alcuni concetti gia’ esposti in precedenza. La
relazione é stata già mostrata in modo schematico in Fig 6.5.1
Le funzioni di gestione TMN sono supportate da funzioni MAF residenti nei
blocchi funzionali le quali a loro volta sono supportate da altre “Funzioni di base o di
supporto” anch’esse residenti nei blocchi funzionali (Fig.6.5.3). Più precisamente, “una
Funzione di Gestione é la risultante dell’interazione cooperativa di Funzioni MAF svolte
in blocchi funzionali diversi.
Una Funzione MAF caratterizza il blocco funzionale a cui essa appartiene. In
base al modello TMN 2000 ci sono quattro tipi di MAF: OSF-MAF, TF-MAF, WSFMAF, NEF-MAF (Fig.6.5.1).
Le Funzioni di Supporto assistono le funzioni MAF nell’ interazione fra
blocchi funzionali. Esempi di funzioni di supporto sono (Vedi Fig.6.5.3):
1) Funzione di Base Dati (DBF) cioè funzioni svolte da MIB (Management
Information Base). Relativa alla gestione dell’ insieme degli “oggetti” gestiti da un
blocco funzionale.
2) Funzione Comunicazione Dati. (DCF). La funzione DCF inizialmente era
riportata nello standard TMN come un blocco funzionale. Successivamente,
l’identità di blocco funzionale è stata rimossa. La DCF fornisce i livelli 1,2,3 della
pila OSI.
3) Funzione di Comunicazione di Messaggi (MCF), Message Communication
Function). Usata dai blocchi funzionali per scambiarsi messaggi, la cui natura
dipende dal tipo di punto di riferimento preso in considerazione. (“f”,”x” oppure
“q”). Fornisce funzioni end-to-end come quelle che si trovano nei livelli 5-7 della
pila OSI. Assieme alla DCF costituisce una pila di protocolli che permettono la
connessione fra i blocchi funzionali.
4) Funzione di Sicurezza. (SF)
5) Funzione di Interfaccia di Utente (UISF).
143
SERVIZIO di GESTIONE
(5) AREE FUNZIONALI
(SMFA)
(23) GRUPPI di INSIEMI di SMF
(260) INSIEMI di SMF
FUNZIONI di GESTIONE (SMF)
realizzato tramite
SMF appartenenti ad
alcune o a tutte le
cinque Aree
Funzionali
ogni area funzionale
divisa in Gruppi di
Insiemi di SMF
ogni Gruppo di insiemi
di SMF diviso in
Insiemi di SMF
ogni Insieme di SMF è
diviso in SMF
(specificato solo per
alcuni insiemi nella
M.3400 )
Fig.6.8.1
6.9 La standardizzazione delle interfacce TMN
Una rete TMN é caratterizzata da una molteplicità di interfacce fra i suoi blocchi
fisici e.g. l’interfaccia Q3 fra elementi di rete NE (gestiti) e sistemi d’esercizio OS
(gestori) o l’interfaccia X fra OS appartenenti a reti TMN diverse.
Il Modello di Riferimento OSI stratificato a sette livelli è stato applicato a queste
interfacce dall’ITU-T creando degli standards di interfaccia. Nel Modello OSI-SM si
devono distinguere i protocolli/servizi relativi ai livelli “inferiori” (da 1 a 4) e quelli
relativi ai livelli superiori (5,6,7).
I protocolli/servizi dei livelli inferiori sono indipendenti dalle particolari
applicazioni gestionali che operano nei livelli superiori e possono appartenere a due
diversi modi di operazione: “connection-oriented” o “connectionless” cioé con o senza
connessioni prestabilite prima del trasferimento di informazioni gestionali.
Al contrario, i protocolli/servizi dei livelli superiori, ed in particolare a livello
applicativo, sono tutti “connection-oriented” cioé esistono componenti applicative che
permettono di stabilire una associazione fra pari entità applicative (SMAE) residenti in
sistemi gestori e sistemi gestiti prima che avvenga lo scambio di informazione gestionale
144
e di eliminare questa associazione quando il trasferimento di informazione gestionale é
terminato (ricordare l’elemento di servizio ACSE).
La Fig.6.9.1 definisce lo standard di interfaccia Q3 per gli strati superiori della
pila OSI. I numeri si riferiscono ai documenti ITU-T dove sono definiti gli standards per i
vari livelli.
6.10 Esercizi (Capitolo 6)
1. Cosa é il modello TMN (Telecommunication Management Network) introdotto
dall’ITU-T ?
2. Come può un utilizzatore di una rete di gestione TMN accedere alla rete stessa?
3. Che relazione c’é fra il modello TMN e il Modello OSI-SM ?
4. Cosa é una “architettura” di una rete di gestione TMN? Cosa é un « Punto di
Vista » ?
5. Quali sono le architetture della TMN introdotte dall’ITU-T?
6. Cosa é l’architettura funzionale del modello TMN?
7. Cosa é l’architettura fisica del modello TMN?
8. Cosa é l’architettura informativa del modello TMN? In che cosa differisce
dall’architettura informativa OSI-SM?
9. Quali sono i quattro elementi fondamentali su cui si basa l’architettura funzionale
TMN?
10. Fare un disegno della struttura interna di un blocco funzionale OSF mostrando i
componenti funzionali. Quale é la differenza fra funzioni MAF (Management
Application Function) e le funzioni di supporto?
11. In un blocco funzionale OSF ci può essere una funzione OSF-MAF Gestore e una
OSF-MAF Agente. In un blocco NEF ci può essere una funzione NEF-MAF
Gestore e una funzione NEF-MAF Agente? Spiegare.
12. Nel modello TMN quale è la differenza fra i “punti di riferimento” nell’
architettura funzionale e le “interfacce” nell’architettura fisica?
13. Cosa é una interfaccia standardizzata Q3 ?
14. Che differenza c’é fra blocco funzionale e blocco fisico? Può un blocco
funzionale risiedere in due blocchi fisici ? Spiegare.
15. Nella architettura funzionale TMN che relazione c’é fra blocchi funzionali e
Servizi di Gestione TMN? Che relazione c’é fra le “funzioni di gestione TMN” e i
“Servizi di Gestione TMN”?
145
SMASE
CMISE
X.211/X.710
ACSE
X.227/X.217
Fig.6.9.1 Livelli alti della
pila di protocolli per
l’interfaccia Q3
ROSE
X.229/X.219
PRESENTATION LAYER
X.206/X.216
SESSION LAYER
X.225/X.215
TRANSP. LAYER
X.224/X.214
CLASSI 0,2
TRANSP. LAYER
X.224/X.214
CLASSE 4
16. Un utilizzatore dei servizi di gestione TMN vede una funzione MAF
(Management Application Function)?
17. Quale é il servizio più elementare visto da un utilizzatore di servizi di gestione
TMN?
18. Cosa è una architettura TMN stratificata? Cosa rappresentano gli strati logici?
Perchè sono chiamati logici? (Suggerimento: Pensare alle diverse aree di
responsabilità all’interno della struttura organizzativa del gestore).
19. Perchè la architettura TMN stratificata è anche “gerarchica”? Cosa significa
“gerarchica”? (Suggerimento: Pensare alla relazione Gestore-Agente fra strati
contigui).
20. Quali sono le limitazioni della TMN?
146
CAPITOLO 7
Gestione di INTERNET: Modello SNMP
(SIMPLE NETWORK MANAGEMENT
PROTOCOL)
7.1
Introduzione
7.1.1 Il modello SNMP
SNMP é un acronimo per Simple Network Management Protocol (in italiano :
Protocollo semplice per la gestione di rete). Quindi in senso stretto SNMP é un protocollo
gestionale cioé un insieme di regole per trasferire messaggi gestionali fra un sistema
gestore e un sistema gestito. Tuttavia SNMP sta ad indicare un qualcosa di molto più
generale che un semplice protocollo comunicativo. SNMP é un modello gestionale per
reti TLC che supportano la pila di protocolli internet (“reti internet” Vedi Tavola
7.1.1). Quindi parleremo di un «modello SNMP» o «standard SNMP» per la gestione di
reti internet il quale comprende la specifica di:
1) un protocollo di comunicazione (SNMP, Simple Network Management
Protocol),
2) la sintassi dell’informazione gestionale (SMI , Structure of Management
Information)
3) la struttura delle basi dati (MIB, Managenet Information Base) dove
sono immagazzinati gli oggetti gestiti rappresentazione astratta delle
risorse reali gestite.
In questo capitolo, oltre ad illustrare il modello gestionale SNMP per reti
internet, metteremo in evidenza le differenze fra questo modello e il modello TMN/OSISM precedentemente studiato.
Il modello SNMP venne alla luce agli inizi degli anni 70 quando, ad opera della
Internet Engineering Task Force (IETF), gruppo di lavoro della Internet Activities
Board (IAB), cominciarono i primi studi sulla possibilità di gestire in modo semplice le
reti internet. Ufficialmente il modello SNMPv1 (versione 1) fu annunciato nel 1988 e da
allora è divenuto lo standard “de facto” delle reti internet. Più recentemente la stessa
IETF ha sviluppato una nuova versione di modello gestionale chiamata SNMPv.2
(versione 2). La seconda versione é stata motivata principalmente dalla necessità di
eliminare gli inconvenienti presentati dalla versione 1 in materia di sicurezza. In questo
147
corso introduttivo sulla gestione dei sistemi TLC ci occuperemo principalmente della
versione 1 che chiameremo semplicemente SNMP.
SNMP é un modello gestionale per reti internet che ha goduto di una notevole
popolarità. Le ragioni di questa popolarità sono:
1)
Semplicità. Infatti SNMP è più semplice di OSI-SM sia a livello di
sottomodello comunicativo (cioè il protocollo SNMP è più semplice del
protocollo CMIP) che a livello di sottomodello informativo (e.g. la
struttura MIB/rappresentazione dati in SNMP è più semplice che in
OSI-SM).
2)
Estendibilità. Il numero di oggetti gestiti contenuti nelle basi dati dello
standard SNMP può essere facilmente aumentato. Ciò sarà spiegato
nel paragrafo 7.7.
3)
Indipendenza dalle tecnologie. Tra poco introdurremo il concetto di
“tipo di oggetto” SNMP. Esso è una rappresentazione astratta generica
valida per una molteplicità di apparati e linee di trasmissione. Oggi
SNMP gestisce quasi tutte le entità che appaiono ai vari livelli della pila
internet mostrata in Tav.8.1.1 (dallo strato di “accesso” allo strato di
“processo”) i.e. sia gli elementi di rete LAN/WAN (e.g. bridges,
routers, gateways, modems, multiplexers, servers etc.) sia le tecnologie
di rete ATM, SONET, Ethernet etc. Inoltre il protocollo SNMP
«viaggia» sui protocolli internet UDP/IP supportati da una varietà di
protocolli comunicativi a livelli più bassi (Vedi Tav. 7.1.1)
Queste caratteristiche fanno sì che i venditori di hardware internet possano facilmente
includere “Agenti SNMP” nei loro prodotti e, se necessario, aggiornare il tipo e numero
di funzioni di gestione che il prodotto può svolgere.
7.1.2 Le tre componenti standard del modello SNMP: SMI, MIB e SNMP
Tutti gli standards SNMP sono pubblicati su documenti RFC (Request for
Comments) dell’IETF come indicato nella Parte I. Tuttavia alcuni documenti sono più
importanti di altri. In particolare é importante riconoscere i documenti RFC con la sigla
aggiuntiva STD che specificano le parti del modello che sono standardizzate.
La IETF ha approvato tre standards individuati dalle sigle STD 15, 16 e 17. Piu’
precisamente:
1) STD 16/Structure of Management Information definisce la sintassi usata
per rappresentare i tipi di oggetti e i tipi di dato SNMP . (Vedi paragrafo 7.2)
2) STD 17/RFC 1213 definisce la struttura della MIB-2 (Management
Information Base-2) che è un repositorio di “tipi di oggetti” SNMP La MIB-2
148
é una versione riveduta e corretta della MIB-1 presentata in precedenza nel
documento RFC 1156. (Vedi paragrafo 7.2)
3) STD 15/RFC 1157 definisce il protocollo comunicativo SNMPv1. Il
protocollo SNMP definisce il formato dei messaggi gestionali trasferiti fra
Gestore (detto Network Management System, NMS, in gergo SNMP) e
Agente. (Vedi paragrafo 7.3)
OSI
APPLICATION
INTERNET
PROCESS
FTP, SMTP,
SNMP
HOST-TO-HOST
TCP,UDP
PRESENTATION
SESSION
TRANSPORT
NETWORK
INTERNET
DATA LINK
NETWORK ACCESS
IP
Token Ring,
Ethernet
PHYSICAL
Tav. 7.1.1
Notare che lo standard STD 15 é relativo al SNMPv.1. Per il modello SNMP versione
2 sono stati pubblicati una serie di documenti numerati da RFC 1901 a RFC 1907 ma
non standard.
149
7.2
Modello SNMP: struttura dell’informazione gestionale
(SMI, System Management Information)
7.2.1 Gli oggetti gestiti SNMP…..non sono oggetti in senso OSI-SM: paragone fra
oggetti gestiti SNMP e oggetti gestiti OSI-SM
•
Gli “oggetti gestiti” (managed objects) SNMP contenuti in una base dati
denominata “Agent MIB”
Come già avvenne nel modello TMN dell’ITU-T, anche nel modello SNMP
dell’IETF/IAB un Gestore gestisce, tramite un Agente, un insieme di dati chiamati
“oggetti gestiti” immagazzinati in una base dati chiamata Management Information Base,
MIB. Gli oggetti gestiti sono le rappresentazioni gestionali astratte delle risorse reali che
si vuole gestire. Più precisamente in Fig.7.1.1 la MIB è indicata come “Agent MIB” per
distinguerla da un repositorio (library) di tipi di oggetti gestiti chiamata MIB-2 o Internet
MIB, che è un sottoalbero dell’albero delle registrazioni. Quindi ciò che in precedenza
chiamammo “MIB” ora è denominata “Agent MIB”.
Gli oggetti gestiti sono le astrazioni gestionali di risorse reali (fisiche o logiche)
che esistono in una rete internet che si vuole gestire. Le “risorse fisiche e logiche” vanno
intese in maniera del tutto generale prendendo in considerazione non solo le
caratteristiche di funzionamento di un elemento di rete internet ma anche i servizi offerti
nei vari strati di una “pila internet”. Ad esempio nello standard SNMP sono oggetti gestiti
non solo il tempo di funzionamento di un apparato di rete misurato dal momento in cui
esso comincia ad essere gestito, l’indirizzo del sito di residenza della risorsa reale gestita,
il nome del proprietario di un sistema internet, ma anche le caratteristiche di
indirizzamento di una interfaccia o del flusso dei datagrammi attraverso un interfaccia di
un nodo di una rete internet etc. Ogni oggetto gestito contenuto in una Agent MIB
contiene il suo “valore” ed è individuato da un “Identificatore di Istanza” IID
(Instance Identifier). Possiamo dire che un oggetto gestito in una Agent MIB è l’istanza
di un “tipo di oggetto” cioè si ottiene da un tipo di oggetto assegnandogli un valore
specifico. Proprio come si faceva per istanziare un attributo di un oggetto OSI-SM
assegnando un valore al nome dell’attributo (Attribute Value Assignment).
Riassumendo possiamo dire che dal punto di vista del Gestore un oggetto gestito
SNMP immagazzinato in una Agent MIB è caratterizzato da due elementi importanti: un
“identificatore di istanza”, chiamato IID (Istance IDentifier) che permette ad un
messaggio gestionale di individuarlo in una Agent MIB e un valore caratteristico della
particolare risorsa gestita che può essere letto (get) o modificato (set) dal Gestore
(attraverso l’Agente). La ragione per la quale l’identificatore di un oggetto gestito è
chiamato “identificatore di istanza” è dovuta al fatto che un oggetto gestito è in effetti
una istanza di un “tipo di oggetto” generico rappresentazione gestionale astratta
standardizzata di risorse reali contenuta in una libreria chiamata MIB-2 .
150
•
I “tipi di oggetto” (object types) SNMP contenuti nello standard MIB-2.
I tipi di oggetto istanziati in una Agent MIB sono scelti dall’Agente da una
libreria standardizzata di “tipi di oggetti”, chiamata MIB-2, indicata come “Internet MIB”
in Fig.7.1.1. Una MIB-2 ha una struttura gerarchica ad albero, sottoalbero di un albero
più grande chiamato “albero delle registrazioni” o, purtroppo!!, “albero OID” (Object
Identifier) come definito dal gruppo di lavoro IETF/IAB nel documento RFC 1213.
Diciamo “purtroppo” perché nell’albero MIB-2 esistono “tipi di oggetti” e non “oggetti”
e ogni tipo di oggetto è identificato da una sequenza di numeri interi positivi separati da
punti, denominato OID ovvero Object Identifier, Identificatore di Oggetto! Sarebbe
stato molto meglio chiamarlo OTID, Object Type Identifier, cioè Identificatore di Tipo
di Oggetto!
Quindi, un “oggetto gestito” contenuto nella base dati Agent MIB è una istanza
di un “tipo di oggetto” contenuto nella libreria MIB-2 o libreria Internet MIB. Proprio
per distinguere fra una base dati MIB e un sottoalbero standardizzato MIB-2, in Fig.7.1.1
abbiamo rispettivamente usato i termini “Agent MIB” e “Internet MIB”.
IETF/IAB Standard
Internet MIB
(MIB-2)
Managed
Real
Resource
OBJECT TYPE
VALUE
INSTANCE
Agent MIB
MANAGED OBJECT
Fig.7.1.1 Differenza fra “oggetti gestiti” in una base dati “Agent MIB”
e “Tipi di Oggetto” in una libreria MIB-2 (anche chiamata “Internet MIB”)
sottoalbero dell’albero delle registrazioni.
Vedremo anche che i “tipi di oggetti” standardizzati rilevanti alla gestione delle
reti internet sono rappresentati dai nodi più bassi (“foglie”) del sottoalbero MIB-2
mentre i nodi interni (“rami”) del sottoalbero hanno un semplice valore strutturale e non
contengono informazione gestionale.
151
•
La differenza fra oggetti gestiti SNMP e oggetti gestiti OSI-SM
Gli oggetti gestiti SNMP sono diversi dagli oggetti gestiti OSI-SM essenzialmente
perché sono diverse le entità da cui essi vengono istanziati cioè rispettivamente i “tipi
di oggetto” nella MIB-2 e le “classi di oggetti” in OSI-SM rappresentate con il linguaggio
GDMO/ASN.1 e relazionate da un albero di ereditarietà. Più precisamente gli oggetti
gestiti SNMP sono più semplici degli oggetti OSI perché non sono definiti nell’ambito di
un ”orientamento agli oggetti” cioè non sono istanze di classi di oggetti caratterizzate
dalle quattro caratteristiche “behaviour”, “attributes”, “notifications”, “operations”,
classi relazionate da proprietà di ereditarietà. Essi sono invece istanze di “tipi di oggetti”
molto più semplici che sono mutuamente relazionati non perché “ereditano” proprietà gli
uni negli altri ma solo per il fatto che fanno tutti parte di una architettura convenzionale
ad albero (albero di registrazione) definita dall’ ente di standardizzazione IETF/IAB.
Un “tipo di oggetto” SNMP contenuto nella MIB-2 può essere paragonato ad un
attributo di una classe di oggetti OSI che viene di volta in volta, a seconda delle necessità
di un Agente, istanziato associandogli un valore specifico, tramite una operazione SVA
(Specifica del Valore di Attributo). Altrimenti si può anche dire che un “tipo d’ oggetto”
SNMP equivale concettualmente ad una “variabile” in un programma di elaborazione
numerica a cui viene poi associato un «valore» specifico. Per questo, un tipo d’ oggetto
SNMP viene anche chiamato «variabile» (“variable” in inglese). Ad esempio quando si
parla del tipo d’oggetto “sysLocation” contenuto nel sottoalbero MIB-2, rappresentazione
astratta dell’ ubicazione di un certo sistema fisico da gestire (e.g. nodo di una rete
internet), in effetti si parla di una variabile da istanziarsi con la assegnazione di un valore
specifico.
Il modello SNMP definisce anche una sintassi denominata “ASN.1 ridotta” ,
sottoinsieme della sintassi ASN.1 precedentemente definita nel modello OSI-SM. Essa
permette di effettuare una rappresentazione formale di un certo “tipo di oggetto”
contenuto nella MIB-2 tramite la specializzazione di un macro generico (OBJECTTYPE macro) definito in generale per tutti i tipi d’oggetto. La Tavola 7.1.2 mostra
proprio un esempio di specializzazione di un macro generico al tipo di oggetto
“sysUpTime”, rappresentazione astratta del tempo di funzionamento di una
apparecchiature in una rete internet..
In SNMP, poiché manca l’orientamento agli oggetti, mancano anche l’albero di
ereditarietà per definire le relazioni fra classi di oggetti e l’albero di contenimento per
definire un nome globalmente univoco per ogni oggetto gestito (Distinguished Name).
L’unico albero che rimane e’ quello delle registrazioni. Infatti in SNMP e’ un “albero
delle registrazioni” che viene usato per classificare i tipi di oggetto che verranno
istanziati negli oggetti gestiti immagazzinati in una Agent MIB. Tuttavia l’albero
delle registrazioni identifica ogni tipo di oggetto con un indicatore OID mentre un
oggetto gestito nella Agent MIB è identificato da un identificatore IID. Quale è la
relazioni fra OID e IID? Tra poco lo sapremo.
Infine, in omaggio allo spirito di semplicità che ha ispirato la formulazione della
gestione SNMP, il gestore SNMP può solo leggere o modificare il «valore» dell’istanza
di un oggetto gestito tramite invio all’Agente di due tipi di messaggi : GET-REQUEST
152
e SET-REQUEST. Altri tipi di messaggi gestionali sono variazioni di questi due tipi di
messaggi fondamentali.
7.2.2 Le caratteristiche di un “tipo di oggetto” SNMP: nome, OID, sintassi,
accesso, stato e descrizione
I concetti sinora esposti sono contenuti e specificati nel modello informativo o
meglio in quella che viene chiamata «la struttura dell’informazione gestionale »
(Structure of Management Information, SMI). Il contenuto delle principali specifiche
SMI é mostrato in Fig. 8.1.2. Un “tipo di oggetto” SNMP (qui chiamato semplicemente
“oggetto” come purtroppo è comunemente fatto nella letteratura esistente) é caratterizzato
da:
1)
«nome», che rappresenta in modo simbolico l’oggetto. Il suo format
standardizzato di rappresentazione grafica (chiamato « tipo » o « tipo di
dato », data type in inglese) è una sequenza di lettere dell’alfabeto con
la prima lettera minuscola (vedi il tipo «printable string» nella sintassi
ASN.1). Ad esempio, « sysUpTime ». è il nome che descrive in modo
simbolico l’oggetto gestito rappresentativo del tempo di funzionamento
della porzione gestionale di un elemento di rete, misurato dall’Agente a
cominciare dall’istante della sua ultima inizializzazione.
2)
«identificatore d’oggetto» (Object Identifier, OID) derivato
dall’albero delle registrazioni (Vedi dopo), che identifica la posizione
dell’oggetto nella MIB ed il cui format standardizzato di
rappresentazione grafica ( cioe’ il « tipo ») è una sequenza di numeri
interi intervallati da punti (vedi il tipo OBJECT IDENTIFIER nella
sintassi ASN.1). Ad esempio l’OID dell’oggetto systemUpTime e’
1.3.6.1.2.1.1.3.
3)
«sintassi» che specifica il tipo di dato usato per rappresentare il valore
associato all’istanza dell’oggetto. Il tipo è scelto fra i tipi definiti nella
sintassi ASN.1 (cioè può essere INTEGER, IpAddress, Counter, Gauge,
TimeTick etc.). Ad esempio il tipo di dato relativo al valore specifico di
una istanza dell’oggetto sysUpTime è «TimeTick » definito come una
sequenza di numeri interi rappresentativa dei centesimi di secondo
trascorsi dall’inizializzazione dell’apparato. Ad esempio il valore di un
ora, specifico di una istanza dell’oggetto gestito sysUpTime, è 360000.
4)
«accesso» ad una istanza di un oggetto gestito (Vedi 8.5). Specifica lo
scopo per cui un messaggio gestionale accede ad una istanza di un
oggetto gestito. (Vedi dettagli a fine paragrafo). Ad esempio l’accesso
ad una istanza dell’oggetto sysUpTime e’ «read-only» cioe’ il
messaggio legge il valore dell’istanza.
5)
«stato» dell’oggetto (Vedi 7.4). Indica se uno sviluppatore di software
SNMP deve implementere o meno un particolare oggetto. (Vedi dettagli
a fine paragrafo). Ad esempio lo stato di un oggetto sysUpTime è
153
«mandatory» cioè l’oggetto deve essere obbligatoriamente incluso in
una MIB perchè essa possa considerarsi a norma SNMP.
6)
breve «descrizione» dell’ oggetto in lingua piana che descrive la
semantica dell’oggetto. Ad esempio la descrizione di un oggetto
sysUpTime e’ « Il tempo trascorso da quando la porzione gestionale di
un elemento di rete e’ stata inizializzata per l’ultima volta » (Vedi
prossimo paragrafo)
7.2.3 La rappresentazione grafica di un “tipo di oggetto” SNMP: il macro
OBJECT-TYPE
Tutte queste caratteristiche di un “tipo di oggetto” SNMP descritte sinora in
maniera informale devono essere rappresentate con una struttura grafica formale per
poter essere lette/scritte da elaboratori numerici. Questo si fa usando “macro”. Nel caso
di un “tipo di oggetto” SNMP il macro è denominato «OBJECT-TYPE macro».
Quindi, la rappresentazione formale di un “tipo di oggetto” SNMP generico viene
effettuata con un “OBJECT-TYPE macro” come indicato nella sintassi ASN.1. Un
OBJECT-TYPE macro, definito in modo del tutto generico, viene di volta in volta
istanziato per un “tipo d’oggetto” specifico. Un macro relativo ad un tipo di oggetto
specifico si chiama una “istanza del OBJECT TYPE macro” generico. Ad esempio una
istanza di OBJECT-TYPE macro per il tipo d’ oggetto specifico “sysUpTime”
menzionato precedentemente, è mostrata qui di seguito.
sysUpTime OBJECT-TYPE
SYNTAX TimeTick
ACCESS read-only
STATUS mandatory
DESCRIPTION
« The time since the management portion of the system was last reinitialized »
: : = {system 3}
Tavola 7.1.2. Rappresentazione di una istanza di OBJECT TYPE macro relativa al Tipo
d’oggetto sysUpTime.
dove l’identificatore è stato rappresentato nella forma contratta «system.3» invece della
forma estesa 1.3.6.1.2.1.1.3. (Vedi Fig.7.7.1 dove “system” corrisponde alla sequenza
1.3.6.1.2.1.1.). A questa “istanza di OBJECT-TYPE macro” può poi essere assegnato un
valore specifico cioè in effetti può essere ulteriormente istanziata per rappresentare un
oggetto gestito da immagazzinare nella Agent MIB relativa ad un sistema specifico da
gestire. Ad esempio al tipo d’oggetto sysUpTime si può associare il valore specifico
182580204 corrispondente ad un tempo di funzionamento di 20 giorni, 2 ore, 30 minuti, 2
secondi e 4 centesimi di secondo (espresso secondo l’elemento di sintassi “TimeTick”
come indicato in Tav.8.1.2)
154
7.2.4 Come si ottiene la sequenza di numeri dell’OID?
Per semplicità chiamiamo un tipo di oggetto nell’albero OID o albero delle
registrazioni semplicemente “oggetto”.L’ OID di un oggetto SNMP e’ definito tramite
un albero di registrazione, chiamato anche « Albero OID », simile a quello definito per il
modello OSI. In questo albero (con la radice in alto e i rami protesi versi il basso) ogni
oggetto e’ specificato con il suo nome simbolico piu’ un numero intero positivo. Alcuni
oggetti sono “nodi” dell’albero e da essi si diramano “sottoalberi”. La sequenza numerica
rappresentativa dell’OID di un oggetto si ottiene come già fatto per l’albero delle
registrazioni OSI. Si percorre l’albero dalla radice verso il basso fino all’oggetto
desiderato e si raccolgono in sequenza ordinata i numeri degli oggetti incontrati
progressivamente durante il percorso. Descriveremo questo processo in maggiore
dettaglio fra poco.
Per il momento é importante riconoscere e ricordare che,
7.3
1)
nel modello SNMP mancano i due alberi tipici del modello OSI (i.e.
eredità e contenimento) ed esiste il solo albero delle registrazioni
(albero OID),
2)
l’albero OID rappresenta lo schema secondo il quale sono
“organizzati” gli oggetti SNMP nella MIB e
3)
l’albero OID é un albero di registrazione che serve a definire il
valore globalmente univoco dell’indicatore d’oggetto OID.
La sintassi ASN.1-ridotta (Fig.7.1.2)
Lo standard SMI specifica la sintassi astratta adottata dal modello SNMP per
rappresentare gli oggetti gestiti e I valori delle loro istanze. Questa sintassi si chiama
“ASN.1-ridotta” per indicare il fatto che SNMP usa una versione ridotta della sintassi
ASN.1 adottata in OSI. Inoltre lo standard SMI specifica il protocollo di codifica (BER)
per trasformare il linguaggio astratto ASN.1 in un linguaggio di ottetti di zeri e uno
riconoscibili da elaboratori digitali e trasferibili fra Gestori e Agenti. É lo stesso concetto
usato per il modello OSI. La differenza é che nel modello SNMP vengono usati solo
alcuni tipi di dato contenuti in ASN.1 e la trasformazione protocollo astratto-protocollo di
trasferimento avviene all’interno dello strato internet di processo e non nei due strati
separati della pila OSI i.e. strato applicativo e strato di presentazione. I tipi di dato ASN.1
usati dal modello SNMP sono mostrati in Fig. 7.1.2. Sono un totale di 13 tipi divisi in tre
categorie. “Universal” sono tipi di dato validi in generale indipendentemente dalla
particolare applicazione, “Application-wide” sono tipi di dato dipendenti dalla
particolare applicazione che in questo caso è lo SNMP, “Constructor” servono per
creare tipi di dato aggregazioni (sequenze) di tipi di dato semplici.
Nella tabella dei tipi di dato adottati dalla sintassi ASN.1-ridotta,
NetworkAddress identifica un indirizzo in rete secondo il protocollo di trasmissione
adottato ma, per il momento, c’e solo il protocollo IP quindi questo tipo di dato si riduce
all’IpAddress cioe’ all’indirizzo in rete internet.
155
Il termine « opaque » e’ un « place holder » cioe’ un termine generico che serve
a « tenere il posto » per data types futuri. Un « Counter » e’ un numero intero che può
solo crescere fino al massimo di (2 exp 32 – 1) = 4.294.967.295 e poi ricomincia da zero
(Esempio: il data type adatto a rappresentare il numero di pacchetti in arrivo su un
interfaccia di un nodo di rete). Un “Gauge” é un intero che può crescere o decrescere ma
raggiunto lo stesso valore massimo del counter resta fissato a quel valore (in inglese :
latches at a maximum). Esempio: Numero di interfacce attive in un nodo ad un certo
istante.
I tipi di dato (“costruttori”, “constructors” in inglese) SEQUENCE e
SEQUENCE OF sono usati entrambi nella costruzione di tavole di dati bidimensionali.
Individualmente si usano come segue: SEQUENCE è usato per rappresentare liste
ordinate di valori relativi a tipi di dato diversi, mentre SEQUENCE OF per liste di
valori con lo stesso tipo di dato.
7.4
Lo «stato» di un oggetto SNMP
In Fig. 7.1.2 lo stato di un oggetto (status) indica se uno sviluppatore di
software SNMP deve implementere o meno un particolare oggetto (per poter dichiarare
che il software e’ a norma SNMP).
1. Lo stato «mandatory» indica che l’oggetto in questione deve obbligatoriamente
essere implementato dallo sviluppatore del software se vuole che il software stesso sia
a norma SNMP. Notare che tutti gli oggetti della MIB-2, proprio perchè, nello spirito
del modello SNMP, rappresentano il minimo indispensabile necessario per gestire una
rete internet sono oggetti «mandatory».
2. Invece lo stato «optional» indica che un particolare oggetto contenuto nell’albero
delle registrazioni (esclusi gli oggetti nella MIB-2) può’ anche non essere presente in
un software a norma SNMP, e la decisione sulla sua presenza o assenza e’ a carico
dello stesso sviluppatore.
3. Lo stato «obsolete» indica che quel particolare oggetto era necessario in vecchie
versioni del modello SNMP ma ora non e’ più necessario.
4. Lo stato «deprecated» significa che un oggetto ora deve essere implementato ma che
non sarà piu’ necessario implementarlo in future versioni del modello SNMP.
7.5
L’ «accesso» a un oggetto SNMP
Nella stessa figura 7.1.2 l’ «accesso» ad una istanza di un oggetto (access)
specifica lo scopo per il quale un messaggio gestionale può accedere all’ oggetto.
Ad esempio, un accesso «read-only» ad un oggetto significa che un messaggio
puo’ solo leggere il valore di una sua istanza. Analogamente l’accesso «write-only» ad
156
un oggetto significa che un messaggio gestionale puo’ solo scrivere o rimpiazzare il
valore di una sua istanza .
Structure of Management Information
1. NOME/POSIZIONE: descrittore/OID
2. SINTASSI: ASN.1 (Ridotta)
3. CODIFICA: BER
4. STATO: mandatory, optional, obsolete, deprecated
5. ACCESSO: read-only, read-write, write-only, not-accessible
ASN.1 (Ridotta)
Universal
INTEGER
OCTET STRING
OBJECT IDENTIFIER
NULL
Application-wide
IpAddress
NetworkAddress
Counter
Gauge
TimeTicks
Opaque
Constructor
SEQUENCE
SEQUENCE OF
Fig.7.1.2 La SMI definisce il linguaggio da usare per rappresentare gli oggetti gestiti
L’accesso «not-accessible» significa che quel particolare oggetto di per sè non è
accessibile per scrivere o leggere il valore della sua istanza. Ciò accade quando si
incontra un oggetto aggregato o oggetto tavola (descritto fra poco) cioè un oggetto la
cui istanza è costituita da una molteplicità di valori (tavola bidimensionale di valori). In
SNMPv.1 questa molteplicità di valori non può essere letta/scritta in blocco da un Agente
tramite un unico identificatore ma in essa ogni valore deve essere letto o scritto
individualmente specificandone l’ Identificatore di Istanza (IID). Quindi il termine «notaccessible» si applica ad un oggetto tavola e sta ad indicare il fatto che per gestire questo
oggetto si devono accedere i valori delle sue istanze individualmente . Ad esempio
l’istanza di un oggetto tavola 3x3 è un insieme di nove valori che devono essere
letti/scritti uno per uno. Fra poco definiremo oggetti «tavola» come aggregazione di
oggetti “riga” e oggetti “colonna”. Di che cosa si tratta? Lo vediamo qui di seguito.
157
7.6
Gli oggetti SNMP: oggetti “scalari”e oggetti “tavola”
7.6.1 Oggetti “scalari” (istanza mono-valore) e oggetti “tavola” (istanza plurivalore)
Continuiamo a mantenere la convenzione per cui un “tipo d’oggetto” SNMP
rappresentato da un nodo dell’albero OID (o meglio, del sottoalbero MIB-2) viene
chiamato semplicemrente “oggetto”. Finora abbiamo parlato di oggetti scalari che sono
caratterizzati dal fatto che una loro istanza è specificata da un solo valore (oggetto con
istanza mono-valore). La Fig.7.6.1 A mostra un oggetto scalare con nome simbolico
ipAddress rappresentativo dell’indirizzo internet di un computer collegato ad una rete
internet (host computer). L’OID dell’oggetto (in forma sintetica) ricavato dalla MIB-2 è
“ip.1”. L’identificatore d’istanza IID che identifica il corrispondente oggetto gestito
immagazzinato in una Agent MIB è per convenzione
IID = OID.0
Quindi nella fattispecie IID = ip.1.0. La Fig. 7.6.1B mostra un esempio di come l’
oggetto scalare di Fig.7.6.1A possa essere generalizzato. All’uopo consideriamo, invece
di un nodo di rete con un unica interfaccia, un nodo di rete internet con tre interfacce. La
gestione dei corrispondenti indirizzi internet e.g. “leggi il valore dell’indirizzo di una
interfaccia” o “modifica il valore dell’indirizzo di una interfaccia”, può effettuarsi
rappresentando il nodo come un oggetto la cui istanziazione avviene assegnandogli non
un solo valore ma una sequenza ordinata di tre valori con lo stesso data type. In figura i
tre valori sono 123.45.6.7, 123.45.6.8, 123,45.6.9 che sono diversi ma hanno la stessa
struttura grafica. Un oggetto di questo tipo si chiama “oggetto colonna”. Il nome deriva
dal fatto che una sequenza di valori di questo tipo può anche interpretarsi come una
colonna in una tavola di dati. Fra poco vedremo come.
Quindi un oggetto colonna è un oggetto la cui istanza è una “SEQUENCE OF” di
valori cioè di istanze di oggetti scalari
Alternativamente questa frase potrebbe riformularsi come segue: “Un oggetto
colonna è un oggetto la cui istanza si ottiene tramite assegnazione di una sequenza
ordinata di valori con lo stesso tipo di dato”.
Nell’istanza di un oggetto colonna deve esistere un IID per ciascun valore in
modo che il Gestore, tramite l’Agente, possa accedere ad esso. Per il momento diciamo
che i tre IID sono relazionati allo stesso OID tramite un indice “i” opportunamente scelto,
quindi
IIDi = OID.i (i = 1,2,3)
dove “i” rappresenta l’i-esimo elemento della sequenza o la i-esima riga nella
“colonna”di dati che istanzia un oggetto “colonna.
La Fig.7.6.2 generalizza ulteriormente la situazione di Fig.7.6.1B. Qui ogni
interfaccia del nodo in una rete internet è caratterizzata non da una ma da cinque
caratteristiche. In generale le cinque caratteristiche sono di natura diversa, e.g. indirizzo,
tempo trascorso dalla inizializzazione, numero di pacchetti in entrata etc. e
conseguentemente sono istanziate da valori scritti con diversi tipi di dato. A ogni
158
caratteristica facciamo corrispondere un oggetto scalare con istanza monovalore. Quindi
per ogni interfaccia esiste un insieme ordinato dei cinque oggetti scalari le cui istanze
hanno valori con diversi tipi di dato. Chiamiamo questo insieme un oggetto riga o
oggetto entry la cui istanza è una SEQUENCE di cinque valori cioè una sequenza di
cinque valori con diverso tipo di dato.
Finora abbiamo rappresentato una interfaccia. Ma osserviamo che il nodo ha tre
interfacce. Allora il nodo si rappresenta sostituendo all’interno di una riga ogni oggetto
scalare con un oggetto colonna a tre valori (uno per interfaccia).
Un oggetto la cui istanza è una SEQUENCE OF di istanze di oggetti riga si chiama
“oggetto tavola”.
Oppure una “istanza di oggetto tavola = SEQUENCE OF di istanze di oggetti riga
laddove una istanza di oggetto riga = SEQUENCE di istanze di oggetti scalari (Vedi
Fig.7.6.4) .
albero delle registrazioni (Vedi Fig. 7.6.5). un oggetto tavola definito nella MIB2 e gli IID relativi ai valori contenuti nella tavola istanza dell’oggetto stesso.
A.OGGETTO SCALARE
Host
Computer con
una interfaccia
Nome simbolico:
ipAddress,
OID = ip.1
Sintassi = IpAddress
Valore = 123.45.6.7
Rappresentazione astratta dell’
indirizzo internet dell’interfaccia
di un host computer
( 1 istanza, 1 valore )
B.OGGETTO “COLONNA”
Nodo con 3
interfacce
Rappresentazione astratta dei tre
indirizzi internet delle tre interfacce
di un nodo in una rete internet
( 1 istanza, 3 valori )
Nome simbolico: ipAddress,
OID = ip.1
Sintassi = SEQUENCE OF ipAddress
Valori = 123.45.6.7
123.45.6.8
123.45.6.9
Fig. 7.6.1 Esempi di oggetti scalari con istanza mono-valore e oggetti colonna con istanza
pluri-valore. Gli identificatori e i valori in figura sono scelti arbitrariamente.
159
Nella MIB-2 dello standard SNMPv.1 il numero delle colonne è standardizzato
mentre il numero delle righe è definibile a piacimento. Ad esempio in Fig. 7.6.3 ogni riga
si riferisce ad una singola interfaccia, ogni colonna si riferisce ad una caratteristica. Lo
standard MIB-2 definisce le cinque caratteristiche di interfaccia mostrate in figura mentre
il numero delle interfacce (3) dipende dalla struttura fisica del nodo preso in
considerazione. Un nodo con dieci interfacce avrebbe una tavola con dieci righe (ma
sempre con cinque colonne!). Un oggetto tavola ha un identificatore d’oggetto OID
definito nell’ albero delle registrazioni (Vedi Fig. 7.6.5). Quando l’oggetto tavola viene
istanziato ogni valore nella tavola è identificato da un identificatore IID. Vediamo ora la
relazione che intercorre fra l’OID di un oggetto tavola definito nella MIB-2 e gli IID
relativi ai valori contenuti nella tavola istanza dell’oggetto stesso.
1
1.
2.
3.
4.
5.
2
Nodo di rete
internet con 3
facce
OGGETTO RIGA
3
IpAddrEntry
Indirizzo faccia
Indice faccia
Ind. sottorete
Broadcasting
Max.Datagr
.
Oggetto “riga” composto
da 5 oggetti colonna con
tipi di dato diversi . Ogni
’
oggetto colonna puo
assumere 3 valori
ipAdEnt BcastAddr
NOME 1
2
ipAdEnt Addr
ipAdEnt Index
OGGETTO 1
Indirizzo
.
3
ipAdEnt Mask
OGGETTO 2
Indice
OGGETTO 3
Sottorete
Fig . 7.6.2
160
4
5
ipAdEnt ReasmMaxSize
OGGETTO 4
Bcstg
OGGETTO 5
Datagram.
La Fig. 7.6.2 mostra un esempio in cui un “oggetto riga” (o “oggetto entry”)
ipAddrEntry fornisce cinque caratteristiche rilevanti all’indirizzamento di datagrammi
a/da una certa interfaccia di un nodo di una rete internet. Per ogni interfaccia e per ogni
caratteristica esiste un oggetto scalare standardizzato nella libreria MIB-2. Poiché ci
sono tre interfacce con le stesse caratteristiche possiamo sostituire il singolo oggetto
scalare con un oggetto colonna con istanza tri-valore. Quindi l”oggetto riga” è costituito
da una sequenza di cinque oggetti colonna con diversi tipi di dato presi dal gruppo MIB-2
“system”. Lo standard MIB-2 specifica (RFC 1213) le cinque caratteristiche per
interfaccia come segue.
1) Indirizzo IP (ipAdEntAddr). Indirizzo IP a cui l’informazione contenuta in
questa riga si riferisce.
2) Indice (ipAdEntIndex). Indice che identifica in modo univoco l’interfaccia a cui
questa riga si riferisce.
3) Caratteristica di “Sottorete” (ipAdEntNetMask). “Maschera di subnet” che
individua la posizione dell’indirizzo di subnet all’interno dell’indirizzo IP di questa riga.
La maschera ha 32 bits di cui una serie di uno corrisponde alle posizioni dei bits relativi
all’indirizzo di subnet all’interno dell’indirizzo IP mentre tutti gli altri bits sono zeri..
Ricordiamo che un indirizzo IP contiene bits rappresentativi degli indirizzi di network,
subnet e host. La sintassi è IpAddress.
ipAdEntAddr
ipAdEntIndex ipAdEntNetMask
ipAdEntBcastAddr
ipAdEntReasmMaxSize
TAVOLA = ISTANZA di OGGETTO TAVOLA
Internet
“ 123.45.2.1”
1
Internet
“123.45.2.2”
2
Internet
“123.45.2.3”
3
Internet
255.255.255.0
Internet
255.255.255.1
Internet
255.255.255.2
Fig. 7.6.3
161
0
12000
0
12000
0
12000
4)
Caratteristica di “Broadcasting” (ipAdEntBcastAddress) Valore del Last
Significant Bit nell indirizzo broadcast (IP broadcast address) usato per inviare
datagrammi sull’interfaccia (logica) associata con l’indirizzo IP di questa riga. Ad
esempio se si usa l’indirizzo broadcast standard costituito da tutti uno, il valore è 1. La
sintassi è INTEGER
5)
Caratteristica di “Riassemblamento Datagrammi” (ipAdEntReasmMaxSize)
Dimensione del datagramma più lungo che l’elemento di rete può riassemblare dai
frammenti di datagrammi in arrivo sull’interfaccia relativa a questa riga. La sintassi è
INTEGER (0….65535). Ricordiamo 65535 è il piu’ grande numero decimale
rappresentabile con 12 bits, infatti 2 exp 12 = 65536
Rappresentazione
ad albero di un
oggetto
TAVOLA
x
Oggetto Tavola
(SEQUENCE OF)
x.1
Oggetto Riga
(SEQUENCE)
Oggetti
Colonna
I
s
t
a
n
z
e
i=
OID=x.1.1
1 IID = x.1.1.1
x.1.2
x.1.3
x.1.2.1
x.1.3.1
2
x.1.1.2
x.1.2.2
x.1.3.2
3
x.1.1.3
x.1.2.3
x.1.3.3
TAVOLA
Fig. 7.6.4 Relazione fra rappresentazione ad albero di un oggetto tavola e
una tavola di valori.
162
Alla luce di quanto detto sinora si può capire perché un oggetto riga la sia rappresentato
con il seguente macro:
ipAddrEntry : : = SEQUENCE ( ipAdEntAddr
IpAddress
ipAdEntIfIndex
INTEGER
ipAdEntNetMask
IpAddress
ipAdEntBcastAddr
INTEGER
ipAdEntReasmMaxSize INTEGER )
Un oggetto riga istanziato tre volte ovvero sostituendo in un oggetto riga gli oggetti
scalari con oggetti colonna e istanziandoli da luogo all’ istanza di un oggetto tavola.
Infatti quest’ultima è una SEQUENCE OF di valori istanze di oggetti riga. Ad esempio
l’istanza dell’ oggetto tavola ipAddrTable è una lista di valori dello stesso tipo i.e.
SEQUENCE OF relativi alle istanze di ipAddrEntry.
Come precedentemente indicato quando si è parlato dell’accesso agli oggetti, gli
oggetti aggregati non sono accessibili in blocco cioè i valori di una loro istanza non
possono essere letti/scritti in blocco con un unico identificatore ma devono essere
letti/scritti uno per uno con i relativi IID.
7.6.2 Riepilogo di tutti gli oggetti SNMP che esistono in una MIB
Sinora abbiamo parlato di quattro tipi di oggetti: oggetti scalari, colonna, riga e
tavola. Come vengono utilizzati questi oggetti in una struttura ad albero come la MIB? La
Fig. 7.6.5 mostra un esempio che risponde a questa domanda. Questo tipo di
rappresentazione e’ standard e si trova in tutti i libri che trattano la gestione SNMP.
Notare la rappresentazione di un oggetto tavola come aggregato ripetitivo di un oggetto
riga (le cui istanze rappresentano le righe di una tavola ma non sono accessibili in blocco)
il quale a sua volta è un aggregato di oggetti colonna con sintassi diversa. Quindi la
struttura ad albero di un oggetto tavola, dall’alto verso il basso, è oggetto tavola, oggetto
riga, oggetti colonna. La Fig.7.6.4 rappresenta la relazione fra l’albero di un oggetto
tavola e una tavola di valori. La figura mostra anche l’istanza successiva in ordine
lessicografico (Vedi appendice) ad un oggetto o a un istanza. Di questo ci occuperemo fra
poco, quando parleremo dei messaggi SNMP.
163
Esempio di oggetto TAVOLA contenuto in una MIB-2
Il gruppo MIB-2 “tcp” contiene 14 oggetti scalari e 1 oggetto tavola
(6)
OGGETTI SCALARI
1
15
2
3
4
5
6
7
“tcp” e’ il sesto gruppo in
MIB-2 (OID = MIB-2.6)
8
9
10
11
12
13
14
15
(SEQUENCE OF)
Oggetto tavola:
dati relativi alle
connessioni tcp
Oggetto entry:
dati relativi a una
connessione in
corso
OGGETTO TAVOLA
(tcpConnTable, MIB-2.6.13)
(SEQUENCE)
OGGETTO RIGA
(tcpConnEntry,MIB-2.6.13.1)
OGGETTI COLONNA
(MIB-2.6.13.1.i con i=1,2,3,4)
Oggetto colonna
con ruolo di indice
Fig.7.6.5 La struttura ad albero degli oggetti in una MIB-2. Solo gli oggetti foglia sono accessibili cioe’ i loro valori possono
essere letti o scritti
164
7.7
L’ “albero OID” e il sottoalbero MIB-2
7.7.1 L’ “albero OID” per trovare gli identificatori OID degli oggetti gestiti.
Come già detto in 7.2.2 e 7.2.3, ricordiamo che un “oggetto SNMP” in effetti è un
“tipo d’oggetto SNMP (OBJECT-TYPE)” caratterizzato da 1) “nome simbolico” che
inizia con una lettera minuscola e.g. sysLocation, relativo all’ubicazione di una
apparecchiatura, 2) OBJECT IDENTIFIER (OID) cioé un “identificatore d’oggetto”,
espresso come una sequenza di numeri interi separati da punti, 3) “sintassi” (SYNTAX)
che specifica il tipo di dato da usare nella scrittura del valore dell’oggetto allorchè
l’oggetto viene istanziato, 4) “accesso” (ACCESS) che specifica lo scopo per cui un
messaggio può accedere all’istanza di un oggetto e.g. leggi, scrivi, leggi/scrivi etc. , 5)
“stato” (STATUS) che specifica la necessità o la opzionalità di includere l’oggetto in
una Agent MIB a norma SNMP (importante per un progettista) e, infine, 6)
“descrizione” dell’oggetto gestito in lingua piana. La istanziabilità di un oggetto gestito
SNMP o, più precisamente, il fatto che esso sia in effetti “un tipo d’oggetto” che acquista
un valore specifico solo al momento della sua istanzazione, fa sì che esso sia molto simile
ad un attributo di una classe OSI-SM che viene istanziato tramite un processo SVA
(Specifica Valore Attributo) o ad una “varibile”, come usata in un programma, che di
volta in volta assume un certo “valore”.
Nella gestione SNMP un identificatore d’oggetto (OID) è definito sulla base di un
“albero di registrazione”, per questo motivo anche chiamato albero OID. L’albero OID
è mostrato in Fig. 8.7.1. Si tratta di un albero di registrazione creato con la stessa filosofia
adottata per l’albero di registrazione usato nel modello informativo OSI-SM (vedi par.
4.12). Ricordiamo che in OSI-SM l’albero di registrazione era usato per definire la
sequenza alfanumerica di registrazione (identificatore) situata al fondo di ogni maschera
GDMO, dopo la parola chiave REGISTERED AS.
Come già per il modello OSI-SM, anche nell’albero OID é possibile definire una
sequenza di numeri interi che identifica un oggetto SNMP, percorrendo l’albero di
registrazione dalla radice verso il basso fino a raggiungere la foglia dell’albero desiderata
cioè l’ oggetto gestito desiderato. Notare che solo i nodi infimi dell’albero (le foglie)
rappresentano oggetti gestiti istanziabili mentre gli altri nodi hanno semplicemente un
carattere strutturale e sono non-istanziabili.
La Fig.7.7.1 rappresenta la parte dell’albero OID rilevante alle reti internet.
Quindi tutti gli OID degli oggetti internet hanno il prefisso 1.3.6.1. corrispondenti alla
sequenza di nodi ISO (1), Identified Organization (3), DoD (6) e internet (1).
Per il sottoalbero di internet (1) si può dire quanto segue.
Il nodo directory (1) é riservato per una possibile utilizzazione di servizi del tipo
Directory (tipo OSI Directory ma valido per un sistema internet). Questo nodo non ci
interessa in questo corso.
Il nodo management (2) é di massimo interesse per noi. Infatti, al di sotto di
questo nodo si trovano tutti gli oggetti gestiti SNMP standardizzati necessari per
gestire una rete internet. Si tratta di oggetti gestiti approvati dallo IAB (Internet
Activities Board) e contenuti nei documenti STD/RFC raccomandati dall’IETF (Internet
165
Engineering Task Force). Ricordiamo che il gruppo di lavoro IETF è una delle due unità
organizzative in cui è diviso lo IAB ed è responsabile dei processi di standardizzazione.
L’altra unità organizzatova è lo IRTF (Internet Research Task Force).
Il nodo “management” ha un unico sottonodo: MIB-2. Al disotto del sottonodo
MIB-2 si trovano oggetti gestiti standardizzati che un Agente può scegliere e includere
nella sua Agent MIB, base dati contenente le rappresentazioni astratte delle risorse
gestite reali relative ad uno specifico elemento di rete.
ATTENZIONE: non confondere questa Agent MIB, base dati, con la MIB-2 di cui
stiamo parlando ora, sottoalbero dell’albero OID!
Dalla Fig. 7.7.1 si vede che gli OID di tutti gli oggetti nella MIB-2 hanno il
prefisso 1.3.6.1.2.1. La MIB-2 si chiama anche “MIB-standard” per distinguerla dalle
“MIB sperimentali” e le “MIB private” di cui parleremo fra poco.
La genesi del nome MIB-2 è la seguente. La MIB-2 fu inizialmente specificata
dall’IETF sotto il nome MIB-1 e poi modificata in MIB-2. Quindi l’ultima versione della
MIB é la MIB-2 che é specificata nel documento RFC 1213 “Management Information
Base for Network Management of TCP/IP based internets:MIB-II”, Marzo 1991.
Il nodo experimental (3) é usato per gli oggetti che sono correntemente in fase di
sperimentazione da parte del IETF. Quindi sotto questo nodo esistono sottoalberi
rappresentativi di “MIB sperimentali” che sono attualmente oggetto di studio e che un
giorno petrebbero essere trasferiti sotto il nodo management (2).Il nodo private (4) é
molto usato dai venditori di apparati. Infatti, come mostrato in Fig.7.7.2, tramite l’unico
nodo figlio enterprise (1) ogni venditore può richiedere ed ottenere l’assegnazione di un
nodo sottostante (e del relativo numero di nodo) per caratterizzare i propri prodotti. Per
un costruttore/venditore di apparati, un sottoalbero privato (“MIB privata”) dove sono
descritti in modo formale i propri prodotti è un mezzo potente per trasferire informazione
ad altri costruttori/venditori. Attualmente ci sono migliaia di identificatori relativi a
migliaia di venditori di apparati. Tutti gli identificatori di una cominciano con il
prefisso 1.3.6.1.4.1. Ad esempio in Fig.7.2.2 si vede che alla ditta CABLETRON é stato
assegnato il numero 52, quindi gli OID dei prodotti CABLETRON cominceranno tutti
con la sequenza 1.3.6.1.4.1.52. Questa sequenza sarà seguita dai numeri derivati dalla
Mib privata CABLETRON. Infine è importante notare come la suddivisione del nodo
internet in quattro sottonodi offra una struttura dell’informazione gestionale in evoluzione
che soddisfa due requisiti importanti: possibilità di usare subito oggetti gestiti
standardizzati e flessibilità di introdurre nuovi oggetti gestiti in linea con l’innovazione
delle tecnologie e la crescita dei prodotti disponibili sul mercato. Questa flessibilità è
garantita dalla triplice possibilità di espandere la MIB standard, trasferire le MIB
sperimentali nella zona standard o aggiungere/espandere MIB private.
166
•
MIBs diverse dalla MIB-2 (?)
A questo punto è bene riconoscere che, non solo ci sono diverse MIB
standardizzate da diverse organizzazioni o MIB private specificate da
costruttori/venditori privati ma anche la stessa IETF può emettere specifiche/standards
relativi a MIBs diversi dalla MIB-2 che standardizzano gruppi di oggetti di natura
diversa. Ad esempio differenti organizzazioni sottopongono al IETF delle proposte per
ottenere RFC’s relativi a MIB’s. Una di queste organizazzioni è l’ATM Forum. Esempi
di RFC’s supportate dall’ATM Forum in ambito IETF sono l’ RFC 1695 (chiamato
AToMMIB), una delle prime MIB’s proposte per la standardizzazione di reti ATM
private, ed il suo aggiornamento RFC 2515, “Definition of Managed Objects for ATM
Management”, molto usato per la gestione della configurazione e il funzionamento di
reti ATM. (L’ RFC 2515 è coordinato con le specifiche originali contenute nel ILMI
MIB (af-ilmi-0065.000) dell’ATM Forum).
Il fatto che diversi gruppi di oggetti siano standardizzati secondo diversi MIB fa si
che che per la gestione di oggetti diversi in uno stesso apparato si possa adottare piu’ di
un MIB standard e/o strutture MIB non-standard. Ad esempio un terminale d’utente di
tipo satellitare puo’ adottare MIB-II per gruppi di oggetti relativi a interfacce terrestri
tipo IP, ILMI-MIB per intefacce d’antenna tipo ATM e MIB proprietari (cioè non
standardizzati) per altri oggetti e.g. temperature all’interno degli apparati. Ovviamente
bisogna poi tener conto di tutto questo nella preparazione dei messaggi gestionali che
accedono a questi oggetti.
7.7.2 La struttura della MIB-2: 171 oggetti in 11 gruppi.
La Fig.7.2.1 mostra la suddivisione della MIB-2 in undici gruppi. Qui di seguito
descriviamo ogni gruppo individualmente. L’ultimo numero fra parentesi rappresenta il
numero di oggetti contenuto nel gruppo. Gli oggetti possono essere oggetti scalari o
oggetti tavola. Tutti gli oggetti gestiti nella MIB-2 sono obbligatori. I gruppi sono:
1) Sistema. In questo gruppo, ogni oggetto descrive una caratteristica fisica del
sistema rilevante alla gestione del sistema stesso (e.g. ubicazione, venditore,
Persona TLC da contattare in caso di guasto, tempo di funzionamento, etc.).
Come si vede si tratta di ciò che nel linguaggio OSI-SM venivano chiamati
“attributi” di un oggetto gestito. Qui si usa la parola “sistema“ per indicare
l’elemento di rete o apparato gestito, adottando, quindi, la terminologia OSI.
Vedere il prossimo paragrafo 7.7.3 per conoscere i sette oggetti gestiti che
appartengono a questo gruppo Inoltre in Fig. 7.7.5 si possono vedere esempi di
valori delle sette variabili. In generale l’Agente restituisce l’informazione
richiesta dal Gestore (i.e. valore dell’oggetto). Tuttavia, se l’Agente non ha
configurato il sistema con un valore non-nullo per ogni oggetto, si deve
assumere un valore default di inizializzazione uguale a zero cioè in mancanza di
un valore specifico per l’istanza dell’ oggetto in esame, l’Agente risponde con
una sequenza { } di lunghezza nulla. (7 oggetti vedi Fig.7.7.4)
167
ITU
(0)
ISO (1)
Joint ISO-ITU
(1)
(2)
(3)
Identified Organization (3)
(1) …..
(2)
(1)…….. (5)
DoD (6)
Ente Nazionale di Standardizzazione
(US National Institute of Standards
and Technology, NIST)
Departmentof Defense
INTERNET (1)
Directory (1)
Management (2)
MIB-2 (1)
system (1) interfac.(2) at(3)
ip(4)tcmp (5)
Experimental (3)
Private (4)
1.3.6.1.2.1
tcp (6) udp (7)
egp (8) cmot (9) transmis.(10) snmp (11)
Fig.7.7.1 Il sottoalbero MIB-2 contiene 11 gruppi e 171 oggetti SNMP
2) Interfacce. Questo gruppo fornisce informazione sulle interfacce di un sistema
gestito e.g. numero delle interfacce, loro stato, capacità, condizione di traffico etc.
L’oggetto può presentarsi come « tavola » («table» in inglese) dove ogni riga
riporta i dati di una interfaccia. Questo gruppo permette la gestione dell’apparato ai
livelli piu’ bassi della pila di protocolli TCP/IP (Vedi Fig.7.2.3). Ogni oggetto é
obbligatorio. (22)
3) Traslazione di indirizzo (address translation). Traslazione di indirizzo da IP a
indirizzo fisico. Nella MIB-2 questo gruppo é stato abolito. L’informazione
fornita da questo gruppo e’ inglobata in una tavola del gruppo IP (Vedi dopo)(3)
4) IP. Protocollo IP. Sono oggetti (tre oggetti tavola e un gruppo di 22 oggetti scalari)
che forniscono informazione sul funzionamento dello strato IP. Ad esempio
forniscono dati su prestazioni e.g. in termini di numero di datagrammi ricevuti e
trasmessi dall’apparato, livello di errori e.g. in termini di numero di datagrammi in
errore, tavole di routing e conversione di indirizzi. Le tre tavole sono: 1) IP Address
Table, 2) IP Routing Table e 3) IP Address Translation Table. Ogni oggetto é
obbligatorio. (22 oggetti scalari +3 oggetti tavola)
168
Esempi di oggetti appartenenti al gruppo IP:
Nome Oggetto
Sintassi
IpForwarding
INTEGER
IpInReceives
ipInHdrErrors
Accesso
ID
Descrizione
RW
1
Indica se questa entita’
funziona come un gateway.
YES=0; NO=1
Counter
RO
3
Numero totale di datagrammi
di ingresso ricevuti dall’entita
Counter
RO
4
Numero di datagrammi di
ingresso scartati a causa di
errori nei loro IP headers.
5) ICMP. Sono oggetti rappresentativi del protocollo ICMP (Internet Control
Message Protocol) che forniscono informazioni su statistiche di traffico di ingresso
e uscita e sulle prestazioni degli stessi datagrammi ICMP. Ogni oggetto é
obbligatorio.(26)
6) TCP. Questo gruppo di oggetti fornisce informazioni sul protocollo TCP.
(Transmission Control Protocol) e statistiche sulle connessioni TCP. Ogni oggetto é
obbligatorio (12)
7) UDP. Come sopra ma per il protocollo UDP (User Datagram Protocol).Statistiche
sul funzionamento UDP. Ogni oggetto é obbligatorio. (4)
8) EGP. Gruppo di oggetti che forniscono informazione sulle prestazioni del
protocollo EGP (Exterior Gateway Protocol). EGP e’ un protocollo internet per lo
scambio di dati relativi agli instradamenti in due sistemi autonomi. Ogni oggetto é
obbligatorio. (8)
9) CMOT. Ha solo importanza storica. L’ introduzione di questo gruppo di oggetti
nella MIB avvenne quando gli sforzi per sviluppare un protocollo CMIP su TCP/IP
(CMOT) erano ancora molto vigorosi ma poi col tempo si sono affievoliti e questo
gruppo ha perso ogni importanza.
(10) Trasmissione. Questi oggetti rappresentano parametri rilevanti alla gestione
delle caratteristiche trasmissive delle reti (LAN, WAN etc.). Correntemente non
ci sono oggetti MIB-2 che facciano parte di questo gruppo.
(11) SNMP. Oggetti relativi alla gestione del protocollo SNMP. Controllo e
monitoraggio della gestione SNMP. É il guardiano che guarda il guardiano! Ogni
oggetto é obbligatorio. (30)
La Fig. 7.2.3 mostra dove questi gruppi di oggetti risiedono nel modello di
riferimento internet.
169
Internet (1.3.6.1)
Private (4)
Enterprises (1)
CISCO (9)
HP (11)
3COM (43)
CABLETRON(52)
Fig.7.7.2 Il sub-albero del nodo “ private (4)” per venditori di apparati internet .
7.7.3 Esempio di struttura di un gruppo MIB-2: il gruppo “sistema“.
Ogni gruppo MIB-2 ha una sua struttura interna ad albero. Come esempio
consideriamo il gruppo system (1). La Fig. 7.2.4 mostra il sub-albero del nodo system (1)
che fornisce una descrizione delle caratteristiche fisiche dell’apparato da gestire. Ci sono
sette oggetti che sono figli di questo nodo. Come precedentemente indicato, ogni oggetto
é specificato da un identificatore OID, un nome descrittore, sintassi, accesso e una breve
descrizione. Per ogni oggetto abbiamo anche incluso un esempio di un possibile valore.
1.3.6.1.2.1.1.1 sysDescr, testo descrittivo del sistema preparata dal venditore.
Sintassi: Display String (0-255). Accesso: Read-only. [Nota: DisplayString é una
convenzione testuale definita come un “ octet string“ che utilizza fino a 256
caratteri presi dal set di caratteri NVT US-ASCII ( Network Virtual Terminal
US-American Standard Code for Information Interchange) presentato in RFC
854]
1.3.6.1.2.1.1.2 sysObjectID, elemento identificatore del sistema come
specificato dal venditore nel sottoalbero del nodo “enterprises”. Ad esempio
un possibile valore per una apparecchiatura del venditore HP potrebbe essere
{enterprises 11.2.3.10.1.2}. Notare che in questo caso l’identificatore é espresso
170
in forma contratta. La forma completa sarebbe {iso. org. dod. internet. private.
enterprises. 11.2.3.10.1.2} oppure espresso in numeri (1.3.6.1.4.1.11.2.3.10.1.2}.
Il questo caso il venditore é la compagnia HP caratterizzata dal numero 11 sotto il
nodo “enterprises“ (Vedi Fig.7.2.4). I numeri dopo il numero 11 rappresentano un
sottoalbero nella MIB privata della HP. Sintassi: OBJECT IDENTIFIER.
Accesso: Read-only
1.3.6.1.2.1.1.3 sysUpTime é un indice della salute del sistema e rappresenta il
tempo totale di funzionamento del sistema stesso. Viene aggiornato in modo
dinamico dall’operatore. Ad esempio: 36 giorni, 4 ore, 27 minuti, 14 secondi e
4/100 di secondo. Sintassi:Time Ticks, sequenza di numeri interi rappresentativa
del tempo totale espresso in centesimi di secondo. Accesso: Read-only
1.3.6.1..2.1.1.4 sysContact, Persona TLC responsabile dell’apparato (da
contattare se necessario). Ad esempio: Sig. Silvio Berlusconi....scritto in ANS.1.
Sintassi: Display String (0-255). Accesso: Read-Write
1.3.6.1.2.1.1.5 sysName, nome internet dell’apparato e.g. “router1.gatech.edu“
per il router No.1 ubicato nell’Università di Tecnologia della Georgia (Georgia
Tech). Sintassi: Display String . Accesso: Read-Write
1.3.6.1. 2.1.1.6 sysLocation, ubicazione dell’apparato in rete. Sintassi: Display
String. Accesso: Read-Write
1.3.6.1.2.1.1.7 sysServices, servizi forniti dall’apparato. In generale indicato con
un numero intero che rimanda ad un elenco di possibili servizi. Sintassi:
INTEGER (0-127). Accesso: Read-only
La Fig.7.2.5 mostra come i sette oggetti del gruppo sistema (1) sono letti
nel corso di un servizio di gestione SNMP GetRequest/GetResponse. Gli oggetti
gestiti (in un contesto SNMP chiamati anche “variabili“) sono mostrati sul lato
destro.
171
ManagedNetworkElement
SYSTEM
SNMP
Process
UDP
TCP
Host-to-Host
IP
EGP
ICMP
Internet
ADDRESS
TRANSLATION
TRANSMISSION
INTERFACES
Net Access
Fig.7.7.3 Questa figura mostra dove i gruppi
-2 risiedono
MIB
nel
modello di riferimento internet.
172
System (mib-2.1)
1)
sysDescr (1)
sysObjectId (2)
sysUptime (3)
sysContact (4)
sysName (5)
sysLocation (6)
sysServices (7)
Fig. 7.7.4. Il gruppo “sistema” nella MIB-2
173
MANAGER
sysDescr.0
sysDescr.0 = “SunOS”
AGENT
sysDescr
sysObjectID.0
sysObjectID.0 = enterprises. 11.2.3.10.1.2.
sysObjectID
GetRequest
sysUpTime.0
GetResponse
sysUpTime
sysUptime.0 = 2247349530
sysContact.0
sysContact
sysContact.o = “ “
Variabile
sysName.0
sysName
sysName.0 = noc1
sysLocation.0
Fig.7.7.5 Esempio di
operazione
GetRequest/Response
per il gruppo “sistema”.
sysLocation
sysLocation.0 = “ “
sysService.0
sysService.0 = 72
174
sysServices
MANAGER
sysDescr.0
sysDescr.0 = “SunOS”
AGENT
sysDescr
sysDescr.0
GetNextRequest
sysObjectID.0 = enterprises. 11.2.3.10.1.2.
sysDescr
sysObjectID.0
GetRequest
GetResponse
sysUptime.0 = 2247349530
sysUpTime.0
sysContact.o = “ “
sysContact.0
sysName.0 = noc1
sysObjectID
sysUpTime
sysContact
Variabile
sysName.0
sysLocation.0 = “ “
sysName
sysLocation.0
Fig.7.7.5.A Esempio di
operazione
GetNextRequest/Respon
se per il gruppo
“sistema”.
sysService.0 = 72
sysLocation
sysService.0
sysServices
endofMIBview
175
7.8 Aspetti comunicativi del modello SNMP
7.8.1 I messaggi gestionali SNMP scambiati fra Gestore e Agente
Per essere “semplice” il protocollo SNMPv.1 prevede cha il Gestore richieda all’
Agente di effettuare un numero limitato di operazioni sugli oggetti gestiti contenuti
nella Agent MIB.
NOTA BENE : Il Gestore non richiede che gli oggetti gestiti effettuino essi stessi operazioni poichè,
come precedentemente indicato, gli oggetti SNMP non hanno la funzionalità di effettuare operazioni.
Si tratta solo di operazioni effettuta sugli oggetti da parte di un Agente su richiesta di un Gestore.
In pratica le richieste di operazioni sono effettuate tramite invio da parte del
Gestore di due tipi di messaggi principali: messaggi GET-REQUEST relativi a
« richiesta di letturaleggi » o messaggi SET-REQUEST relativi a « richiesta di
scrittura », il valore di una istanza di un oggetto gestito. L’Agente risponde con
messaggi tipo GET-RESPONSE oppure può emettere messaggi non sollecitati tipo
TRAP corrispondenti alle « notifiche » OSI. I messaggi menzionati realizzano
operazioni gestionali rispettivamente di monitoraggio (leggi) e monitoraggio/controllo
(leggi/scrivi).
Lo scambio di messaggi Gestore-Agente a livello applicativo avviene utilizzando
i servizi di tutti gli strati della pila TCP/IP (Vedi Fig.7.3.1) in modo simile a quanto si
faceva nel modello OSI-SM con la pila OSI.
Piu’ precisamente il protocollo SNMPv1 prevede cinque tipi di messaggi mentre
il protocollo SNMPv2 ne prevede due in più cioè sette. I cinque messaggi SNMPv.1 sono
1. GET-REQUEST,
2. GET-NEXT-REQUEST,
3. SET-REQUEST,
4. GET-RESPONSE,
5. TRAP.
Ma vediamo in dettaglio cosa accade nel caso dei vari messaggi.
7.8.2 Il messaggio GET-REQUEST, i concetti di « MIB view » e «comunita’».
Quando un Gestore manda un messaggio GET-REQUEST ad un Agente, in effetti
egli chiede all’Agente di leggere i valori delle istanze dei tipi di oggetti gestiti la cui
locazione nella MIB è specificata da identificatori d’istanza IID contenuti nel messaggio.
(Ricordiamo che per oggetti semplici mono-valore l’identificatore d’istanza è legato
all’identificatore d’oggetto OID dalla relazione IID = OID.0, dove l’indice zero identifica
176
la natura “monovalore ” dell’oggetto). Quindi non è necessario che un Gestore invii un
messaggio per ogni valore richiesto ma un solo massaggio GET-REQUEST può
includere più IID e quindi richiedere la lettura dei valori di più istanze. E questo è un
notevole vantaggio offerto dalla gestione SNMP. Vedremo fra poco come tutto ciò possa
essere fatto.
Teoricamente un Gestore potrebbe inviare un messaggio GET-REQUEST ad un
Agente chiedendo di leggere il valore di una qualsiasi istanza nella MIB, semplicemente
includendo nel messaggio l’apposito indicatore di istanza IID. Tuttavia ciò in realtà non
è possibile poichè l’ IETF, per motivi di sicurezza, ha introdotto limiti su “chi può
gestire che cosa”. Nella gestione SNMP il Gestore non può accedere ad un qualsiasi
oggetto contenuto nella MIB: certi Gestori possono accedere solo a certi oggetti
secondo un criterio stabilito dall’Agente. Più precisamente i Gestori appartenenti ad un
gruppo (“comunita’”) definito dall’ Agente possono accedere ad un insieme di oggetti
(“MIB-view”) anch’esso definito dall’Agente secondo modalità di accesso (“privilegi di
accesso”) anch’esse definite dall’Agente. (Vedi Fig.7.8.2.1)
Quindi, la “MIB view” è l’insieme degli oggetti MIB “visti” o gestiti da un
Agente per conto di un certo numero di Gestori appartenenti ad una comunita’. Gli
oggetti gestiti contenuti in una MIB view sono stati presi dal repositorio MIB-2 cioè
hanno identificatori d’oggetto e d’istanza ma non devono necessariamente appartenere
allo stesso sottoalbero.
Una “comunita’” è costituita da un Agente e dall’ insieme dei Gestori
autorizzati ad accedere agli oggetti contenuti in una “MIB view”. La comunità e la
MIB-view sono definite dall’ Agente.
Una comunità è caratterizzata da un “community name” che viene inserito in un
messaggio GET-REQUEST e usato come lasciapassare per accedere a una MIB view.
La verifica del lasciapassare viene effettuata dall’Agente come segue.
Quando l’Agente riceve un messaggio GET-REQUEST contenente un community
name, egli verifica che il Gestore appartenga ad una comunita’ autorizzata all’accesso
della MIB-view che contiene l’oggetto destinatario del messaggio. Se la verifica è
positiva la richiesta del Gestore viene soddisfatta. Se invece la verifica è negativa la
richiesta del Gestore viene rigettata.
177
GESTORE 1
AGENTE
RO
RW
ELEMENTO
RETE
GESTORE 2
GESTORE N
SNMP
COMMUNITY
MIB VIEW
Fig.7.8.2.1 Un sottoinsieme di oggetti MIB II “visto” da un Agente costituisce
una MIB view. L’Agente permette la gestione degli oggetti in una MIB view
solo ai gestori appartenenti ad una “comunita’ “ di Gestori.
178
Quindi il community name incluso nel messaggio GET-REQUEST (e anche nel
messaggio SET-REQUEST) è un dispositivo di sicurezza che permette l’accesso ad una
MIB-view solo ai Gestori autorizzati e solo dopo verifica da parte dell’Agente.
In effetti il community name è un dispositivo di sicurezza talmente embrionale da
essere di scarsa utilità pratica. Infatti un Gestore non-autorizzato può facilmente
impossessarsi di un messaggio GET-REQUEST, leggere il community name relativo
all’oggetto destinatario, e poi usare questo community name per accedere egli stesso
all’oggetto. In tutto questo l’Agente controllore non può accorgersi che la richiesta
proviene da un Gestore non-autorizzato che si è impossessato illegalmente di un
comunity name..
Per questa ragione la gestione SNMPv.1 fu considerata sin dall’inizio
estremamente carente dal punto di vista della sicurezza e una delle ragioni per sviluppare
la nuova gestione SNMPv.2 fu proprio la necessità di avere un sistema gestionale piu’
sicuro. In verità anche la gestione SNMP v.2 fu considerata insufficiente dal punto di
vista della sicurezza e si dovette aspettare la terza versione SNMP v.3 per ottenere dei
risultati soddisfacenti.
7.8.3
Vantaggi e svantaggi della GET-REQUEST
Un vantaggio offerto dalla gestione SNMP è certamente la possibilità di leggere
più valori con un solo messaggio GET-REQUEST. Vedremo ciò in dettaglio quando
parleremo della struttura dei messaggi. Un grosso svantaggio della versione SNMPv.1 è
la atomicità dell’operazione di lettura dei valori cioè o tutti i valori vengono letti o
nessuno: non c’è possibilità di una risposta parziale da parte dell’Agente in cui alcuni
valori vengono recuperati ed altri invece non sono letti e l’Agente restituisce una risposta
di errore (e.g. “noSuchName”). Questo inconveniente è stato rimediato nella SNMP v.2.
Nel caso in cui una istanza non possa essere letta perché non esiste (l’Agente non ha
effettuato il processo di istanzazione) il problema può risolversi con l’uso di un
messaggio GET-NEXT-REQUEST.
7.8.4 Il messaggio GET-NEXT-REQUEST e l’ordine lessicografico degli oggetti
nella MIB view.
Ricordiamo che come al solito “oggetto” in effetti significa “tipo di oggetto”.
Il messaggio GET-NEXT-REQUEST è formalmente simile al messaggio GETREQUEST ma profondamente diverso per i risultati che la sua utilizzazione può
produrre. Con un messaggio GET-NEXT-REQUEST il Gestore ottiene, come
risposta dall’Agente, il valore dell’istanza “successiva” all’oggetto o all’istanza
specificata tramite OID o IID nel messaggio di richiesta. Il termine “successiva”, si
riferisce all’ordine lessicografico degli oggetti e delle loro istanze contenute nella MIB
view. In Appendice 1 viene mostrato che le sequenze di numeri interi, come in effetti
sono gli identificatori OID o IID, possono essere a loro volta ordinate in sequenze
secondo un ordine chiamato “lessicografico”. Viene anche mostrato come la
convenzione IID = OID.0 adottata per rappresentare gli indicatori di un oggetto scalare fa
sì che l’istanza segua lessicograficamente l’oggetto. Sono proprio queste proprietà di un
179
ordinamento lessicografico che vengono sfruttate nella utilizzazione dei messaggi GETNEXT-REQUEST.
Ad esempio si faccia riferimento alla Fig.7.8.4.1 doveè illustrato un oggetto
“nodo”, parente di un sottoalbero OID costituito da tre oggetti scalari. Assieme agli
oggetti anche le istanze sono rappresentate. Una istanza per oggetto. Le frecce indicano
l’istanza successiva in ordine lessicografico.
Se il Gestore specifica in un messaggio GET-NEXT-REQUEST gli identificatori
d’oggetto OID = x, y, z relativi ai tre oggetti con nome simbolico nomSimb1,
nomSimb2 e nomSimb3, egli riceve dall’ Agente un messaggio di risposta GETRESPONSE che contiene il valore “a” dell’istanza successiva all’oggetto nomSimb1, il
valore “b” dell’istanza successiva all’oggetto nomSimb2 e il valore “c” dell’istanza
successiva all’ oggetto nomSimb3. Nel messaggio GET_RESPONSE questi valori
saranno specificati sottoforma di tre coppie, x.0 = a, y.0 = b, z.0 = c (che utilizzano gli
identificatori d’istanza x.0, y.0, z.0).
Se il Gestore specifica in un messaggio GET-NEXT-REQUEST l’identificatore
d’oggetto OID = g relativo all’oggetto nodo l’Agente restituisce il valore “a” della prima
istanza seguente in ordine lessicografico cioè l’istanza del primo oggetto nomSimb1 cioè
restituisce lo stesso valore ottenuto in risposta all’ OID = x ! Questo risultato è
importante perchè mostra come la coppia x.0 = a del primo oggetto possa ottenersi
inviando solo un identificatore OID=g e ignorando l ‘identificatore x dell’oggetto: si è
ottenuto il valore e l’identificatore di un oggetto gestito sconosciuto!
7.8.5 Il messaggio SET-REQUEST e i problemi di sicurezza
Il messaggio SET REQUEST è una richiesta di modifica dei valori esistenti degli
oggetti gestiti con nuovi valori (specificati nel messaggio stesso)
7.8.6 I messaggi GET-RESPONSE e TRAP emessi dall’Agente
L’Agente emette un messaggio di risposta GET-RESPONSE sincrono ma può
emettere anche un messaggio in modo spontaneo (in generale non periodico o asincrono)
chiamato TRAP, per notificare al Gestore l’occorrenza di eventi importanti da un punto
di vista gestionale. La TRAP evita ai Gestori verifiche periodiche (polling)dello stato
degli Agenti.
7.8.7 I messaggi INFORM-REQUEST e GET-BULK-REQUEST
Il protocollo piu’ recente SNMPv2 (versione 2) ha due tipi di messaggi in più:
1. INFORM-REQUEST
2. GET-BULK-REQUEST.
La INFORM-REQUEST permette ad un Manager di mandare informazione tipo
TRAP ad un altro Manager ( messaggio indicato con zero in Fig.7.8.7.1).
180
La richiesta GET-BULK-REQUEST e’ una generalizzazione della GET-NEXTREQUEST in cui la risposta da parte dell’Agente fornisce i valori relativi a più istanze
successive ( non solo ad una istanza successiva come nella GET-NEXT-REQUEST). La
GET-BULK-REQUEST permette ad un Manager di accedere in maniera efficiente (i.e.
minimizzando il numero di messaggi necessari per recuperare un certo volume di dati) a
oggetti aggregati e.g. oggetti “tavola” molto grandi.
181
Oggetto gruppo
di oggetti
scalari. OID = g
OGGETTI
nomSimb1
OID = x= g.1
ISTANZE
(valore)
nomSimb2
OID = y= g.2
nomSimb3
OID = z = g.3
(a)
(b)
(c)
IID = x.0
IID = y.0
IID = z.0
Per leggere i valori associati a tutte le istanze il Gestore invia:
1. GetRequest (x.0, y.0, z.0), inviando gli IID, oppure
2. GetNextRequest (x, y, z), inviando gli OID
In entrambi i casi la risposta e’: GetResponse (x.0 = a, y.0 = b, z.0 = c)
= indica l’istanza succesiva in ordine lessicografico
Fig.7.8.4.1 Nella gestione SNMP il Gestore può leggere i valori delle istanze con un messaggio GetRequest
indirizzato all’ istanza (IID) o con un messaggio GetNextRequest indirizzato all’oggetto (OID).
182
PROCESSO APPLICATIVO
“GESTORE”
0
1
2
3
4
5
PROCESSO APPLICATIVO
“AGENTE”
6
1
2
3
4
5
6
SNMP PDU
SNMP
SNMP
UDP
UDP
IP
IP
DL
C
DL
C
PHYSICAL
PHYSICAL
MEZZO FISICO
0.
1.
2.
3.
Inform-request
Get-request
Get-next-request
Get-bulk-request
4.
5.
6.
Set-request
Response
Trap
183
Fig.7.8.7.1 Struttura di SNMPv2
7.9
Struttura dei messaggi e delle PDU
7.9.1 La struttura del messaggio SNMP
La struttura del messaggio SNMP (codificato secondo il protocollo BER)
scambiato fra Gestore e Agente é mostrata in Fig.7.9.1 e 7.9.2. Ogni messaggio é
costituito da una parte di codifica (indicata con linee tratteggiate in rosso) e una parte
rappresentativa del messaggio vero e proprio.
1) Numero della versione del protocollo (Zero per SNMPv.1 e 1 per SNMPv.2)
2) Nome della Comunità usato nel processo di autenticazione (Octet String)
3) Dati della SNMP PDU
7.9.2
La struttura della PDU SNMP (per tutte le PDU meno la TRAP PDU)
A sua volta ogni SNMP PDU (ad eccezione di TRAP) é costituita da due parti :
una parte di codifica (PDU-Tag e PDU-Length) indicata con linee tratteggiate in rosso
più una parte costituita da quattro zone:
1) Request ID. E’ un intero che identifica univocamente una richiesta in modo
che la risposta, dopo ricezione, possa essere accoppiate correttamente con la
richiesta stessa.
2) Error Status. Usato solamente dall’Agente nella GetResponse-PDU per
indicare uno stato di errore nel comando ricevuto in precedenza e.g.
GetRequest-PDU. Esiste un codice di sei numeri, da zero a cinque, per
identificare il tipo di errore. In tutte le altre PDU ha valore zero. Ad esempio
l’errore “no such name” indicativo del fatto che l’oggetto target specificato
dal Manager nella sua richiesta non esiste, ha valore 2
3) Error Index. Indica la prima variabile nella lista VarBindList che ha causato
un errore (Vedi dopo)
4) Variable Binding List. Quest’ultima zona é costituita da una lista di coppie
« identificatore-valore », una coppia per istanza di oggetto gestito (chiamato
in SNMP “variabile”). Ogni coppia é codificata con BER e quindi é preceduta
dalle due zone « tag » e « length ». (Vedi Fig.7.9.2)
Questo formato é valido per tutte le PDU ad eccezione delle TRAP-PDU.
184
7.9.3
La struttura della TRAP PDU
La struttura per la TRAP PDU é mostrata in Fig.7.9.3. Le TRAP PDU hanno il
seguente formato
1) Enterprise – Questa zona contiene l’ OID dell’apparecchiatura che emette la
TRAP presa dal sottoalbero “Enterprise”. E’ simile al valore di sysObjectId (Vedi
Fig.7.7.5)
.
2) Agent address – Indirizzo IP dell’agente che ha inviato la TRAP.
3) Generic trap id – Indice (da 0 a 6) indicativo del tipo di TRAP standardizzata
e.g. coldStart (1), warmStart (2) etc.
4) Specific trap id – Indice che indica il tipo di TRA proprietario di un vendor XYZ
specifico (specificata nel sottoalbero XYZ del sottoalbero “enterprise”)
5) Time stamp – Tempo trascorso fra il tempo di inizializzazione dell’elemento di
rete il tempo di invio della TRAP
6) VarBind List come per le altre PDU è una coppia IID=valore relativa all’oggetto
gestito che emette la trap
185
Messaggio SNMPv1 codificato
Valore
BER
MT
ML
PDU-T
Versione
(*)
PDU-L
Comunità
SNMP(**)
Req.ID
Error Status
PDU
Error Index
VarBind List
M = Message, L = Length, T = Tag
Fig. 7.9.1 Struttura del messaggio SNMPv1 codificato con BER. (*) Per SNMPv.1 é un intero di valore
0. (**) Un “octet string” che contiene il nome della comunità usata nel processo di autenticazione. La
zona Req.ID inizia con un PDU Type Indication (command number) 0,1,2,3 rispettivamente per
GetRequest, GetNextRequest, GetResponse e SetRequest
186
PDU-T
PDU-L
Var No.1
tag
IID
Req.ID
Var No.1
length
Var No.1
Value
Error Status
. . . . .
Valore
Error Index
VarBind List
Var No.N Var No.N Var No.N
tag
length
Value
IID
Valore
Fig. 7.9.2 Struttura del messaggio SNMPv1 codificato con BER. VarBind List
= Variable Bindings List. OID = Object Identification.
187
Messaggio SNMPv1 codificato
Valore
BER
MT
ML
PDU-T
Versione
(*)
Comunità
SNMP(**)
PDU
PDU-L Enterprise Agent Generic # Specific # Time VarBind List
Stamp
Addr.
M = Message, L = Length, T = Tag
Fig 7.9.3 Struttura del messaggio SNMPv1 codificato con BER per la PDUTRAP. (*) Per SNMPv.1 é un intero di valore 0. (**) Un “octet string” che
contiene il nome della comunità usata nel processo di autenticazione.
188
7.10 Protocolli di supporto al protocollo SNMP.
Il protocollo SNMP è stato concepito per interconnessioni tipo “connectionless”
cioè nessuna connessione sorgente-destinatario esiste prima dell’invio dei dati. Questo
meccanismo di trasporto è molto semplice ma non offre alcuna garanzia sulla effettiva
consegna dei dati al destinatario e quindi sulla qualità del servizio. In termini piu’ precisi
si dice che il protocollo SNMP è stato concepito per essere supportato dalla pila di
protocolli “connectionless” User Datagram Protocol (UDP) sovrapposto a Internet
Protocol (IP).(Vedi Fig. 7.8.7.1)
Il carattere “connectionless” dei protocolli di supporto offre vantaggi e svantaggi.
Come vantaggio, si deve riconoscere che conferisce una certa robustezza alla
connessione, nel senso che l’Agente ed il Manager sono completamente disaccoppiati
cioè nessuno dei due dipende dall’altro per effettuare le proprie operazioni e, ad esempio,
un Manger puo’continuare ad operare anche se un Agente subisce un guasto. Quando
l’Agente ricomincia a funzionare egli manda un messaggio TRAP al Manager indicando
la ripresa della sua attività. Come svantaggio si deve riconoscere che la natura
“connectionless” del SNMP lascia la funzione “recovery and error detection” sulle spalle
del Gestore nella stazione NMS (Network Managment Station).
In ogni caso, anche se il protocollo SNMP è stato concepito per un supporto
“connectionless”, in pratica esso puo’ essere supportato da altri protocolli (e.g.
“connection-oriented” come TCP o ATM) utilizzando gli opportuni strati di adattamento.
In effetti il protocollo SNMP puo’ riguardarsi come indipendente dai protocolli di
supporto
7.11
Bibliografia e riferimenti.
1. David Zeltserman, “Practical Guide to SNMPv3 and Network Management”,
Prentice Hall, May 1999.
2. William Stalling, “SNMP, SNPv2, SNMPv3 and RMON 1 and 2”, AddisonWesley, 1998.
3. Jeffrey Case, Rob Frye, Jon Saperia, “SNMPv3 Survival Guide”, John Wiley,
October 1999.
4. David Perkins, Evan McGinnis, “Understanding SNMP MIBs”. Prentice Hall,
December 1996.
5. Bob Natale, “SNMPO Agents”, Macmillan Technical Publishing/Cisco Press,
December 2000.
6. John Larmouth, “ASN.1 Complete”, Morgan Kaufman Publishers, October 1999.
7.12 Esercizi (Capitolo 7)
1. Cosa é il Modello gestionale SNMP?
2. Il modello gestionale SNMP é stato sviluppato per quali ragioni e per quale tipo di reti
di telecomunicazione? Non ere forse sufficiente avere il modello OSI-SM?
189
3. Quali sono gli aspetti organizzativi, informativi, comunicativi e funzionali del modello
SNMP?
4. Il modello SNMP definisce tre tipi di standards. Quali sono questi standards?
5. Gli standards relativi agli aspetti informativi del modello sono contenuti nella
Structure of Management Information (SMI). Quale é la differenza fra un oggetto gestito
OSI ed un oggetto gestito SNMP?
6. In un contesto SNMP quale e’ la differenza fra “messaggio” e “PDU”?
7. La MIB view e’ l’elemento di rete “visto” dall’Agente. La mappatura risorsa gestitaoggetto gestito e’ uno-a-uno?
APPENDICE al CAPITOLO 7
A7.1
•
L’ordine lessicografico (Fig. A7.1.1 e A7.1.2)
Il criterio matematico alla base dell’ordinamento lessicografico
L’ordine lessicografico è un ordine secondo cui si possono ordinare sequenze di
numeri interi positivi. Il criterio su cui si basa questo ordine è definito
matematicamente come segue.
Date due sequenze ordinate di numeri interi positivi {xi }e {yj} con 1 ≤ i ≤ N e 1≤ j
≤ M si dice che la sequenza {xi } precede la sequenza {yj} se sono verificate le
condizioni seguenti:
1) Caso No.1.
xi = yj 1 ≤ i < k CORREZIONE
xk < yk k < N, M
Esempio: N = 6, M = 5, k = 4
La sequenza {xi } = 2.2.2.1.3.4 precede la sequenza {yj} = 2.2.2.2.3 perchè 1 < 2
2)
xi = yi
Caso No.2
N<M
Esempio: N = 2, M = 3
190
{xi } = 2.2 precede {yj} = 2.2.0 perché la prima sequenza è più corta della seconda
Una conseguenza importante del caso No.2 è che, poichè in un oggetto scalare
IID = OID.0, la istanza di un (tipo di ) oggetto scalare segue sempre (il tipo di) oggetto
scalare stesso. (Vedi Fig, A7.1.1)
•
Ordinamento lessicografico di sequenze di numeri interi positivi e
ordine alfabetico di sequenze di lettere (nomi).
Notare che l’ordinamento lessicografico di sequenze di numeri interi positivi è
l’equivalente numerico dell’ordine alfabetico usato per ordinare sequenze di lettere
dell’alfabeto. Ad esempio se devo ordinare alfabeticamente i seguenti cognomi
Albertini
Alberoni
Albertelli
Amendola
automaticamente scrivo la sequenza
Albertelli
Albertini
Alberoni
Amendola
dove , forse inconsapevolmente, in effetti ho applicato un criterio analogo al
criterio matematico precedentemente esposto nel quale al criterio “minore di” ho
sostituito il criterio “precede nell’alfabeto”. Ad esempio per ordinamento “Albertelli,
Albertini”, k= 7, xk = e “precede nell’alfabeto” yk = i
•
Ordinamento lessicografico e struttura ad albero (Fig. A 7.1.2)
La relazione fra ordinamento lessicografico e una struttura ad albero (e.g. albero
delle registrazioni) si basa sul fatto che in quest’ultima ad ogni nodo è assegnato un
numero intero positivo e, allo stesso tempo, ogni nodo è convenzionalmente la
rappresentazione grafica di una sequenza di numeri interi positivi ottenuta
percorrendo l’ albero dalla radice al nodo. Ad esempio in Fig. A.7.1.2 ci sono tredici nodi
e quindi l’albero rappresenta tredici sequenze di numeri interi positivi. Il nodo piu’ in
basso a sinistra rappresenta la sequenza 1.1.1.1. Questa corrispondenza biunivoca fra
nodi e sequenze ci permette di parlare in modo interscambiabile di nodi o sequenze di
numeri. Ci si pone allora la seguente domanda: quale è l’ordinamento lessicografico dei
nodi in un albero delle registrazioni e.g. come quello mostrato in Fig.A.7.1.2 ?
La risposta si trova applicando il seguente criterio grafico. Si consideri un albero
costituito da sottoalberi i cui nodi foglia siano numerati con numeri interi positivi
crescenti da sinistra verso destra. La sequenza dei nodi in ordine lessicografico si ottiene
partendo dalla radice dell’albero e percorrendo da sinistra a destra i sotto alberi
dall’Alto al Basso da Sinistra a Destra. Quindi i primi quattro nodi in ordine
lessicografico sono quelli corrispondenti al lato estremo a sinistra dell’albero percorso
dall’alto verso il basso: (1), (1.1), (1.1.1), (1.1.1.1) Il prossimo nodo è (spostandosi
191
leggermente a destra): 1.1.1.4. Spostandosi ulteriormente a destra si trovano i nodi 1.1.2,
1.1.2.3 e 1.1.2.4 e cosi’ via. La sequenza lessicografica completa dei tredici nodi è
mostrata nell’inserto della Fig. A 7.1.2 . Ovviamente l’ultimo nodo della sequenza e’ il
nodo in basso all’estrema destra cioe’ 1.3.5.5
192
OGGETTO
(OID)
ORDINE
ISTANZA
(IID = OID.0)
LESSICOGRAFICO
PRECEDE
SEGUE
Fig.A7.1.1
193
OGGETTI MIB in ORDINE LESSICOGRAFICO
NUMERI IN ORDINE:
NUMERICO
1
3
6
11
17
29
58
77
79
112
176
190
234
LESSICOGRAFICO
1
11
112
17
176
190
234
29
3
465
58
6
674
1
11
111
1111
1114
112
1123
1124
12
13
135
1
1
2
1
1
3
2
4
3
5
4
4
5
OGGETTI MIB IN ORDINE LESSICOGRAFICO
Fig.A7.1.2
194
195