1 LABORATORIO DI INFORMATICA Network Management 1. Introduzione: Network Management e ITU TMN...

1

LABORATORIO DI INFORMATICANetwork 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

GESTIONEInsieme 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

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

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

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

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

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

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

In Current Problems List

Alarm notification

Fault management: gestione guasto su apparato SDH

F1 F2defect Consequent action

(isolamento guasto)

F3: correlazione fault F4: integrazione

F5: severity assignment alarm

Event Forwarding Discriminator

Alarm logLog

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

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

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

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

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

Configuration management

esempio Connessione via PSTN ad un provider Internet

modem

Rete di accesso

PSTN

exchange

Rete di trasporto

PSTN

exchangeRete di accesso

terminal

server

provider

HOST

16

Configuration managementesempio 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

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

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

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

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

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

22

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

23

OperationsSystem

OperationsSystem

OperationsSystem

Data Communication Network

ExchangeTx systemExchange Tx system Exchange

TLC

TMN

ITU Telecommunications Management Network

24

ITU Telecommunications Management NetworkStandard 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

ITU Telecommunications Management NetworkStandard 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

TMN - Livelli di Gestione

Business Management

Network Management

Service Management

Element Management

Network Element(o Managed Element:apparati)

27


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


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

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

Architettura e tecnologie di rete

OTN(Optical Tranport Network)

SDH(Synchronous Digital Hierarchy)

PDH(PlesiochronousDigital Hierarchy)

ATM(Asynchronous Transfer Mode)

IP

31


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

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

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

Architettura funzionale layerizzata - rete SDH

• 5 layer

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

36

Architettura funzionale layerizzata di rete

Modellazione ITU di un layer (G.805)

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

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

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

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

Data Communication Network

sistemi

gestiti

agent

sistemi di

gestione

manager

Architettura dell'applicazione distribuita di gestione

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

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

manager agent

sistema di gestione sistema gestito

MIBmanagedobject

risorsereali

notifiche

operazioni

(su oggettinella MIB)

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

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

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

47


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

CONTROLLO DELLE NOTIFICHE NELLA TMNDa X.721. Vedi anche pagine seguenti

discriminator MANAGED OBJECT CLASS DERIVED FROM top; CHARACTERIZED BY

discriminatorPackage PACKAGEBEHAVIOUR 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. ";;

ATTRIBUTESdiscriminatorId GET,discriminatorConstruct REPLACE-WITH-DEFAULT

DEFAULT VALUEAttribute-ASN1Module.defaultDiscriminatorConstruct

GET-REPLACE,administrativeState GET-REPLACE,operationalState GET;

49

CONTROLLO DELLE NOTIFICHE NELLA TMNcontinua

NOTIFICATIONSstateChange,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 PACKAGESavailabilityStatusPackage 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",

50


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",

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};

51


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

BEHAVIOUReventForwardingDiscriminatorBehaviour BEHAVIOURDEFINED AS "This managed object is used to represent the criteria thatshall be satisfied by potential event reports before the event report is forwarded to a particular destination. The semantics of the managedobject class, namely its attributes, management operations and behaviour, are described in CCITT Rec. X. 734 | ISO/IEC 10164-5. ";;

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

52


CONDITIONAL PACKAGESbackUpDestinationListPackage PACKAGE

ATTRIBUTESactiveDestination 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

ATTRIBUTESconfirmedMode 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};

53


--The semantics of the discriminator Construct attribute type are specified in -- the Discriminator Construct attribute in CCITT Rec. X.734 | ISO/IEC 10164-5.

discriminatorConstructATTRIBUTEWITH 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};

54


Destination ::= CHOICE {

single AE-title,multiple SET OF AE-title}

DiscriminatorConstruct ::= CMISFilter

55

CONTROLLO DELLE NOTIFICHE NELLA TMNContinua (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 {attributeId AttributeId,attributeValue ANY DEFINED BY attributeId}

56

CONTROLLO DELLE NOTIFICHE NELLA TMNContinua (da X.711, definizione di CMIP)

FilterItem ::= CHOICE {equality [0] IMPLICIT Attribute,substrings [1] IMPLICIT SEQUENCE OF CHOICE {

initialString [0] IMPLICIT SEQUENCE {attributeId AttributeId,string ANY DEFINED BY attributeId },

anyString [1] IMPLICIT SEQUENCE {attributeId AttributeId,string ANY DEFINED BY attributeId },

finalString [2] IMPLICIT SEQUENCE {attributeId AttributeId,string ANY DEFINED BY attributeId}

},greaterOrEqual [2] IMPLICIT Attribute, -- asserted value >= attribute valuelessOrEqual [3] IMPLICIT Attribute, -- asserted value <= attribute valuepresent [4] AttributeId,subsetOf [5] IMPLICIT Attribute, -- asserted value attribute valuesupersetOf [6] IMPLICIT Attribute, -- asserted value attribute valuenonNullSetIntersection [7] IMPLICIT Attribute}

57


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.

1 LABORATORIO DI INFORMATICA Network Management 1. Introduzione: Network Management e ITU TMN...

Documents

Transcript of 1 LABORATORIO DI INFORMATICA Network Management 1. Introduzione: Network Management e ITU TMN...