ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
1. Introduzione: Network Management e ITU TMN
Claudio Salati
Copyright © 2001 by Claudio Salati
1
GESTIONE
Insieme delle attivita' di
• Pianificazione
• Installazione
• Configurazione
• Monitoraggio
• Manutenzione
• Contabilizzazione
Necessarie per controllare (attivamente e passivamente) e ottimizzare le
funzionalita' di una rete ed i servizi da essa forniti.
RETE
• TLC: OTN, SDH, PDH, ATM, PSTN, radiomobile, …
• Calcolatori: OSI, internet, …
2
AREE FUNZIONALI DI GESTIONE
ITU M.3400 definisce 5 aree funzionali di gestione:
• Performance management
• Fault management
• Configuration management
• Accounting management
• Security management
Si fa riferimento alla normativa ITU perche' le prime grandi reti
sono state reti TLC, ed e' in questo ambito che si e' affrontato e
sistematizzato il tema della gestione.
3
Performance management
• Definizione e verifica degli obiettivi di QOS (Quality Of Service)
(e.g. 99.999% di disponibilita' dei circuiti o secondi errorati nelle reti SDH)
• Attivazione di punti di misurazione della QOS
• Misurazione, accumulo ed elaborazione dei dati di performance
• Raccolta centralizzata dei dati e loro archiviazione
Ma anche
• Analisi (tipico delle reti commutate) e previsione del traffico
• Valutazione delle prestazioni della rete
Scopi
• Verifica del Service Level Agreement (SLA)
(traffico protetto, non-protetto, occasionale nelle reti SDH)
• (Ri)configurazione rete per ottimizzazione
• Pianificazione evoluzione
4
Performance management
I parametri misurati dipendono
• dalla tecnologia della rete (SDH vs. internet)
• dal layer della rete che si considera (fisico vs. trasporto)
Esempi
• OTN, SDH, PDH:
• tasso di errore, secondi errorati (contatori ES, SeverelyES),
mancata disponibilita' del segnale (contatore UAS),
• potenza TX/RX di un laser, rapporto segnale/rumore
• Rete di calcolatori:
• livello di utilizzazione delle risorse, errori, throughput, round-trip
delay
• collisioni, pacchetti scartati, unicast vs. broadcast
5
Fault management
• Definizione degli obiettivi di robustezza e disponibilita'
• Funzioni:
• sorveglianza,
• correlazione
• locale al singolo apparato (per evitare di considerare come
fault gli effetti secondari del guasto: e.g. se disconnetto il mio
attacco Ethernet cadono le mie connessioni TCP),
• sulla rete (e.g. se si interrompe un data link anche nodi non
direttamente connessi possono rimanere isolati),
• relativamente ai servizi finali,
• filtraggio (e.g. filtraggio nel tempo di allarmi fluttuanti)
• log,
• notifica degli allarmi (a livelli superiori di gestione)
• Testing (diagnosi preventiva)
6
Fault management - reazione al guasto
• Trouble administration, ovvero gestione del ciclo di vita di un allarme
e della sua storia:
• presa in carico dell'allarme
• ocalizzazione del guasto,
• isolamento del guasto(per ripristinare comunque, se possibile, il
servizio)
• rimozione del guasto
Guasto:
• Non conformita' tra la configurazione reale della rete e la
configurazione progettata (e.g. errore di equipaggiamento)
• Funzionamento non corretto (e.g. mancanza di segnale in ricezione
o LOS)
• Quantita' eccessiva di errori (e.g. EBER o excessive bit error rate)
7
Fault management: requisiti d'utente
• SLA definisce obiettivi di robustezza e disponibilita'
• Possono essere tollerate interruzioni del servizio ma
• L'indisponibilita' deve essere rilevata e notificata al piu'
presto
• La durata dell'indisponibilita' deve essere verificabile
• L'indisponibilita' deve essere contabilizzata
• Il ripristino del normale servizio deve essere rilevato e
notificato al piu' presto
• Le possibili conseguenze di un guasto e dei conseguenti
interventi di manutenzione devono essere notificati
e.g. Se e' configurato uno schema di protezione 1:N e si
guasta la risorsa J occorre informare gli utenti di tutte le risorse
K!=J che non godono piu' di protezione
8
Fault management: gestione guasto su apparato SDH
F1
defect
F2
Consequent action
(isolamento guasto)
F3: correlazione
fault
F4: integrazione
F5: severity assignment alarm
Event Forwarding Discriminator
Log
In Current
Problems List
Alarm notification
Alarm log
9
Fault management
esempio SDH
Defect = LOS su linea protetta MSP
• Defect correlati: RS LOF, MS AIS
• F2  autoswitch protezione MSP, inserzione AIS a valle
• F3  soppressione dei defect correlati: RS LOF, MS AIS
• F4  attesa permanenza SPI LOS per 0.5 sec
• F5  assegnazione a SPI LOS severita' minor (linea protetta!)
• EFD  condizioni di generazione notifica verso sistema di gestione
• LOG  condizioni di registrazione evento
10
Time stamping
• la marca temporale di un avvenimento e’ una delle chiavi principali
di concatenazione con gli altri avvenimenti che capitano in rete
• ovviamente, perche’ una marca temporale sia significativa, occorre
che
• tutti gli apparati marchino la stessa cosa (defect, fault, allarme,
notifica: preferibilmente il defect, per evitare ritardi differenziati)
• gli orologi di tutti gli apparati siano sincronizzati tra loro (con una
precisione garantita)
 Deve essere l’applicazione di gestione a mantenere l’allineamento
degli orologi
o deve essere l’infrastruttura di rete che mette a disposizione di tutti
questo servizio?
E.g. attraverso l’uso del protocollo ntp
11
Fault management
esempio internet
L'applicazione remota non risponde al mio programma locale
• E' un malcomportamento dell'applicazione remota?
• L'applicazione remota e' terminata/abortita?
• Il sistema remoto e' congestionato? O e' restartato?
• L'interfaccia di rete del sistema remoto e' guasta?
• L'interfaccia di rete del sistema remoto e' disconnessa?
• Un router lungo il path dal sistema locale al sistema remoto e'
guasto? O e' congestionato?
• Una sottorete lungo il path dal sistema locale al sistema remoto e'
guasta? O e' congestionata?
• …
12
Configuration management
• Pianificazione della rete
• Pianificazione dei link: e.g. dimensionamento
• Pianificazione degli apparati: e.g. localizzazione, tipologia ed
equipaggiamento
• Installazione
• Configurazione e inventariazione dell'apparato
• Download ( e attivazione, e restart, …) del SW
• Pianificazione e negoziazione dei servizi
• Provisioning
• Network connection management delle reti coinvolte nel servizio, e.g.
• path provisioning delle reti permutate
• tabelle statiche di instradamento nelle reti commutate (switched)
• Equipaggiamento e configurazione del traffico sugli apparati
• Inventory
13
Verso l'auto-configurazione della TLC
• c'e' in atto una evoluzione che porta la TLC ad assorbire alcune
funzionalita' della TMN, diventando capace di auto-configurarsi e
auto-riconfigurarsi come reazione a dei fault
• auto-riconoscimento da parte di un apparato delle sue risorse
fisiche e delle loro funzionalita'
• auto-riconoscimento delle adiacenze sulla rete e, tramite opportuni
protocolli di routing, della topologia della rete
• auto-switch dei circuiti in base alle richieste del cliente
 protocolli di segnalazione interni alla rete, e tra rete e cliente
• si passa da una logica di controllo in loop aperto ad una logica di
controllo in loop chiuso
 si perde in buona parte la possibilita’ (ma anche la necessita’) di
avere una diagnostica di non-conformita’ tra configurazione
attesa e configurazione reale
14
Configuration management
esempio Connessione via PSTN ad un provider Internet
PSTN
exchange
Rete di
accesso
modem


Rete di
trasporto
PSTN
exchange
Rete di
accesso
terminal
server
provider
HOST
15
Configuration management
esempio Connessione via PSTN ad un provider Internet
• Pianificazione della rete
•
•
•
•
Dimensionamento del link PSTN - provider
Dimensionamento dei link del provider
Dimensionamento del link provider - backbone
Dimensionamento delle reti trasmissive di accesso e di trasporto
• Negoziazione del servizio
• Risorse a disposizione dell'utente sull'HOST c/o IP provider
• Regola di tariffazione per chiamate verso provider
• Regola di ribaltamento del ricavo verso provider
• Reti coinvolte
• Rete trasmissiva di accesso (e.g. PDH)
• PSTN
• Rete trasmissiva di trasporto (e.g. SDH, OTN)
• Provisioning
• Configurazione utente e risorse su HOST del provider IP
• Configurazione dei path sulle reti trasmissive
16
Accounting management
 Non si tratta solo di tariffazione, ma anche di traffic engineering:
• Attribuire o negare l'accesso alle risorse
• Monitorare (e tenere traccia del) l'utilizzo delle risorse da parte
dell'utente
• limitare l'uso di risorse a quanto contrattato
• verificare che l'utente non sprechi risorse
• Confrontare l'utilizzo che l'utente fa delle risorse con quanto
previsto dal SLA e con la politica di tariffazione concordata
• utilizzo del parametro di QoS (priorita') nello scambio di
informazioni sulla rete
 E' anche un servizio per l'utente
17
Security management
• Prevention (crittografia, autenticazione, firewalls)
• Detection (tentativi di effrazione, identificazione)
• Containment and recovery
• Administration
• Gestione delle chiavi di crittografia
• Gestione degli utenti e delle password
• Monitoring e log degli accessi
Requisiti di sicurezza
•
Segretezza: l'informazione su un sistema deve essere disponibile solo per
chi ne ha diritto
•
Integrita': la configurazione di un sistema deve essere controllabile solo da
chi ne ha diritto
•
Disponibilita': chi ne ha diritto deve poter avere accesso alle risorse di un
sistema
18
Security management
• (si dice che) La mancanza di una gestione della security e' cio' che
ha limitato il supporto del provisioning remoto nella gestione di
Internet
• I problemi di security nella gestione remota delle reti TLC sono di
norma risolti attraverso l'utilizzo di reti di gestione fisicamente
separate
• Inizia comunque a farsi significativa la richiesta di un supporto di
qualche livello di security nelle reti di gestione
(e.g. uso di password nel log-in remoto sugli apparati TLC)
19
ITU Telecommunications Management Network
• Problema: esistono reti di TLC di diversa tecnologia e che offrono
diversi tipi di servizi.
• Come fare a gestirle in modo uniforme ed integrato?
• In particolare (piu' modestamente) come e' possibile una
gestione uniforme di apparati di costruttori diversi (per uno
stesso tipo di tecnologia)?
• Risposta: si definiscono le caratteristiche funzionali ed architetturali
di una Rete di Gestione (Management Network) capace di farlo
• Rete di Gestione: rete di calcolatori, i cui nodi sono capaci di
controllare/monitorare i nodi della rete TLC
• Rete di Gestione vs. Rete Gestita
• Sovrapposizione delle due nel caso di rete di calcolatori
• Parziale condivisione dei portanti e dei nodi nel caso delle reti TLC
vere e proprie
• Rete di Gestione  applicazione distribuita di gestione
20
Logica dell'approccio
1
• Io, gestore di un servizio di TLC, ho una rete fatta di tanti apparati.
• Non riesco a fare soldi con questa rete se non gestendola
adeguatamente, facilmente e uniformemente
• Se tu, manifatturiera, vuoi vendermi un tuo apparato per inserirlo
nella mia rete
• non mi basta che esso interoperi con gli altri apparati a livello
TLC
• voglio che interoperi anche con il sistema di gestione della rete
• voglio cioe' che supporti la (si inserisca senza sforzo nella)
architettura (standard) di gestione
• questa architettura
• moduli
• protocolli
• interfacce
e' pubblica e standard. Se tu la supporti, l'insrimento del tuo
apparato nella TMN sara' plug&play
21
Logica dell'approccio
2
• Io, manifatturiera, so che se supportero' le architetture (e quindi le
interfacce e i protocolli) standard TLC e TMN potro' vendere i miei
prodotti a qualunque network operator.
• Sviluppare i miei prodotti mi costera' anche molto meno, perche'
potro' basarmi su degli strumenti e su delle tecnologie SW standard
• di alta qualita'
• di basso costo
• note a tutti
• ai miei dipendenti
• ai dipendenti dei miei clienti
 Da cio' discende che la disponibilita' di tecnologie e strumenti SW
adeguati a supportare l'architettura costituisce un aspetto
essenziale dell'approccio
22
ITU Telecommunications Management Network
TMN
Operations
System
Operations
System
Operations
System
Data Communication Network
Exchange Tx system Exchange Tx system Exchange
TLC
23
ITU Telecommunications Management Network
Standard relativi alla TMN:
• M.3000: Overview of TMN Recommendations
• M.3010: Principles for a TMN
• M.3020: TMN Interface Specification Methodology
• M.3200: TMN Management Service Introduction
• M.3400: TMN Management Functions
• X.700: Management Framework
• X.701: System Management Overview
• X.720: Management Information Model
• X.722: Guidelines for the Definition of Managed Objects (GDMO)
• X.721: Definition of Management Information
• X.73x: System Management Application Service Element
• M.3100: Generic Network Information Model
24
ITU Telecommunications Management Network
Standard utilizzati dalla TMN:
• X.2xx: Open Systems Interconnection (OSI)
La management Network e' implementata come una rete OSI di
calcolatori. In particolare vedi:
• X.208/ISO 8824: Specification of Abstract Syntax Notation One
(ASN.1)
• X.209/ISO 8825: Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1)
• X.219/ISO 9072-1: Remote Operations: Model Notation and
Service Definition
• X.229/ISO 9072-2: Remote Operations: Protocol Specification
• X.710: Common Management Information Service (CMISE)
Definition
• X.711: Common Management Information Protocol
(CMIP)Specification
25
TMN - Livelli di Gestione
Business Management
Service Management
Network Management
Element Management
Network Element
(o Managed Element:
apparati)
26
TMN - Livelli di Gestione
Business management
• Raccolta dati di mercato ed elaborazione delle strategie
• Gestione dei contratti di serivizio
• Qualita' globale (e.g. definizione dei Service Level Agreement)
• …
Service management
• Gestione del ciclo di vita dei servizi
• Set-up, disponibilita', qualita', dati di utilizzo, fatturazione, …
 Gestione dei servizi finali e conseguente gestione integrata dei
servizi delle diverse reti che contribuiscono alla loro realizzazione
27
TMN - Livelli di Gestione
Network (level) management
 Gestione degli apparati in quanto interconnessi in rete, con
capacita' di gestione del traffico end-to-end
 Gerarchia di network manager
 Per area geografica (nazionale vs. regionale)
 Per tecnologia (OTN vs. SDH)
• Pianificazione dell'infrastruttura di rete
• Gestione del traffico
• Provisioning
• Localizzazione dei guasti primari
• Ribaltamento/correlazione degli allarmi sui circuiti end-to-end
(per una stessa tecnologia vs. tra differenti tecnologie)
• Performance monitoring di un circuito end-to-end
28
RETI E TECNOLOGIE DI RETE
• Molto spesso una rete e’ implementata da una singola tecnologia
• e un tipo di rete utilizza un altro tipo di rete come (sostitutivo/
integrativo del) proprio livello fisico
• esistono pero’ eccezioni, e la situazione si modifica nel tempo
• le grandi autostrade della rete di trasporto sono attualmente
realizzate da reti SDH eventualmente integrate da reti OTN
• anche le reti di trasporto regionale sono realizzate in tecnologia
SDH
• SDH e’ presente anche nella rete di accesso
29
Architettura e tecnologie di rete
IP
PDH
(Plesiochronous
Digital Hierarchy)
ATM
(Asynchronous
Transfer Mode)
SDH
(Synchronous Digital Hierarchy)
OTN
(Optical Tranport Network)
30
TMN - Livelli di Gestione
Element management
 Gestione individuale dei singoli apparati
 Diversi EM connettibili al singolo apparato (gestione loro interazione)
 EM territoriale (centralizzato, multi-operatore, multi-NE) vs.
 craft interface terminal (locale, mono-operatore, mono-NE)
• Gestione equipaggiamento e protezioni
• Inventory
• Realizzazione locale delle funzioni di rete, e.g.
• Configurazione locale del traffico
• Raccolta e correlazione locale dei fault
• Abilitazione del monitoraggio e raccolta dei dati di performance
31
Principi della soluzione di gestioneTMN
• La gestione degli apparati e' basata sulle loro funzionalita' e non
sulla loro architettura
• La rete gestita viene modellata funzionalmente
(secondo lo stile del modello di riferimento OSI)
• Architettura funzionale layerizzata
• Protocol Entity vs. Service Access Point
• Ogni blocco funzionale della rete viene modellato come una classe
secondo uno stile di programmazione Object-Oriented
• L'interfaccia sintattica/semantica delle classi viene definita
formalmente utilizzando strumenti (dedicati) di programmazione
distribuita
 si ha una coincidenza tra linguaggio di specifica e linguaggio di
implementazione!
32
Architettura funzionale layerizzata - rete OSI
•
7 layer
1. Physical Layer: trasmissione di bit tra nodi adiacenti
2. Data Link Layer: framing ed error detection. Trasmissione di
frame tra nodi adiacenti
3. Network Layer: trasmissione di byte (datagram) end-to-end
(tra End-System)
4. Transport Layer: trasmissione (affidabile o meno) di byte
end-to-end (tra processi di elaborazione)
5. Session Layer: ?
6. Presentation Layer: trasmissione affidabile di informazione
end-to-end
7. Application Layer: servizi applicativi (e.g. RPC)
•
Client layer
33
Architettura funzionale layerizzata - rete SDH
•
5 layer
34
Architettura implementativa e architettura funzionale
• supponiamo di dovere realizzare un apparato che supporta N porte
SDH
• una possibilita’ e’ di realizzare n schede, ciascuna capace di
supportare tutti i layer funzionali dell’SDH per N/n porte
• una possibilita’ alternativa e’ di realizzare n1+n2 schede,
• le prime n1 che implementano il layer fisico, ciascuna per N/n1
porte
• le seconde n2 che implementano gli altri layer funzionali,
ciascuna per N/n2 porte
• l’architettura implementativa dei due apparati e’ molto diversa, ma la
loro architettura funzionale rimane identica
• posso quindi gestire entrambi gli apparati utilizzando il medesimo
modello funzionale
35
Architettura funzionale layerizzata di rete
Modellazione ITU di un layer (G.805)
36
Architettura funzionale layerizzata di rete
Modellazione di un layer
OSI Protocol Entity

ITU Trail Termination Point (TTP)
OSI SAP

ITU Connection Termination Point
(CTP)
Inoltre
•
relazione tra un TTP e i CTP attraverso i quali esso offre i suoi
servizi
•
relazione tra un layer e l'altro (tra un TTP e il/i CTP attraverso cui
esso accede ai servizi del layer sottostante)
•
funzione di connettivita' (switching o permutazione)
•
rapporto tra modello funzionale e architettura implementativa
37
Esempio:
Higher order pass-through cross-connection
in un apparato SDH
38
Strumenti OSI per la programmazione distribuita
Linguaggi
• RO-notation
• Definizione dei prototipi delle RPC (Remote Procedure Call,
procedure remote) utilizzate per l'interazione tra i moduli
dell'applicazione distribuita
• Definizione della struttura dell'applicazione distribuita
• ASN.1
• Definizione della struttura dell'informazione scambiata tra i
moduli dell'applicazione distribuita
• E.g.: definizione del tipo dei parametri di input/output delle RPC
 RO-notation si basa su ASN.1
