1 LABORATORIO DI INFORMATICA Network Management 1. Introduzione: Network Management e ITU TMN Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER.

Presentazione sul tema: "1 LABORATORIO DI INFORMATICA Network Management 1. Introduzione: Network Management e ITU TMN Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER."— Transcript della presentazione:

1 1 LABORATORIO DI INFORMATICA Network Management 1. Introduzione: Network Management e ITU TMN Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2 2 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, …

3 3 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.

4 4 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

5 5 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

6 6 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)

7 7 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)

8 8 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

9 9 In Current Problems List Alarm notification Fault management: gestione guasto su apparato SDH F1F2 defectConsequent action (isolamento guasto) F3: correlazione fault F4: integrazione F5: severity assignment alarm Event Forwarding Discriminator Alarm log Log

10 10 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

11 11 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 lapplicazione di gestione a mantenere lallineamento degli orologi o deve essere linfrastruttura di rete che mette a disposizione di tutti questo servizio? E.g. attraverso luso del protocollo ntp

12 12 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? …

13 13 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

14 14 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

15 15 Configuration management esempio Connessione via PSTN ad un provider Internet modem Rete di accesso PSTN exchange Rete di trasporto PSTN exchange Rete di accesso terminal server provider HOST

16 16 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

17 17 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

18 18 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

19 19 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)

20 20 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

21 21 Logica dell'approccio1 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

22 22 Logica dell'approccio2 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

23 23 ITU Telecommunications Management Network

24 24 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

25 25 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

26 26 TMN - Livelli di Gestione Business Management Network Management Service Management Element Management Network Element (o Managed Element: apparati)

27 27 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

28 28 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

29 29 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

30 30 Architettura e tecnologie di rete OTN (Optical Tranport Network) SDH (Synchronous Digital Hierarchy) PDH (Plesiochronous Digital Hierarchy) ATM (Asynchronous Transfer Mode) IP

31 31 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

32 32 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!

33 33 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

34 34 Architettura funzionale layerizzata - rete SDH 5 layer

35 35 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 dellSDH 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 larchitettura 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

36 36 Architettura funzionale layerizzata di rete Modellazione ITU di un layer (G.805)

37 37 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

38 38 Esempio: Higher order pass-through cross-connection in un apparato SDH

39 39 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

40 40 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

41 41 Architettura dell'applicazione distribuita di gestione

42 42 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

43 43 Manager, Agent, MIB, Managed Objects 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

44 44 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 dellagent 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

45 45 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)

46 46 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 dellapparato 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

47 47 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

48 48 CONTROLLO DELLE NOTIFICHE NELLA TMN Da X.721. Vedi anche pagine seguenti discriminatorMANAGED OBJECT CLASS DERIVED FROM top; CHARACTERIZED BY discriminatorPackagePACKAGE BEHAVIOURdiscriminatorBehaviour 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 discriminatorIdGET, discriminatorConstructREPLACE-WITH-DEFAULT DEFAULT VALUE Attribute-ASN1Module. defaultDiscriminatorConstruct GET-REPLACE, administrativeStateGET-REPLACE, operationalStateGET;

49 49 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 availabilityStatusPackagePRESENT IF "any of the scheduling packages, ( duration, weekly scheduling, external) are present", durationPRESENT IF "the discriminator function is scheduled to start at a specified time and stop at either a specified time or function continuously ", dailySchedulingPRESENT IF "both the weekly scheduling package and external scheduler packages are not present in an instance and daily scheduling is supported by that instance",

50 50 CONTROLLO DELLE NOTIFICHE NELLA TMN continua weeklySchedulingPRESENT IF "both the daily scheduling package and external scheduler packages are not present in an instance and weekly scheduling is supported by that instance", externalSchedulerPRESENT 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};

51 51 CONTROLLO DELLE NOTIFICHE NELLA TMN continua eventForwardingDiscriminatorMANAGED OBJECT CLASS DERIVED FROMdiscriminator; CHARACTERIZED BY -- The value for the administrative state if not specified at initiation defaults -- to the value unlocked. efdPackagePACKAGE BEHAVIOUR eventForwardingDiscriminatorBehaviourBEHAVIOUR 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 destinationGET-REPLACE;;; -- discriminatorConstruct attribute is defined using the attributes of -- a potential event report object -- described in CCITT Rec. X.734 | ISO/IEC 10164-5.

52 52 CONTROLLO DELLE NOTIFICHE NELLA TMN continua CONDITIONAL PACKAGES backUpDestinationListPackagePACKAGE ATTRIBUTES activeDestinationGET, backUpDestinationListGET-REPLACE; REGISTERED AS{smi2Package 9} ; PRESENT IF "the event forwarding discriminator is required to provide a backup for the destination", modePackagePACKAGE ATTRIBUTES confirmedModeGET; 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};

53 53 CONTROLLO DELLE NOTIFICHE NELLA TMN continua --The semantics of the discriminator­Construct attribute type are specified in -- the Discriminator Construct attribute in CCITT Rec. X.734 | ISO/IEC 10164-5. discriminatorConstructATTRIBUTE WITH ATTRIBUTE SYNTAXAttribute-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. destinationATTRIBUTE WITH ATTRIBUTE SYNTAXAttribute-ASN1Module.Destination; MATCHES FOR EQUALITY; REGISTERED AS{smi2AttributeID 55};

54 54 CONTROLLO DELLE NOTIFICHE NELLA TMN continua Destination ::= CHOICE { singleAE-title, multipleSET OF AE-title} DiscriminatorConstruct ::= CMISFilter

55 55 CONTROLLO DELLE NOTIFICHE NELLA TMN Continua (da X.711, definizione di CMIP) CMISFilter::= CHOICE { item[8] FilterItem, and[9] IMPLICIT SET OF CMISFilter, or[10] IMPLICIT SET OF CMISFilter, not[11] CMISFilter } Attribute::= SEQUENCE { attributeIdAttributeId, attributeValueANY DEFINED BYattributeId }

56 56 CONTROLLO DELLE NOTIFICHE NELLA TMN Continua (da X.711, definizione di CMIP) FilterItem::= CHOICE { equality[0] IMPLICIT Attribute, substrings[1] IMPLICIT SEQUENCE OF CHOICE { initialString[0] IMPLICIT SEQUENCE { attributeIdAttributeId, stringANY DEFINED BY attributeId }, anyString[1] IMPLICIT SEQUENCE { attributeIdAttributeId, stringANY DEFINED BY attributeId }, finalString[2] IMPLICIT SEQUENCE { attributeIdAttributeId, stringANY 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 }

57 57 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.