39
Applicazione distribuita di gestione
Linguaggi
• GDMO
• Definizione delle classi che modellano la rete gestita o che servono a
supportare l'applicazione di gestione (modello informativo)
• Definizione formale dell'interfaccia sintattica
• Definizione della semantica in linguaggio naturale
• RO-notation
• Definizione dei prototipi delle RPC utilizzate per implementare i metodi
delle classi definite nel modello informativo (protocollo CMIP)
• ASN.1
• Rappresentazione dello stato (variabili di classe) delle classi definite
nel modello informativo
 GDMO si basa su ASN.1
40
Architettura dell'applicazione distribuita di gestione
manager
sistemi di
gestione
Data Communication Network
sistemi
gestiti
agent
41
Architettura dell'applicazione distribuita di gestione
•
In una rete di gestione manager (su sistemi di gestione) e agent
(su sistemi gestiti) sono collegati da una rete di comunicazione tra
calcolatori (DCN)
•
ci troviamo di fronte ad una applicazione distribuita in cui un
modulo sw puo’ giocare due diversi ruoli
• Manager
• Agent
•
Naturalmente, nell'architettura layerizzata TMN ogni sistema di
gestione puo' giocare un doppio ruolo (dual-role entity):
• Agent rispetto ad un sistema di gestione di gerarchia
superiore
• Manager rispetto ad un sistema di gestione di gerarchia
inferiore o ad un NE
42
Manager, Agent, MIB, Managed Objects
sistema di gestione
manager
sistema gestito
operazioni
agent
(su oggetti
nella MIB)
notifiche
MIB
•
managed
object
risorse
reali
MIB (Management Information Base)
•
•
•
rappresentazione logica delle risorse gestite
(indipendente dalla struttura delle risorse reali, e.g. ASIC)
come albero di managed object
ogni managed object essendo una istanza di una classe definita nel
modello informativo
43
MANAGER
Funzione realizzata da un sistema di gestione che deve
•
interfacciarsi con gli agent gestendo i protocolli di comunicazione
(ma questo non e' solo uno strumento per fare il proprio vero mestiere?
quello descritto di seguito?!)
1. mantenere una visione globale e coordinata dell'insieme dei sistemi
gestiti, garantendo quindi che la propria conoscenza dello stato di
ciascun apparato sia allineata con lo stato descritto nella MIB
dell’agent corrispondente
2. interfacciarsi con l'operatore umano
3. supportare le funzioni applicative che consentono di agire sui
sistemi gestiti
4. interagire con gli altri manager della rete di gestione
44
AGENT
Funzione realizzata da un apparato che deve
•
interfacciarsi con i manager gestendo i protocolli di comunicazione
(ma questo non e' solo uno strumento per fare il proprio vero mestiere?
quello descritto di seguito?!)
1. mantenere coerenza tra lo stato reale del sistema gestito e la sua
rappresentazione astratta nella MIB
2. eseguire sugli oggetti gestiti ed eventualmente sulle corrispondenti
risorse reali le azioni richieste dal manager
3. notificare al manager particolari cambiamenti di stato sugli oggetti
gestiti che riflettono variazioni (in particolare variazioni spontanee)
dello stato delle risorse reali corrispondenti (e.g. allarmi)
45
OPERAZIONI DI GESTIONE
• operazioni invocate dal manager: alternative
1.operazioni specifiche della classe dell'oggetto gestito, e.g.:
 interfnum.activate()
2.operazioni generiche per operare su strutture dati, applicabili a
tutte le classi, e.g.:
 interfnum.set(status, active)
• la prima alternativa e' quella fisiologica in un ambiente O-O
• la seconda alternativa e' quella scelta da ITU
• concentra le specificita' del sistema (la sua modellazione) nella
MIB (negli attributi dei managed object, che devono essere
pubblici!)
• garantisce che lo stato dell’apparato sia completamente esplicito
• tutte le classi condividono lo stesso insieme predefinito (da
CMISE/CMIP) di metodi, seppure disciplinati in forma diversa
metodi fondamentali: M-GET (lettura), M-SET (scrittura)
• la prima alternativa rimane in forma relativamente marginale nelle
operazioni M-ACTION e M-EVENT-REPORT
46
OPERAZIONI DI GESTIONE
Trasferimento di informazioni al manager: alternative
1. polling dei sistemi gestiti da parte del manager per raccogliere
l'informazione di una loro variazione spontanea di stato
2. invio al manager da parte dell'agent di una generica notifica di
variazione spontanea dello stato del sistema gestito:
per avere l'informazione di dettaglio il manager deve interrogare
l'agent (trap-directed polling)
3. invio al manager da parte dell'agent di una notifica specifica e
dettagliata a seguito della variazione spontanea dello stato del
sistema gestito

Alternativa scelta da ITU: 3

Necessita' conseguente (come anche per soluzione 2) di registrare
sull'agent l'identita' dei manager interessati ad eventi spontanei, e a
quali tipi di eventi spontanei ciascun manager e' interessato
47
CONTROLLO DELLE NOTIFICHE NELLA TMN
Da X.721. Vedi anche pagine seguenti
discriminator MANAGED OBJECT CLASS
DERIVED FROM
top;
CHARACTERIZED BY
discriminatorPackage PACKAGE
BEHAVIOUR
discriminatorBehaviour BEHAVIOUR
DEFINED AS "This managed object is used to represent the criteria for
controlling management services. The semantics of the managed
object class, namely its attributes and behaviour are described
in CCITT Rec. X.734 | ISO/IEC 10164-5. ";;
ATTRIBUTES
discriminatorId
discriminatorConstruct
administrativeState
operationalState
GET,
REPLACE-WITH-DEFAULT
DEFAULT VALUE
Attribute-ASN1Module.
defaultDiscriminatorConstruct
GET-REPLACE,
GET-REPLACE,
GET;
48
CONTROLLO DELLE NOTIFICHE NELLA TMN
continua
NOTIFICATIONS
stateChange,
attributeValueChange,
objectCreation,
objectDeletion;;;
-- the semantics of the above events are defined in CCITT Rec.
-- X.731 | ISO/IEC10164- 2, CCITT Rec. X.730 | ISO/IEC10164-1
CONDITIONAL PACKAGES
availabilityStatusPackage PRESENT IF
"any of the scheduling packages, ( duration, weekly scheduling, external) are
present",
duration
PRESENT IF
"the discriminator function is scheduled to start at a specified time and
stop at either a specified time or function continuously ",
dailyScheduling
PRESENT IF
"both the weekly scheduling package and external scheduler packages are
not present in an instance and daily scheduling is supported by that instance",
49
CONTROLLO DELLE NOTIFICHE NELLA TMN
continua
weeklyScheduling
PRESENT IF
"both the daily scheduling package and external scheduler packages are not
present in an instance and weekly scheduling is supported by that instance",
externalScheduler
PRESENT IF
"both the daily scheduling package and weekly scheduling packages are not
present in an instance and external scheduling is supported by that instance";
-- see CCITT Rec. X.734 | ISO/IEC 10164-5 for the description of this
-- managed object class.
REGISTERED AS
{smi2MObjectClass 3};
50
CONTROLLO DELLE NOTIFICHE NELLA TMN
continua
eventForwardingDiscriminator MANAGED OBJECT CLASS
DERIVED FROM
discriminator;
CHARACTERIZED BY
-- The value for the administrative state if not specified at initiation defaults
-- to the value unlocked.
efdPackage PACKAGE
BEHAVIOUR
eventForwardingDiscriminatorBehaviour BEHAVIOUR
DEFINED AS "This managed object is used to represent the criteria that
shall be satisfied by potential event reports before the event report is
forwarded to a particular destination. The semantics of the managed
object class, namely its attributes, management operations and
behaviour, are described in CCITT Rec. X. 734 | ISO/IEC 10164-5. ";;
ATTRIBUTES
destination GET-REPLACE;;;
-- discriminatorConstruct attribute is defined using the attributes of
-- a potential event report object
-- described in CCITT Rec. X.734 | ISO/IEC 10164-5.
51
CONTROLLO DELLE NOTIFICHE NELLA TMN
continua
CONDITIONAL PACKAGES
backUpDestinationListPackage PACKAGE
ATTRIBUTES
activeDestination
GET,
backUpDestinationList
GET-REPLACE;
REGISTERED AS
{smi2Package 9} ;
PRESENT IF "the event forwarding discriminator is required to provide
a backup for the destination",
modePackage
PACKAGE
ATTRIBUTES
confirmedMode GET;
REGISTERED AS
{smi2Package 10};
PRESENT IF "the event forwarding discriminator permits mode for reporting
events to be specified by the managing system";
REGISTERED AS
{smi2MObjectClass 4};
52
CONTROLLO DELLE NOTIFICHE NELLA TMN
continua
--The semantics of the discriminatorConstruct attribute type are specified in
-- the Discriminator Construct attribute in CCITT Rec. X.734 | ISO/IEC 10164-5.
discriminatorConstructATTRIBUTE
WITH ATTRIBUTE SYNTAX Attribute-ASN1Module.
DiscriminatorConstruct;
REGISTERED AS
{smi2AttributeID 56};
-- The semantics of the destination attribute type are specified in the Destination
-- Address attribute in CCITT Rec. X.734 | ISO/IEC 10164-5.
destination ATTRIBUTE
WITH ATTRIBUTE SYNTAX
Attribute-ASN1Module.Destination;
MATCHES FOR EQUALITY;
REGISTERED AS
{smi2AttributeID 55};
53
CONTROLLO DELLE NOTIFICHE NELLA TMN
continua
Destination ::= CHOICE {
single
AE-title,
multiple
SET OF AE-title}
DiscriminatorConstruct ::= CMISFilter
54
CONTROLLO DELLE NOTIFICHE NELLA TMN
Continua (da X.711, definizione di CMIP)
CMISFilter
item
and
or
not
}
::= CHOICE {
[8] FilterItem,
[9] IMPLICIT SET OF CMISFilter,
[10] IMPLICIT SET OF CMISFilter,
[11] CMISFilter
Attribute
::= SEQUENCE {
attributeId
AttributeId,
attributeValue
ANY DEFINED BY
}
attributeId
55
CONTROLLO DELLE NOTIFICHE NELLA TMN
Continua (da X.711, definizione di CMIP)
FilterItem
equality
substrings
initialString
anyString
finalString
::= CHOICE {
[0] IMPLICIT Attribute,
[1] IMPLICIT SEQUENCE OF CHOICE {
[0] IMPLICIT SEQUENCE {
attributeId
AttributeId,
string
ANY DEFINED BY attributeId },
[1] IMPLICIT SEQUENCE {
attributeId
AttributeId,
string
ANY DEFINED BY attributeId },
[2] IMPLICIT SEQUENCE {
attributeId
AttributeId,
string
ANY DEFINED BY attributeId}
},
greaterOrEqual [2] IMPLICIT Attribute, -- asserted value >= attribute value
lessOrEqual
[3] IMPLICIT Attribute, -- asserted value <= attribute value
present
[4] AttributeId,
subsetOf
[5] IMPLICIT Attribute, -- asserted value  attribute value
supersetOf
[6] IMPLICIT Attribute, -- asserted value  attribute value
nonNullSetIntersection
[7] IMPLICIT Attribute
}
56
OPERAZIONI DI GESTIONE
MIB traversal
1. Quando un manager si connette con un agent non conosce
•
quanti e quali sono e
•
di che tipo sono
gli oggetti presenti nella sua MIB
2. Il protocollo di gestione deve quindi consentire al manager di
acquisire da zero la configurazione dell'apparato gestito,
3. senza conoscere a priori niente di questo se non il modello
informativo che lo descrive.
57