Vous êtes sur la page 1sur 40

ADMINISTRATION DE RESEAUX

INTRODUCTION A LA GESTION DES RESEAUX


INTRODUCTION DEFINITION DISCIPLINES FONCTIONALITES CRITERES D'UNE ORGANISATION LOGIQUE UNE ORGANISATION LOGIQUE CONCLUSION

LA GESTION ISO
RAPPEL SUR LA COUCHE PRESENTATION LES 3 NIVEAUX DE GESTION ASPECT FONCTIONNEL ET FLUX D'INFORMATION CMIS CMIP

LA GESTION SYSTEME ISO


GENERALITES ASPECT INFORMATIONNEL ET FONCTIONNEL ASPECT COMMUNICATION ASPECT ORGANISATIONNEL LES FONCTIONS DE LA GESTION SYSTEME STRUCTURE DES INFORMATIONS DE GESTION DEFINITION DES INFORMATIONS METHODE POUR LA DEFINITION DES OBJETS GERES

LA GESTION SNMP
PLAN INTRODUCTION ARCHITECTURE STRUCTURE INFORMATIONNELLE LE PROTOCOLE SNMP PROPRIETES EXEMPLES D'UTILISATION CMOT ET SNMP2 LES PERFORMANCES

EXEMPLES D'ARCHITECTURE
QUELQUES EXEMPLES

CONCLUSION
1

LEXIQUE BIBLIOGRAPHIE

I - LA GESTION DES RESEAUX


1.INTRODUCTION
Grer = tirer le meilleur parti de la structure que l'on gre, mais inversement le comportement de cette structure dpend de sa gestion. Jusqu' prsent on a fait des progrs normes sur les problmes de communication et d'interconnexion, donnant la possibilit de construire des rseaux de plus en plus complexes. Malheureusement on s'aperoit que l'on n'a rien prvu pour avoir des informations dcrivant le fonctionnement du rseau. C'est comme si on avait construit une F1 et que l'on avait oubli le tableau de bord. Il faut donc aujourd'hui trouver une norme qui dcrivent ces informations, comment elles sont recueillies, traites, stockes... Cela pose de nombreux problmes car il est difficile d'intgrer ces services dans les normes existantes ( notamment dans les 7 couches OSI ). Il y a donc 2 problmes rsoudre:

Intgration dans les rseaux des aspects de gestion Structuration de cette gestion ( et de son interfonctionnement )

2. DEFINITION
En franais administrer c'est :

- reprsenter une organisation. - l'ensemble des services qu'offre cette administration.

En rseau la distinction n'est pas faite. Ainsi sa dfinition pourrait tre:


- offrir aux utilisateurs une qualit de service (aspect externe). - permettre l'volution du systme. | ( aspect interne ) - rendre oprationnel le systme . .|

Remarque : Une administration est lie une politique, une stratgie de l'entreprise. Cette politique entrane une mthodologie par entreprise. Le but de l'administration des rseaux est de rendre toutes les mthodologies possibles. La partie oprationnelle consiste mettre en place l'ensemble des ressources ncessaires cette mthodologie.

3.LES DISCIPLINES
2

Le rseau peut tre dfinit par un environnement constitu de 3 personnes (groupe d'entits ) diffrentes : - les utilisateurs ( consommateurs de services ). - les serveurs ( fournisseurs de services ). - les machines de transport ( reliant utilisateurs et fournisseurs ). 3a) L'administration des utilisateurs Un utilisateur doit :

accder aux diffrentes applications du rseau de manire transparente. accder aux diffrentes ressources. avoir de la confidentialit et de la scurit ( environnement confidentiel sans perte ou altration des donnes ). qualit du service en terme de disponibilit de performance.

3b) L'administration des serveurs Connexion et distribution des applications et des donnes. Un serveur doit permettre des accs son service au plus de personne possible, ainsi que l'accs aux services en fonction de certains droits. 3c) L'administration de la machine de transport

grer les oprations du rseau pour modifier le fonctionnement de celui-ci dtecter les incidents et les rparer. grer les performances ( temps de rponse ). grer les cots d'accs. grer la configuration du rseau. grer l'inventaire ( ensemble des lments du systme ).

4. LES FONCTIONALITES
Pour grer un rseau, il faut savoir grer un ensemble de particularits ( suivant la tactique). Cinq tactiques, aires fonctionnelles, ont t diffrencies.Il s'agit de : Gestion des fautes Gestion des configurations et des noms Gestion des performances Gestion de la comptabilit Gestion de la scurit 4a) La gestion des fautes

Fonction de surveillance : remarquer les pannes sur le rseau, comme par exemple remarquer les trames non sollicites... Localiser les fautes ( pannes ) par recherche dichotomique en utilisant des batteries de tests. Dterminer les pannes : par consultation de journaux.

4b) Gestion des configurations et des noms

Fonction installation : paramtrer un composant, le mettre en service, le retirer du service. Cela permet une mise jour des versions utilises. Fonction contrle et surveillance : surveillance de l'tat des composants. Gestion des noms : pour identifier tous les lments du rseau.

4c) Gestion des performances


Fonction de surveillance : pour collecter les donnes statistiques des performances. Fonction de gestion du trafic : d'aprs les statistiques prcdentes on rgule le trafic sur le systme. Fonction d'observation de qualit de service : exemple : mesurer le temps de rponse la connexion un service...

4d) Gestion de la comptabilit


grer la charge des ressources et donc empcher toute surcharge. grer le cot d'utilisation des ressources et les facturer. grer les quotas d'utilisations des ressources.

4e) Gestion de la scurit


grer la confidentialit : utilisation de cls d'encryptage... audit : surveillance des journaux afin de localiser les tentatives de connexions intempestives. enregistrer et grer les abonns : maintenir et dterminer les droits de connexion aux diffrents services.

5. LES CRITERES POUR UNE ORGANISATION LOGIQUE


L'organisation d'un rseau doit tre dfinie, notamment en utilisant diffrents critres. - le critre informationnel - le critre fonctionnel - le critre temporel - le critre de discipline 5a) le critre informationnel Ensemble des informations servant grer le rseau. Ce sont :

informations en provenance du rseau : elles proviennent des composants du rseau, des tests, des utilisateurs... les informations qui dcrivent le systme : elles sont stockes dans une base de donnes pour la gestion du rseau.

5b) le critre fonctionnel Ensemble des fonctions servant grer le rseau. Il s'agit d'un sous domaine des 5 domaines fonctionnels vus plus haut. 5c) le critre temporel Ensemble des contraintes lies au temps sur des lments de gestion. Elles sont divises en 3 classes : 4

court terme : minute -> journe = contraintes lies aux aspects oprationnels de la gestion. moyen terme : journe -> plusieurs mois = contraintes lies aux aspects d'environnement. long terme : anne = contraintes lies aux aspects volutifs du rseau.

5c) le critre de discipline On ne peut pas dissocier l'administration de rseau et celle des utilisateurs et des services du rseau. Ainsi l'administration de rseau comprend trois disciplines diffrentes

administration des utilisateurs. Cela reprsente une part croissante car les utilisateurs se voient offrir de plus en plus de services. administration des fournisseurs de services: il faut leur donner les moyens de suivre leurs services ( en matire de qualit de service) et donc d'en assurer leurs propres gestions. gestion du systme de communication.

6. L'ORGANISATION LOGIQUE
L'organisation de l'administration d'un rseau doit respecter les 4 critres precdemment cits. L'organisation peut tre envisage en couches ( niveaux hirarchiques ) chacune ayant en charge un critre. - le service de gestion du rseau rel - le service de gestion du rseau logique - le service de gestion des performances - le service de gestion de la planification 6a) le service de gestion du rseau rel C'est l'activit qui gre les donnes en provenance du systme gr, donc c'est une activit court terme. Ce service indispensable consiste :

collecter les donnes. excuter les fonctions de service. prendre en compte les alertes et notifier les vnements. dterminer les problmes. contrler la configuration. activer, dsactiver, redmarrer des lments. effectuer la maintenance technique.

6b) le service de gestion du rseau logique Il s'appuie sur les informations stockes, donc c'est une activit moyen terme et effectue le lien entre la tactique d'administration et les dcisions oprationnelles. Ce service est effectu de manire unique dans le rseau et est donc centralis. Il s'agit de:

comprimer les inforamations de gestion ( supprimer celles qui ne servent pas ). valuer le niveau de service. maintenir l'inventaire. grer et interprter les diffrents problmes rpertoris.

valuer le trafic. contrler la scurit. faire la comptabilit. grer les modifications.

6c) le service de gestion des performances Sur la base de donnes et ayant une porte moyen terme, il fait le lien entre les dcisions tactiques et stratgiques. Il s'agit de :

maintenir ( ou tablir ) une base de donnes des performances. analyser er rguler le rseau. dfinir les indicateurs de performances.

6d) le service de gestion de la planification Il reprsente l'activit de gestion long terme. Il s'agit de:

tablir les besoins. tudier et dterminer une solution. planifier l'implantation de cette solution.

CONCLUSION
Tous ces aspects doivent donc tre normaliss. C'est ce qu' essay de faire l' OSI. Des constructeurs ont eux aussi essay de fournir leurs solutions. C'est par exemple le cas d'IBM avec Netview (avec le protocole SNMP).

LA GESTION ISO
1. RAPPEL SUR LA COUCHE PRESENTATION ( couche 7 )
La couche prsentation traite l'aspect communication entre 2 entits ( traducteur en langage commun ). Il faut donc diffrencier :

l'environnement local : fonction concernant des choix locaux ( donc hors de toute normalisation ). - l'environnement distant : ensemble des fonctions d'change de donnes avec une entit distante en vue de la fourniture d'un service de niveau application.

L'OSI a d'abord normalise la norme ALS ( Application Layer Structure) dfinissant l'ensemble des fonctions qui sont propres cette couche. En fait on s'est vite aperu qu'on ne pouvait pas dfinir une modlisation globale de toutes les couches prsentations possibles. Deux concepts sont alors apparus :

celui des lments communs tous services de cette couche : CASE (Common Application Service Element ). celui des lments spcifiques : SASE ( Specific Appli Service Element ). 6

Ainsi la couche prsentation a t divise en 2 sous-couches hirarchiques :


les AP ( Application Process ) : ensemble des fonctions mettre en oeuvre pour une application particulire de type prsentation. les AE ( Application Entity ) : ensemble de fonctionnalits runies pour offrir une fonction particulire l' "Application Process". les ASE ( Application Service Element ) : description des services et protocoles standards de la couche 7 -> une AE peut tre compose de plusieurs ASE.

SAO : objet d'association unique. C'est un ensemble d'ASE ralisant une fonctionnalit prcise. SACF : fonction de contrle d'association unique. Elle assure la coordination de plusieurs ASE. MACF : fonction de contrle d'associations multiples. Elle contrle le fonctionnement de plusieurs SAO si leurs activits sont correlatives et maintient la cohrence.

exemple d'ASE :

commun ( CASE ) : ACSE, ROSE spcifique : CMISE

Modle architectural
structure de la gestion
Elle est divise en trois parties : la gestion systme la gestion de couche les oprations de couche . - la gestion systme ( SM ) : ensemble de mcanismes administrant les objets du systme ouvert. Il s'agit d'change de niveau 7 entre des SMAE via des protocoles spcifiques la gestion SMP ( System Management Protrocol ). - la gestion de couche ( N )-LM ( N Layer Management ) : ensemble de fonctionnalits permettant de grer l'activit de communication d'une couche ( N ) (concerne donc plusieurs instances de communication ) travers des protocoles spcifiques nots ( N ) - LMP. - les oprations de couche N-LO ( Layer Operation ) : ensemble des mcanismes grant une communication particulire, et en utilisant le protocole de la couche N existant.

MODELE ARCHITECTURAL(suite)
7

les fonctionnalits de la gestion OSI La base d'information de gestion flux des informations de contrle les fonctionnalits de la gestion OSI Elles ont t dcoupes en 5 domaines fonctionnels ( SMFA = Specific Management Functionnel Area ): gestion des anomalies gestion de la comptabilit gestion de la configuration performance scurit - anomalies ( Fault Management ) : une anomalie est vue comme un vnement survenu alors qu'il ne devrait pas. Parmi les fonctionnalits de la gestion des anomalies on trouve :
o o o o

tenue et examen des journaux d'erreurs. rception et modification de dtection d'erreurs. recherche et identification des anomalies ( squence de tests ou diagnostics ). correction des anomalies.

- comptabilit ( Accounting Management ) :


o

gestion des cots des ressources du systme.

- configuration ( Configuration Management ) : il s'agit de l'tablissement des paramtres contrlant les fonctionalits normales du rseau, c'est dire :
o o o

association de nom/adresse. initialisation ou retrait des objets de gestion. notification de l'tat courant du systme.

- performance ( Performance Management ) :


o o o o

collecte les statistiques. tenue et examen de journaux chronologiques de l'tat du systme. dfinition des performances attendues. modification du rseau pour atteindre ces performances.

- scurit ( Security Management ) :


o o

cration, suppression et modifications des contrles scuritaires. diffusion d'informations relatives la scurit.

La base d'information de gestion

MIB ( Management Information base) : c'est l'ensemble des informations de gestion, transfrables par des protocoles de gestion. C'est une vue conceptuelle reprsentant ces informations. flux des informations de contrle Les processus de gestion OSI reoivent des informations de contrle

des agents administratifs ( personnes ou logiciels ). des systmes distants via les SMAE, (N)-LM, (N)-LO.

le flux des informations de gestion ( celles contenues dans la MIB )


accs la MIB par les agents administratifs locaux ( administrateur... ) accs distants via SMP, (N)-LM, (N)-LO

5.LES SERVICES ET PROTOCOLES COMMUNS ( CMISE, CMIP )


CMIS : Common Management Information Service ( ISO 9595 ) .
introduction service CMISE services sous jacents scoping filtering synchronisation
INTRODUCTION

Il s'agit d'un ASE ( comme vu prcdemment ). Il s'agit de normaliser l'ensemble des services ( change informations + commandes des objets ) dans un but de gestion. L' ASE fournissant les services CMIS s'appelle CMISE. Les gens utilisant ce service sont dfinis comme suit :

CMISE-Service-Provider : entit fournissant des services CMIS CMISE-Service-User : processus d'application CMISE -> Invohing-CMISE-SU : utilisateur ( celui qui invoque l'opration ). -> Performing-CMISE-SU : excuteur ( celui qui excute le service ).

Ainsi on dfinit les primitives de CMISE par :

Services CMISE :

- Pour les notifications de gestion : 9

M-Event-Report : invoqu par un utilisateur rapportant un vnement concernant un objet gr pour un autre utilisateur. Il peut tre confirm ou non.

Pour les oprations de gestion: M-Get : un utilisateur demande un autre de retrouver des informations de gestion sur un objet. Ces inforamtions sont contenues dans les attributs de celui-ci. Les paramtres sont :

rfrence de l'objet. niveau de scoping. filtre appliquer. choix de synchronisation. liste des attributs demands.

M-Set : un utilisateur demande de notifier une information de gestion (mmes paramtres que M-Get ). Il s'agit donc de modifier les attributs de l'objet. M-Action : un utilisateur demande un autre d'xcuter une opration de gestion. Paramtres :

objet. action. plus une partie variable suivant les actions.

M-Create : un utilisateur demande un autre de crer une instance d'objet gr. M-Delete: un utilisateur demande un autre de supprimer une instance d'objet gr.

- Pour les associations M-Iniatilize : tablit l'association entre 2 CMISE-Service-User. M-Terminate : terminaison normale de l'association. M-Abort : abandon brutal d'une association ( provider ou user en paramtres ). Services sous jacents :

ACSE : pour les associations. ROSE : pour les oprations distantes.

Une autre fonction a t rajoute la norme 9595 : M-CANCEL-GET qui permet un utilisateur de ne pas recevoir les rsultats du GET. CMISE offre en plus des services supplmentaires comme :

10

slection multiple d'objet. rponse multiple ( linked reply ) : le fournisseur renvoie l'intgralit du rsultat obtenu.

Slection de l'objet gr : 2 phases :


rduction de l'espace de choix (scoping). filtrage ( filtering ).

Les noms des instance des objets grs se trouvent dans un arbre hirarchique nomm MIT ( Management Information Tree ). le scoping Identification d'un ensemble d'objet. On spcifie le niveau de scoping.Ce niveau dfinit les informations que l'on renvoie quand on a trouv l'objet dans le MIT.

objet de base seul. . descendant de Neme niveau. objet + tous ses descendants ( jusqu'au Neme niveau ). objet + tous ses descendants.

le filtering Applique un test chacun des objets pour en extraire un sous-ensemble. Synchronisation : Spcification de la synchronisation des divers objets slectionns ( par scoping + filtering ). Deux valeurs possibles :

Atomic : excution sur tous les objets ou pas du tout ( => si une impossibilit alors pas d'excution ). Best Effort : excution sur un maximum d'objets.

CMIP : Common Management Information Protocol ( ISO 9596)


Ensemble des protocoles utiliss pour rendre les services de CMISE. Comme tout protocole, il dfinit les rgles de cration et d'change des diffrents PDU. Les services sous-jacents sont :

ROSE ( RO-INVOKE, RO-RESULT ...) : les classes utilises sont 1 ( synchrone + rapport ), 2 et 5 (asynchrone avec ou sans rapport ). ACSE + Prsentation ( A-ASSOCIATE..., P-DATA ) utilis par ROSE.

CMIP spcifie le transfert des CMIP-PDU. La machine CMIP transmettra au CMISE-ServiceUser toutes les trames valides, et renverra ( en spcifiant le rejet ) toutes celles qui ne le sont pas. 11

Le principe :

accepter les primitives + donnes et en vrifier la validit. envoyer le CMIP-PDU via ROSE son interlocuteur. attendre une rponse de ROSE.

Exemple sur M-GET: Avec:

LA GESTION SYSTEME ISO


Le document ISO 10 040 fournit les mcanismes pour surveiller, contrler et coordonner les ressources de gestion d'un environnement ISO. La norme comprend 3 sous normes:

fonction de gestion systme ( ISO 10164 ). spcification des objets grs ( ISO 10165 ). service et protocole de niveau 7 ( CMIS, CMIP ).

Cette norme couvre l'ensemble des 5 domaines SMFA. Mais un domaine peut utiliser ces 3 normes de manire non disjointe ( c'est dire un objet peut tre gr par 2 domaines, une fonction peut tre utilise par 2 domaines... ) Ce document ( aussi appel System Management Overview ) s'appuie sur une srie de dfinitions :

service de gestion systme ( SM service ) : ensemble des primitives fournissant un service utilis par la gestion systme. . MIS-user : application utilisant des services de gestion systme. . agent : MIS-user qui, pour un change de gestion, est capable d'excuter des oprations sur des objets grs et d'mmettre des notifications sur leur comportement. . manager :MIS-user qui met des oprations de gestion ( extrieures ) et est capable d'en recevoir des notifications. . modle de gestion de systme : comprend 4 aspects ( voir dtail plus loin ). . gestion d'un environnement de communication. . application de gestion : processus excutant des activits de gestion de manire distribue. . interaction entre applications : s'exprime en terme d'opration et de notification et est utilise grce aux services et protocoles de gestion. . activit de gestion : manipulations des objets grs.

MODELE DE GESTION SYSTEME


Aspect informationnel. Aspect fonctionnel

Aspect informationnel
12

La MIB d'un systme est constitue de l'ensemble des objets grs par celui-ci et de leurs attributs. Un objet est donc une vue abstraite d'une ressource ( reprsentant ses proprits de gestion ). Ces objets sont de 2 types:

objet du systme gr relevant de plusieurs couches ou du systme complet . objet de la couche ( N ).

La norme ISO 10165 dcrit ces objets et sera dtaille plus loin.

Aspect fonctionnel
C'est l'numration et la dfinition des 5 domaines SMFA ( configuration, fautes, scurit, performance, comptabilit ). Cette numration logique pour but de dfinir les normes sur les fonctions d'administration ( ISO 10 164 ) qui doivent recouvrir chacun de ces 5 domaines.

Aspect communication
PRINCIPES Les conversations entre agent et manager sont ralises grce des changes d'informations de gestion au moyen de protocole OSI. Les supports pour ces communications sont :

CMIS pour le transfert de requtes. Management Service Control Discriminator : contrle d'accs aux objets et dissmination des informations de notification.

Le discriminateur comprend 3 parties :


service access dicriminator : reoit les oprations et accde aux objets. event control discriminator : qui reoit des objets la notification des oprations effectues et les renvoit au monde extrieur concern. log control disciminator : reoit les notifications des objets et les crits dans un journal local ( permet des recherches d'informations a posteriori ).

REALITE La gestion systme est donc dfinie sous la forme d'AE que l'on nomme SMAE ( system management application entity ) et est compose de:

ROSE. ACSE. CMISE.

13

SM-ASE ( system management ASE ) : entit utilisant CMISE pour transfrer dans MA-PDU ( management protocol data unit ).

Un contexte d'application est l'tat de la communication, aprs les accords effectus lors de l'association de celle-ci. Il s'agit donc d'un ensemble d'lments de services applicatifs qui peuvent tre utiliss tout moment de l'association. Le document ISO 10040 a dfinit 3 contextes:
o o o

contexte d'application manager : ACSE + ROSE + CMISE + SM.ASE.Celui qui a demand l'association est dfinit comme le manager. contexte d'application agent : identique au contexte d'application manager mais celui qui a demand est l'agent. contexte d'application manager/ agent : mme ASE mais les entits peuvent jouer les 2 rles.

L'tablissement de l'association prvoit 2 ngociations :


o o

celle du contexte d'application : on prend le plus grand contexte possible. celle d'unit fonctionnelle : elle est optionnelle et permet de limiter les fonctionnalits possibles d'une association ( ex: juste les notifications...) . Dans ce cas l'entit propose des units fonctionnelles ( SMFU ) qui sont acceptes ou non.

Ainsi une communication entre 2 entits de gestion implique pour eux la connaissance :
o o o o

du protocole ( contexte d'application... ). fonctionnelle ( fonction refuse ou accepte ). de l'objet gr ( classe, instance, identification de l'objet, attribut ). des contraintes sur les fonctions supportes.

Cette connaissance peut tre tablit :


o o o

- avant la communication. pendant la phase d'association. pendant l'association.

Aspect organisationnel
Il dcrit la nature distribue de la gestion. Il s'agit d'un ensemble d'associations asymtriques entre MIS-USER ( dans la mesure ou l'un joue le rle d'agent et l'autre de manager ). Pour les besoins organisationnels la notion de domaine de gestion est dfinie. Son but est de partitionner la gestion en ensemble de fonctions ( ou politiques ( scurit, comptabilit...) ) appel domaine fonctionnel de gestion : MFD ( Management Functionnal Domain ).

14

Ces domaines peuvent se recouvrir mais chacun est gr par une autorit propre. Remarque : certaines autorits ont le contrle de plusieurs domaines pour des besoins administratifs particuliers ( tels que l'tablissement et maintenance des autorits... ). Les domaines sous le contrle de cette autorit s'appelle le MAD ( Management Administration Domain ).

FONCTION DE LA GESTION SYSTEME


Actuellement il existe 7 documents normalisant les fonctions de gestion et 6 documents l'tat de draft qui constitueront la suite de cette srie. Dans la suite nous prsenterons chacun de ces 13 documents. La gestion des objets La gestion des tats La gestion des relations La gestion des alarmes la gestion des vnements La gestion des journaux La gestion de la scurit Les fonctions d'analyses de la scurit Attributs et objets pour le contrle d'accs La fonction de compteur de comptabilit Fonction de surveillance de la charge d'un travail Fonction de gestion des tests La fonction de rsum a) La gestion des objets Doc 10 164-1 Le but est de pouvoir : - crer un objet. - dtruire un objet. - changer tout ou une partie de l'objet - examiner tout ou une partie de l'objet Il s'agit enfin de notifier les changements dans la configuration. Remarque : Cette gestion peut se faire - dans le processus de configuration local. - dans les oprations de couches. - par gestion systme. Nous n'allons examiner que ce dernier point. La gestion d'objet dcrit 10 services dont : 4 services de rapport ( compte rendu ) : utlisant M_EVENT_REPORT - raport de cration ( confrm/non) - rapport de destruction ( c/n ) - rapport de changement de nom ( c/n ) - rapport de changement d'attribut ( c/n ) 6 services de gestion

15

- PT-Create ( c ) : cration de l'objet -> M-Create. - PT-Delete ( c ) : destruction d' un objet -> M-Delete. - PT-Action ( c/n ) : action sur un objet -> M-Action. - PT-Set ( c/n ) : modification de la valeur d'attribut -> M-Set. - PT-Get (c) : recherche de la valeur d'attribut -> M-Get. - PT-Event-Report ( c/n ) : compte rendu d'venement -> M-Event- Report. b) La gestion des tats Doc 10 164-2 Le but est de permettre un utilisateur d'tre averti des changements des tats, ainsi que de contrler l'utilisation des ressources, leur oprabilit, leur disponibilit. Pour chaque objet son tat dpend de 3 facteurs : - oprabilit : l'objet est ( ou n'est pas ) physiquement install : operationnal state. - son utilisation : l'objet est ( ou n'est pas ) utilis : usage state. - son administration :permission (ou non) d'utiliser le rseau: administrative state. Les attributs correspondant ces diffrents cas sont : - opeationnal state : 2 valeurs : en et hors service. - usage state : 4 valeurs : inactif, actif, occup, inconnu. - administrative state : 3 valeurs : verrouill, dverrouill, coup. c) La gestion des relations Doc 10 1643- 3 Le document prvoit la dfinition d'un ensemble d'attribut, d'opration et de notification permettant de reprsenter les relations existantes entre les diffrentes parties du systme. Une relation est un ensemble de rgles dcrivant la manire dont une opration affecte d'autres oprations du systme. Ainsi 2 objets sont en relation si l'opration de l'un affecte l'opration de l'autre. Ces relations peuvent tre directes ou indirectes. De plus, une relation est dite symtrique quand le rle jou par les objets ainsi que les rgles d'interaction entre eux sont identiques. Sinon, elle est asymtrique. OSI reconnait 3 types de relations : - la relation de contenance : voir modle d'informations. - la relation rciproque : reprsente par l'attribut relation qui a la (les) valeur(s) de (des) l'objet(s) auquel il est reli. exemple : Attribut de relation de : -A:B -B:A Une relation rciproque est reprsente par la concatnation de l'attribut de relations des 2 objets ( ici AB ). On gnralise ensuite cette notion N objets. La gestion de relation est donc la gestion de ces attributs. Elle se fait via les oprations de gestion d'objets ( Create, Replace, Delete ). Mais la difficult est qu'une opration sur un objet ncessite aussi une opration sur chaque objet en interaction. Les relations d'un objet sont obtenues par un simplet Get sur l'objet ( en observant l'attribut de relation ). Selon l'objet, une notification peut tre mise quand la relation est cre, dtruite ou change.

16

- relation sens unique : identique rciproque sauf que l'attribut n'est prsent que dans un objet. - plusieurs types de relations rciproques entre objets existent : - service : relation asymetrique,1er objet fournisseur de service et 2eme objet utilisateur. - parit : relation symtrique reprsentant les rgles de communication entre objets. - reprise sur erreur : relation asymtrique indiquant que le second objet (secondaire ) peut remplacer le 1er en cas d'erreur. - backup : relation asymtrique, le 2eme objet est une sauvegarde du 1er. - groupe : relation entre 2 objets o le 1er ( membre ) appartient un groupe reprsent par le second ( propritaire ). Ce concept permet de regrouper des classes, ou des objets dans un but fonctionnel et dynamique. La norme permet donc de dfinir les attributs ncessaires la description d'une relation ainsi qu'une fonction de compte rendu ( Relationship change reporting ). Ces attributs sont : - la nature de la relation ( rciproque...). - son type ( utilisateur, fournisseur... ). d) La gestion des alarmes Doc 10 164- 4 Dans ce document on dfini la faon dont sont transmises les alarmes, les erreurs... En effet, il est utile dans un systme de dtecter les fautes le plus tt possible. Pour cela, on surveille le systme, on tablit un taux d'erreur et un seuil ne pas dpasser. 5 types d'alarmes sont normaliss : - communication : dfaut de communication ( ou dgradation ). - qualit de service : dgradation de la qualit. - quipement : faute d'quipement. - processing : faute de soft. - environnement : faute dans l'entourage de l'quipement. Chacune de ces alarmes a des paramtres spcifiques tels que : - cause probable : appartient une liste de 40 causes. Exemple : - communication : perte du signal, erreur de transmission locale... - qualit de service : largeur bande rduite, taux de retransmission excessif... - soft : erreur version, problme mmoire... - quipement : problme terminal, multiplexeur... - environnement : temprature, humidit... - degr de svrit : ide que l'on se fait de l'alarme. Il peut tre : - cleared : annule les autres alarmes de mme causes. - indtermin. - mineur : n'affecte pas le service, mais sa correction peut empcher une faute plus grave. - majeur : action corrective urgente. - critique : action corrective immdiate. - avertissement : alarme sans effet a priori. En plus de ces 2 paramtres obligatoires, il existe d'autres paramtres: - backup : l'objet a t sauvegard. - information de seuil : en cas de dpassement de celui-ci.

17

- changement d'tat ( ventuel ). - proposition de rparation ... Cette fonction Alarm Reporting forme une unit fonctionnelle nomme Alarm Reporting Functional Unit.

e) la gestion des vnements Doc 10 164-5 La notification des diffrents objets est reue par une fonction nomme "Dtection et traitement d'vnements " qui construit un " rapport d'vnement potentiel". Les rapports sont envoys au diffrents discriminateurs, qui dterminent le rapport d'vnement effectivement envoy aux diffrentes destinations. La gestion d'vnement permet donc d'tablir et de contrler les tests de discrimination et d'envoyer les rapports. Elle comprend les services : - initiation. - terminaison. - suspension. - reprise. - notification de conditions. - recherche des conditions. On dfinit ainsi une classe d'objet de base ( discriminateurs ), pouvant tre divise en sous- classe. Ces objets comportent divers critres comme les tats administratifs, d'utilisation, oprationnels... Un attribut particulier est le Discriminator Construct : Filtre appliquer sur l'objet arrivant. Un autre attribut est la ( les ) condition(s) pour laquelle le discriminateur envoie le rapport d'vnement ( attribut boolen construit grce une opration (et/ou) sur la prsence ou non de proprit sur un attribut ). Un discriminateur comme tout objet comporte 3 tats : - administratifs : locked, unlocked. - oprationnel : enable, disable. - utilisation : active, idle, busy, unknow. Les fonctions d'un discriminateur peuvent tre actives : - toutes les 24h : daily scheduling package. - toutes les semaines : weekly scheduling package. - par un message de type schedular : external schedular scheduling package. La classe Event Forwarding Discriminator est une sous classe des discriminateurs qui permet, pour un objet donn, de grer les conditions d'envoi de notification. Les services utiliss par cette unit fonctionnelle ( nomme Event Report Management Functionnal unit ) sont : - PT-Create : pour initier. - PT-Delete : pour terminer. - PT-Set : pour modifier, suspendre, reprendre.

f) La gestion des journaux Doc 10 164- 6 18

Ce document spcifie l'ensemble des procdures de journalisation, c'est dire : - choisir les enregistrements mettre dans un journal. - modifier les critres d'enregistrement. - suspendre et reprendre l'activit d'enregistrement. - crer ou dtruire des journaux. Le journal est reprsent par une classe d'objets spcifiques nomms " log ". Ces objets contiennent des rapports d'evnements et des informations spcifiques ( heure d'enregistrement ... ) ajouts par le processus qui traite la journalisation. L'objet " log " comprend les attributs suivant : - idf du log. - tat ( administratif, oprationnel ) d'utilisation. - conditions d'enregistrement ( l'objet stock doit remplir ces conditions ). - nombre d'enregistrements stocks. - taille actuelle. - taille maximale. - comportement en cas de dpassement de capacit de stockage. La classe " log record " reprsente les enregistrements contenus dans le journal et est compose d'attributs : - objet. - idf. - heure d'enregistrement. Les services utiliss par Log Control Functionnal unit sont : - pour log - PT-Create et PT-Delete : pour crer et terminer un log. - PT-Set : pour modifier les attributs, suspendre ou reprendre l'activit. - pour log-record : - PT-Get : pour rechercher des enregistrements. - PT-Delete : pour dtruire des enregistrements. g) La gestion de la scurit Doc 10 164- 7 La norme 10 164-7 se base sur celle de la gestion des vnements dcrite plus haut. Les vnements sont choisis l'aide d'un "discriminateur d'envoi" et transmis l'utilisateur directement via le service CMIS M-Event-Report. La fonction dcrite ci-dessous permet de crer, dtruire, modifier cet objet discriminateur d'envoi. En plus du traitement normal d'un vnement, certains paramtres sont ajouts. Ce sont: - type de l'alarme : - violation intgre : flot de donnes interrompu : problme possible concernant la destruction, modification.. d'un objet. - violation oprationnelle : le service demand ne peut tre fourni. - violation physique : la ressource physique demande un problme. - violation de scurit : problme dtect par un mcanisme de scurit. - violation temporelle : un vnement s'est produit hors du temps autoris. - causes probables (environ 20) dfinies suivant le type d'alarme : - intgrit : information manquante ... - oprationnelle : refus service, hors service... - physique : cbles dfectueux...

19

- scurit : chec authentification... - temporelle : expiration d'un dlai... - la svrit : indtermine, critique... - autres paramtres : ex: identificateur de celui qui a gnr l'alarme, utilisateur/ fournisseur du service ayant dclench l'alarme... h) Les fonctions d'analyses de la scurit Doc 10 164-8 Ce document dfinit l'analyse rtrospective de la scurit ( Audit trail ). Cette analyse consiste comparer les enregistrements d'vnements scuritaires avec les valeurs qu'on attendaient d'eux. On dfinit pour cela un journal spcifique ( Security Audit Trail Log ). Il s'agit d'un journal normal ( comme dfinit dans la gestion des journaux ) ayant en plus les attributs suivants : - type de l'audit : nature, statistiques dues un vnement... - cause du rapport de service : requte, refus, rponse, erreur, reprise sur erreur... - informations sur l'audit lui mme. i) Attributs et objets pour le contrle d'accs Doc 10 164-9 Ce document dfinit comment un administrateur peut contrler l'accs aux diffrentes ressources. Ainsi pour toute requte d'accs une ressource on utilisera une police d'accs qui acceptera ou non cet accs. Cette fonction sera donc active pour toutes les demandes d'association et d'oprations sur un objet. Le principe est : - une fonction excute le contrle d'accs ( AEF : Access- Control-Enforcement Functiun ) qui a pour but de dtecter les requtes sur un objet protg et l'envoie vers une partie dcisionnaire en spcifiant le demandeur, l'opration, et l'objet demand. - la partie dcisionnaire est excute par l' ADF ( Access Control Decision ) qui compare les attributs de la requte avec des informations contextuelles et prend la dcision d'accs ou de refus et la transmet l'AEF. - l'AEF prend note de la dcision et transmet la requte en cas d'autorisation ou envoie le refus au demandeur. La norme dfinit 3 classes d'objet ncessaires au contrle d'accs : - descripteur de contrle d'accs : lments ( AEF, ADF ) utiliss pour le contrle d'accs. - information de contrle d'accs : lments protger, + rgles appliquer lors de l'accs. - initiateur autoris : c'est la police de contrle d'accs ( nom de la police du domaine, rgles par dfaut...). Le contrle d'accs peut se reprsenter par le schma :

j) La fonction de compteur de comptabilit Cette fonction collecte des informations sur l'utilisation des ressources du systme. On dfinit pour cela 2 classes d'objet : - contrle de compteur de comptabilit : collecte et choisit les donnes d'utilisation de la ressources.

20

- donnes de compteur de comptabilit : reprsentation comptable de l'objet. il s'agit de : - notification de comptabilit ( suivant les paramtres ). - GET sur certains attributs de l'objet. Les attributs de : - contrle : - unit de mesure utilise. - vnement dclenchant la mise jour et/ou l'envoi d'informations comptables. - ensemble des instances d'objets contrls ( et le nom de ces objets ). - donnes : - identification des objets et des services. - l'heure de mesure. - tat de l'objet. - informations de mesure. L'opration de comptage est active lors d'une demande d'un utilisateur.Cette demande crera des objets de type contrle et donnes. Un journal sera aussi cr pour sauvegarder les diffrentes notifications mises par l'objet donn. Les diffrents services dfinis par ces classes sont : - contrle : - crer et dtruire un objet : PT-Create, et PT-Delete. - action de dmarrer, suspendre ou reprendre un contrle : PT-Action. - rechercher et modifier la valeur des attributs : PT-Get et PT-Set. - rapport d'vnements : PT-Event-Report ( dmarrage, suspension, reprise). - donnes : - crer et dtruire : PT-Create et PT-Delete. - rechercher la valeur d'un attribut : PT-Get. - rapport d'vnement : PT-Event-Report. Cette unit fonctionnelle s'appelle Accounting Mater Functionnal Unit. k) Fonction de surveillance de la charge d'un travail Doc 10 16411 Le but de ce document est de dtecter le plus vite possible les problmes de manque de ressources. Cette documentation spcifie la fonction de surveillance (mesure de la charge de travail, de rejet, d'utilisation ) ainsi que les mcanismes pour obtenir ces mesures. Dfinitions des notions utilises : - objet mtrique : objet ayant au moins un attribut ( attribut mtrique dont la valeur est calcule partir de valeurs observes sur d'autres objets. - capacit : quantit de ressources ( alloues + disponibles ). - charge de travail ( Workload ) : quantit de ressources demandes par un utilisateur. On tudie 3 quantits qui sont : - taux de rejet. - taux de demande. - taux d'utilisation. Pour chacune de ces 3 quantits ont associe un ensemble de 4 mesures qui sont les conditions d'atteinte et de sortie d'un seuil :

21

- avertissement prcoce ( EWx, EWCx ). - svre ( Sx, SCx ). avec - EW : early warning. - S : severity. - C : clear. - x : RRT ( Rejection Rate Thresold ) pour taux de rejet. RQT ( Rejection Question Thresold ) pour taux de demande. RUT ( Rejection Utilisation Thresold ) pour taux d'utilisation. Diffrentes contraintes s'exercent sur ces seuils : EWCT < EWT < SCT < ST, c'est dire que le niveau de l'avertissement prcoce est infrieur au niveau de l'avertissement svre. Les taux peuvent se reprsenter graphiquement sous forme de jauge. Dfinition des diffrents taux : - taux de ressource : nombre de ressources disponibles. Il est incrment quand un utilisateur demande une ressource, et est dcrment quand il la libre. - taux de rejet : nombre de rejets d'accs une donne pendant un intervalle de temps t, calcul suivant les notifications de l'objet. - taux de demande : nombre de demande d'accs pendant un intervalle de temps t, calcul suivant les requtes des utilisateurs de la ressource. Pour cette surveillance l'OSI dfinit 2 objets de type mtrique : - Gauge Monitor : met des notifications quand un seuil est atteint. - Mean monitor : notification de la moyenne des taux sur une priode de temps. Des sous-types ont t crs, ils ont une particularit en plus par rapport ces objets, telle que : - compteur spcifique ( effaable par une ressource, compteur de boucle ). - lancement automatique : tous les jours, semaines, mois... Cette classe est une sous-classe du type gestion des alarmes avec : - type d'alarme : qualit de service. - cause probable : taux de ressource, taux de rejet ou taux de demande. - svrit : S: svre, EW : mineure. Services dfinis dans cette fonction : - crer et dtruire un objet mtrique : PT-Create, PT-Delete. - modifier les attributs, suspendre et reprendre l'activit : PT-Set. - obtenir des attributs d'objets mtriques : PT- Get. l) Fonction de gestion des tests Il s'agit de dcrire la fonction qui gre les tests sur les objets de gestion. Cette fonctionnalit est trs utile dans des aires fonctionnelles comme la gestion des fautes, des performances... Un test modifiant l'environnement doit donc : - crer un environnement. - contrler les objets dans le domaine test. - restituer l'environnement. Telle qu'elle a t dfinie, cette fonction offre diffrentes possibilits sur les modes d'activation des tests ( scehuling ) et sur les mthodologies ( tests en boucles, injection de fautes..). Un test, tel qu'il est dfini, met en jeu 2 lments diffrents:

22

- le conducteur. - l'excuteur. Ainsi un test est demand par le conducteur et excut par l'excuteur. Celui-ci demande le test un objet spcifique de la gestion de tests nomm MO ( objet gr ). Ce dernier va crer des objets de tests ( TO ) qui n'existeront que pendant la dure de celui-ci. Leur but est de contrler le test et l'mission de diffrentes notifications. Les objets subissant le test et l'mission sont eux appels MOT ( Management Object Tested ). 2 types de tests sont dfinis : - test synchrone : les notifications sont donnes au conducteur. - test asynchrone : les notifications sont renvoyes ultrieurement par l'excuteur ou en lisant les TO ( objet de tests ). En crant un test, on doit donc spcifier les diffrents TO ncessaires, la valeur initiale de leurs diffrents attributs, ainsi que les objets tests. Les attributs des objets de test ( TO ) sont : - inoccup sans problme : en attente d'activation. - inoccup avec problme : test demarr, mais problme d'excution. - suspendu : test suspendu, mais les attributs sont visibles. - test en cours : phase active. - termin : test termin, remise en place de l'nvironnement. - inaccessible : erreur pendant le test. Une session de tests est un test que l'on nomme et qui est rutilisable volont. Un test peut tre suspendu. Dans ce cas l'environnement de test est sauvegard (chaque TO garde ses attributs ), l'environnement est restaur ( les objets se mettent en tat oprationnel ). A la reprise, l'environnement de test sera restitu dans l'tat o il tait lors de la suspension. Caractristiques des tests : - tout objet de test ( TO ) a un tat de test. - but du test. - interaction entre les TO et les objets tests ( MOT ). - environnement du test : comment l'objet MOT est configur ( bloqu, absent) et quand cela doit tre fait. - type de terminaison : spontane ou demande par une requte du conducteur. - type des informations dans le compte rendu du test. - priode de temps maximale du test. - paramtres d'chec de test ( ex : TO existe dj, cration TO impossible ). Services : - destruction des TO : PT-Delete. - modifier et consulter les attributs des TO : PT-SET, PT-GET. - 4 services spcifiques utilisant M-Action : - Test-Request-Asynchrone ( c ) : demande de test asynchrone. - Test-Request-Synchrone ( c/m) : demande de test synchrone. - Test-Suspend-Resume : pour suspendre ou reprendre un test. - Test-Terminaison : demande de terminaison d'un test. - 1 service utilisant M-Event-Report : - Test-Result : compte rendu du test. m) La fonction de rsum doc 10 164- 13

23

Ce document rpond au besoin de performance des mesures. Il s'agit en effet de regrouper plusieurs valeurs d'attributs afin d'en fournir des informations statistiques. Il s'agit donc de rsumer les informations concernant : - un seul type d'attributs, d'un objet gr. - plusieurs types d'attributs, d'un objet gr. - un seul type d'attributs, de plusieurs objets grs. - plusieurs types d'attributs, de plusieurs objets grs. Les informations seront rcoltes : - l'instant mme, sur demande. - pendant une priode de temps fixe. - priodiquement. La fonction devra donc : - planifier les activits de rsum. - identifier les algorithmes statistiques utiliss. - envoyer des rapports d'vnement. Les objets pour lesquels on peut utiliser des informations, sont des informations de type: - gestion de ressources ( voir scurit ). - d'objet mtrique ( voir taux de charge ). - journaux. Les rapports des objets de type rsum vont : - vers des journaux. - vers des discriminateurs d'vnements. Le document dfinit les objets servant cette fonction. Ils sont de type " scanner ". Il en dfinit 3 sous-classes particulires : - scanner homogne : il observe un attribut sur un ensemble d'objets. Ces objets sont slectionns par CMISE par scoping + filtering. Cette classe d'objets permet de calculer des statistiques sur les attributs de type numrique.En fin de priode d'observation il renvoie : - l'ensemble des attributs rcolts. - les statistiques calcules. - les deux. - scanner htrogne : diffrents attributs sur diffrents objets. Le rsultat est transmis en fin de priode. - scanner htrogne avec buffer : mme chose que sans buffer, mais on peut stocker les rsultats de diffrentes priodes. La " super classe " scanner dfinit comment on spcifie l'ensemble des objets "rsums". Ses attributs sont : - identificateur. - tat ( oprationnel...). - priodicit. - attributs et objets relever. Le scanner comprend une partie contrle qui permet de stimuler le dbut des relevs ( chaque dbut de priode ) et activer le scanner. L'envoie des rapports se fait : - en fin de priode en temps normal. - sur demande ( si priode nulle ). - la fin d'une priode particulire ( et prdfinie ) et seulement dans le cas d'un scanner bufferis.

24

Le scanner homogne relve un ensemble d'attribut du mme type, soit dans une liste d'objets, soit dans un rsultat de recherche CMISE (scoping + filtering ). Il calcule le rsultat d'une fonction qui lui est fournie chaque fin de priode. Optionnellement, il peut renvoyer aussi les dernires valeurs d'attributs releves. Ces attributs sont : - la slection des objets ( objet de base + scoping + filtering ou une liste ). - liste des attributs. - priode de relev. - calculs utiliss ( fonction statistique, algorithmes... ). Le scanner htrogne possde les mme attributs sauf le calcul utilis ( il ne calcule pas ). Le scanner htrogne avec buffer est identique celui sans buffer mais possde en plus un attribut qui est la priode de rapport ( nombre de priodes avant l'envoi des notifications). Les services fournis sont donc : - crer, dtruire, modifier, accder aux diffrents scanner : PT-Create, PT- Delete... - grer les notifications : M-Event-report. - activer les relevs : par M-Action.

LA STRUCTURE DES INFORMATIONS DE GESTION


Il s'agit ici de dfinir les diffrentes informations de gestion. Cette dfinition est trois niveaux :

Le modle d'informations ( 10 165-1 ) : structure commune tous les objets de gestion, oprations et notifications les concernant, et principe de nommage et de contenance de ceux- ci. Dfinitions des objets de gestion et de leurs attributs ( 10 165-2 et-3 ). - Aide la dfinition de nouveaux objets ( 10 165-4 ).

a) Le modle d'information
Concept Principe de nommage Opration et Notification Concept Une structure de gestion est modlise par un objet, ce qui est trs puissant pour toute modlisation. Un objet comporte :

des attributs ( type statique ). des actions et notifications ( type dynamique ).

Attribut d'un objet : Il s'agit pour un objet de dfinir :

le nom de l'attribut . 25

type de domaine. restriction.

Ces attributs pourront tre lus ou crits. Le type du domaine peut tre un objet lui-mme l'attribut est dit " set value " ). On peut regrouper les attributs en groupes logiques ( association d'attribut sans former un objet ). On dfinit ainsi un " group attribute ". Le comportement ( Behaviour ) : Il s'agit de la smantique de l'objet, c'est dire son comportement. Exemple :

temps de rponse de l'opration . circonstance d'envoi de notification...

Ensemble conditionnel : ensemble des proprits qui sont toujours observes ( ou prsentes ) sur les attributs tous moments ( invariant de l'objet ). Principe de contenance et de nommage Une relation est dite de contenance, si un objet gr contient une instance d'autres objets tel que :

modlisation d'une ressource ( composant...). relation organisationnelle ( rpertoire, fichier, champ...).

On dfinit ainsi une relation de dpendance entre ces 2 objets. On dfinit aussi un arbre de contenance, de racine root ( objet contenant tous les autres ) et a en relation avec b si b est contenu dans a ( remarque : a : le suprieur, b : le subordonn ). On dfinit ainsi le principe de nommage des objets grs.

si a contient b et a se nomme DNi-1, et le nom propre de b est RDN alors : o nom de b = DNi = DNi-1+ RDN ( + = concatn )

Nom de :

A = "a" B1 = "ab" C = "ac" B2 = "abb"

Les oprations de notification Opration sur les attributs Opration sur les objets Notification Les oprations de gestion sur un objet sont de deux types :

celles qui agissent sur les attributs.

26

celles qui agissent sur l'objet tout entier.

Pour bien se drouler, les oprations doivent respecter les rgles suivantes :

celui qui invoque l'opration les droits d'accs cet objet. l'opration ne viole aucune contrainte de consistance.

Si l'opration est excute sur plusieurs objets, elle devra mettre en oeuvre un mcanisme de synchronisation, dfinit diffremment sur chaque objet. Oprations sur les attributs :

lecture d'attribut : GET : lecture d'une liste d'attributs donne en paramtre ( par dfaut elle lit tous les attributs ). Erreur ssi lecture d'un attribut non lisible. criture d'attribut : REPLACE : remplace pour chaque attribut ( donn en paramtre ) sa valeur ( donne en paramtre ). Erreur ssi attribut restreint en criture et valeur incorrecte ou attribut en lecture simple. valeur par dfaut : REPLACE WITH DEFAULT : remplace les attributs d'une liste par la valeur par dfaut spcifie la cration de l'objet. Erreur ssi attribut en lecture simple et pas de valeur par dfaut. ajout d'lments un ensemble : ADD NUMBER : ajoute des lments un attribut de type set-value. Erreur ssi l'attribut n'est pas de type set value ou en lecture simple. retrait d'lment d'un ensemble : REMOVE MEMBER : retire les lments ( d'une liste ) un attribut de type set value. Erreur ssi pas de type set value ou pas accessible en lecture.

Oprations sur les objets :

cration d'objet : CREATE : crer et initialiser l'objet reprsentant la ressource. Le principe de nommage de cet objet suit les rgles de contenance cites plus haut. La valeur des attributs est : o fixe par une liste de donnes passe en paramtres. o spcifie dans la dclaration de classe ( par dfaut ). o recopie partir d'un objet pass en paramtre ( objet de rfrence ). Erreur ssi utilisation d'identificateurs ( attribut, objet de rfrence...) incorrects, lien de contenance invalide. destruction d'un objet : DELETE : si il existe des objets contenus alors il agit de 2 manires diffrentes : o refus de la requte. o destruction des objets contenus. De mme si cette destruction tait contraire aux contraintes d'intgrit ( relation avec d'autres objets... ) alors l'objet peut refuser de se dtruire. opration de l'objet : ACTION : lancement d'une opration constituant un point d'entre dans l'objet. Elle rend soit le rsultat soit une indication d'erreur ( nombre de paramtres incorrects... ).

Notification : En dfinissant une classe, on dfinit des notifications mettre en cas d'vnements prcis ( interne ou externe ). Mais c'est le discriminateur d'objet qui prendra l'initiative de distribuer cette notification dans le systme

27

La dfinition des informations


dfinition explication des objets normaliss Le document " dfinition de l'information de gestion " ( DIS 10 165-2 ) est la concatnation des 2 draft " Dfinitions des objets supports " ( DP 10 165-2 ) et de " Dfinition des attributs supports ( DP 10 165-3 )". Il s'agit en fait de dfinir une ou des super classes d'objets utilisables par toutes les fonctions de gestion ( prsentes ou venir ). Le document dfinit 15 classes d'objets. Nous allons les reprsenter dans un graphe qui nous permettra non seulement de voir des relations d'hritage mais aussi des relations de contenance : avec :

Top : classe d'objet dont tous les autres sont drivs. System : reprsentation du matriel ( ou logiciel ) concern pour le traitement ou le transfert des ressources. Discriminator: dfinit l'ensemble des critres pour contrler l'ensemble des services de gestion ( voir chap. 2.e ). o Event Forwarding discriminator : dfinit les conditions d'envoi des rapports d'vnements . Log : dfinit les critres de contrle de l'information des journaux ( cf 2.f ). o Log record : dfinition des enregistrements contenus dans un journal. Alarme R : information stocke aprs un rapport d'alarme ( sous ensemble des infos mises lors d'une notification d'alarme ( cf 2.d )). Attribute Value Change R : information stocke aprs un rapport de changement d'attribut ( cf 2.a ). Object Creation R : information stocke aprs un rapport de cration d'un objet ( cf 2.a ). Object Deletion R : information stocke aprs un rapport de destruction d'un objet ( 2.a ). Object Name Change R : information stocke aprs un rapport de changement de nom d'un objet ( 2.a ). Relationship Change R : information stocke aprs un rapport de changement dans une relation ( 2.c ). State Change R : information stocke aprs un rapport de changement de l'un des 3 tats ( 2.b ). Security Alarm Report R : information stocke aprs un rapport d'alarme de scurit.

Pour chaque objet, on dfinit :


la classe selon laquelle il hrite. ses attributs et comment on peut les accder ( ex : lecture... ). pour chaque attribut, on dfinit les contraintes respecter et les notification mettre si celles ci ne le sont pas.

28

Mthode pour la dfinition des objets grs


Contrainte imposos par l'ISO pour la dfinition de nouveaux objets Conseil propos par l'ISO pour la dfinition de nouveaux objets Il s'agit ici de donner des informations et des outils ncessaires la cration de nouveaux objets compatibles avec la norme. Nous avons vu que pour grer un systme il faut : - Un ensemble de services et de protocoles utiliss par la communication (modification, opration, information...). Il y a 3 types de protocoles : - protocole de gestion systme ( SMP : System Management Protocol ) ex : CMIP. - protocole de gestion de couche : (N)-LMP ( Layer-MP ). - protocole de couche : (N)-LP. - Le comportement des objets du systme en matire d'opration, notification... remarque : ce comportement est totalement indpendant du protocole utilis. - La dfinition syntaxique de chaque objet ( reprsentation...), dpendant totalement du protocole utilis. Diffrents problmes rsultent de cette sparation. La consistance en est un, notamment lors de la destruction d'un objet. Il faut donc absolument dfinir prcisment l'action de destruction de l'objet ( en termes de contraintes, notifications et oprations ) lorsqu'il est dtruit ( cf 2.c ). De plus la dfinition de chaque nouvel objet ncessite la cration d'un identificateur unique (exemple : les identificateurs utiliss par CMIP doivent tre uniques ( et non ambigus )). La norme prvoit donc un mcanisme d'identification pour chaque objet. Un autre problme est le fait que la cration d'un objet de gestion peut se faire par des moyens extrieurs au cadre OSI ( exemple : opration de la ressource reprsente...). Pour cela, on a dfinit un objet spcifique nomm Initial Value Manage Object ( IVMO ), ayant des valeurs par dfaut , et modifiables tout moment par des oprations de gestion. Ces valeurs par dfaut peuvent tre: - un paramtre du Create. - la valeur par dfaut spcifie la dfinition de la classe. - la valeur par dfaut spcifie dans le IVMO associ. - un objet de la mme classe dfini comme l'objet de rfrence dans Create. En dehors de ces aspects obligatoires la cration d'une nouvelle classe d'objets, l' OSI a mis des principes facultatifs mais conseills pour cette mme opration : - utiliser les types d'attributs, notification, action dj dfinis dans la norme. - la structuration d'un groupement d'attributs ( attributs soit tous prsents, soit tous absents) peut se faire suivant 2 cadres : - prsence du groupe fix au moment de la spcification, alors on utilise la technique de : - groupe d'attribut. - sous-classe ( ou hritage multiple ).

29

- si cette prsence peut changer pendant l'existence de l'objet, alors on utilise des objets contenus, crs et dtruits dynamiquement. - la dfinition d'un superclasse ( mme si elle n'est jamais instancie ) devra se faire ds que possible, si elle permet de regrouper diverses classes d'objets ( devenant des sous classes ) afin de faciliter les extensions futures. - la synchronisation entre diffrents objets doit tre parfaitement dfinie si il existe des relations entre ces diffrents objets. - la norme prvoit aussi la modlisation des relations entre les couches (N-1) et (N) ( =SAP : Service Access Point ). Les informations sont de 3 types : - informations contenues dans la couche ( N-1 ). - objets de la couche (N). - objets n'appartenant aucune de ces couches. Par ailleurs la norme prvoit aussi une collaboration entre couches ( en supprimant un peu l'ide d'indpendance entre couches ) afin d'viter la redondance de certains compteurs ( erreur locale, succs ou chec d'une transaction ...).

LA GESTION SNMP INTRODUCTION


Les rseaux locaux sous protocole IP sont apparus dans les annes 70 et ont connu depuis un essor important. Il a donc fallu trs rapidement des outils de gestion des rseaux TCP/IP interconnects. Pour cette raison, la communaut TCP/IP a concentr ses efforts sur deux protocoles : S.N.M.P : Simple Network Management Protocol. C.M.O.T : CMIS Over TCP/IP. Le protocole SNMP a pour but de rpondre rapidement au problme de gestion de rseaux TCP/IP alors que CMOT doit tre une solution plus long terme conforme la normalisation ISO. A l'origine, SNMP vient d'un ancien protocole : SGMP (Simple Gateway Monitoring) utilis pour la supervision des passerelles entre rseaux TCP/IP. SNMP est actuellement dominant dans le monde TCP/IP o il est le standard recommand depuis mai 1990. Son modle d'architecture repose sur un ensemble de composants de rseau (noeuds ou agents) et sur un ensemble de stations d'administration (station de gestion ou manager). Les managers sont chargs de surveiller les noeuds. Le rle du protocole SNMP est de vhiculer les informations de gestion entre managers et noeuds.

ARCHITECTURE SNMP
Cette architecture a t initialement dveloppe pour tre supporte par le systme d'exploitation UNIX sous protocole TCP/IP et fonctionner en mode datagramme sous le protocole UDP (User Datagram Protocol). Elle est compose par :

30

- un ensemble de noeuds grs, - une station de gestion centralise et - le protocole de gestion qui permet l'change d'informations.

NOEUDS GERES
Cela peut tre n'importe quel lment du rseau : une machine hte, une station de travail, un serveur, une imprimante mais aussi une passerelle, un pont, un modem, un multiplexeur... Chaque noeud support un agent serveur qui doit rpondre aux demandes d'informations et de prendre en compte les mesures correctives manant de la station de gestion client. Certaines machines peuvent avoir des protocoles propritaires non bass sur le protocole UDP. Dans ce cas, on peut utiliser des agents par procuration appels PROXY qui utilisent des mcanismes de translation de protocoles. L'agent proxy se comporte comme le reprsentant d'un ensemble de noeuds grs.

STATION DE GESTION
Une station de gestion est dfinie comme la station qui surveille l'tat du rseau. Elle demande priodiquement des informations aux diffrents agents. Cette station supporte donc, les oprations de gestion de rseau : 1) Elle collecte les informations provenant provenant de chacun des noeuds grs. 2) Elle maintient sa propre base d'information. Une station de gestion peut grer plusieurs noeuds et plusieurs stations de gestion peuvent grer des noeuds identiques.

PROTOCOLE DE GESTION :
Il spcifie la nature des communications entre un programme client, situ sur la station de gestion et un programme serveur qui s'excute sur un noeud. Le protocole SNMP est un protocole asynchrone de type requte / rponse, sans connexion qui utilise le protocole de transport UDP.

Structure Informationnelle
Linformation de gestion communique par les oprations du protocole est code dans une syntaxe qui correspond un sous-ensemble de la syntaxe 31

normalise ASN.1. Nous verrons les types dobjets utilisables et la structuration de ceux-ci regroups par groupes. rem : le terme objet correspond uniquement des variables informatiques classiques. Voici la macro ASN.1 utilise pour dfinir des objets SNMP : object type : object-type macro ::= begin type notation ::= syntax type (type ObjectSyntax) access Acces status Status value notation ::= value (value ObjectName) Access ::= read-only / read-write / write-only / none Status::= mandatory / optional / obsolete end La clause syntax permet de typer lobjet, la clause access permet de limiter lutilisation de lobjet, enfin la clause status dfinit le type dimplmentation.

LES TYPES DOBJETS


Il existe trois catgories de type dobjets utilisables : les types de base, les types structurs et les types dfinis. Les types tructurs sont limits aux listes (squence) et aux tables (squence de squences). Les types dfinis sont construits partir des types prcdents :

NetworkAdress : adresse issue dune des familles possibles de protocole (ex : internet.). IpAdress : adress internet sur 32 bits. Counter : entier non sign dont la valeur peut voluer jusqu une borne au-del de laquelle le compteur est remis zro. Gauge : entier non sign : compris entre 0 et 232-1. TimeTicks : entier positif qui cumule en centime de secondes le temps coul depuis une date initiale. Opaque : permet le passage entre une syntaxe ASN.A et une syntaxe arbitraire.

STRUCTURE DES OBJETS


Chaque agent localise ses informations dans la base de gestion et change les donnes avec sa gestion. La base de gestion (MIB) est un ensemble dlments parfaitement dfinis. Pour dsigner de faon unique et sans ambigut un lment dinformation, il est ncessaire de possder une rgle de nommage. Le terme didentifiant dobjet est utilis pour modliser cette rgle : elle est de type hirarchique. Un identifiant dobjet est une squence de nombres entiers qui traverse un arbre global constitu dune racine rattache par des arcs un certain nombre de noeuds tiquets. Ltiquette dun noeud

32

est lassociation dune courte description textuelle et dun entier: ISO 1, CCITT 2... La dsignation peut ainsi se faire de deux faons : 1) par un unique mnmonique : ISO.Org.DoD.Internet. 2) par une suite dentiers : 1.3.6.1. Exemple :

GROUPE DOBJETS
Les variables que gre SNMP sont regroupes en plusieurs listes :

SystemGroup : liste des informations de configuration. InterfacesGroup : liste des informations gnriques sur les interfaces. AtGroup : liste de traduction dadresse. IpGroup : liste des variables lies au protocole Internet Control Message Protocol. TCPGroup : liste des variables lies au protocole TCP UDPGroup : liste des variables lies au protocole UDP EGPGroup : liste obligatoire dans les noeuds qui implmentent Exterior Gateway Protocol. TransmissionGroup : liste apparue dans la version MIBII, regroupe lensemble des variables qui correspondent aux diffrents types dinterfaces, token-ring, loopback... SnmpGroup : liste apparue dans la version MIBII, liste des variables se rapportant SNMP.

Le Protocole SNMP
Emanation d'un ancien protocole SGMP (Simple Gateway Monitoring Protocol) utilis pour la supervision des passerelles TCP/IP. Protocole sans connexion bas sur le protocole UDP (User Datagram Protocol). SNMP traduit toutes les oprations en termes de lecture/criture.

trs simple comprendre, trs stable, trs simple implmenter.

Pour traduire en terme de lecture/criture, SNMP utilise 5 types d'opration : get-request, getnext, set- request, get-response, trap. De plus, nous allons voir le compromis propos par SNMP pour rsoudre le problme de la dtection dvnements sur un noeud . - get-request : lit le contenu d'une variable se trouvant dans la base de gestion. Il faut lui passer en argument le libell de la variable et l'agent dsir. La rponse est fournie grce get-response. Si le libell de la variable est invalide, la valeur NULL est retourn par le noeud gr : ex : snmp_get -h station1 SysDec.0 Cet appel retourne la valeur de la variable SysDec se trouvant sur la machine hte de nom station1.

33

- get-next : retourne le libell de la variable se trouvant aprs la variable passe en argument. Elle effecetue un parcours infix de larbre en ne sarrtant quaux feuilles. La rponse est fournie grce get-response : ex : snmp_get-next -h station2 IpRouteDest.0 Cet appel retourne lidentification de la variable qui suit la variable IpRouteDest.0 : soit IpRouteDest.1 (feuille suivante), soit un autre libell ce qui signifie que le programme a parcouru lensemble de la table. - set-request : affecte une valeur une variable sur un noeud donn. Elle retourne la valeur affecte la variable mme si l'affectation n'a pu avoir lieu. Elle permet aussi la cration et la suppression de variable : ex : snmp_set -h station2 IpRouteDest.0 OctetString HELLO Cet appel affecte la chane de caractres HELLO la variable IpRouteDest. - get-response : permet un noeud gr de rpondre une requte provenant d'une station de gestion. - trap : permet un noeud gr d'envoyer un message une station de gestion lorsqu'un vnement s'est produit sur le noeud. Lors d'un vnement sur un agent, il existe deux moyens pour la station de gestion dtre au courant de cet vnement : - l'agent envoye le compte-rendu de lvnement ds quil a lieu : surcharge du travail des agents, suppose que la station de gestion est prte, surcharge le rseau. - la station de gestion scrute priodiquement ltat des agents et aura donc le compterendu quand elle le dsirera : problme du choix de la frquence de scrutation. Pour bnficier des avantages des deux approches, SNMP propose un compromis : - lagent envoye juste un signal en cas dvnement. - la station de gestion a le loisir de demander au noeud un descriptif plus complet.

PROPRIETES
Nous dtaillons ici, deux points importants :

La scurit La distribution

LA SECURITE
La conjugaison d'un agent SNMP avec un ensemble d'entits d'application s'appelle une communaut SNMP. Chaque communaut SNMP est identifie par une chane d'octets, le nom de la communaut. Pour assurer la scurit des oprations de gestion, le protocole SNMP utilise la notion de message authentique qui se dfinit comme un message pour lequel on a contrl que l'entit d'application mettrice est bien membre de la communaut spcifie dans ce message.

34

Il est clair qu'une administration scurise utilisant des entits d'applications bties sur SNMP doit disposer de services 'authetification capables d'identifier les messages SNMP avec un fort taux de crdibilit. rem : certaines implmentations peuvent souhaiter ne supporter qu'un service d'authentification trivial, ce qui revient accepter tous les messages comme des messages authentiques.

LA DISTRIBUTION :
En matire de distribution, la politique retenue pour SNMP est la minimisation du nombre et de la complexit des fonctions de gestion et donc, de la charge de travail de la machine gre (noeud). Ceci a pour consquences :

rduction des cots de dveloppement logiciels des qgents de gestion ncessaires au support du protocole. limitation des restrictions des outils de gestion dvelopps sur les stations de gestion. assimilation rapide par les dveloppeurs d'outils de gestion d'ensembles simples de fonctions de gestion.

Exemples d'utilisation de SNMP


Nous allons voir dans cette partie des exemples d'utilisation de SNMP surveillance de l'tat du rseau, identification et rsolution des problmes de routage.

Surveillance de l'tat du rseau :


La station de gestion surveille l'tat du rseu en demandant priodiquement des informations chaque noeud par la requte getrequest. Elle collecte les informations provenant de chacun d'eux, afin de permettre l'administarteur de surveiller individuellement chaque noeud ainsi que les performances du rseau.

Identification et Rsolution des Problmes de Routage


La station de gestion doit pouvoir s'apercevoir qu'une passerelle est surcharge. Pour cela, une solution est d'implmenter une application sur chaque station de gestion locale chaque sousrseau qui dtermine par la requte get-request applique sur la variable IpInReceives le nombre de paquets qui arrivent sur chaque passerelle. Lorsque ce nombre dpasse un seuil fix, la requte trap permet d'informer l'administrateur du problme. En utilisant les requtes get-request et get-next , ce dernier peut localiser le problme de routage et grce set-request rsoudre le problme en modifiant les tables de routage.

CMOT et SNMP2
Nous allons voir successivement les apport de ces deux protocoles : 35

CMOT SNMP2

CMOT Le protocole CMOT est la migration du systme de gestion des rseaux TCP/IP vers la normalisation. Le groupe qui travaille sur CMOT s'est intgr l'OSI sous le nom de OIM (Osi Internet Management) L'architecture envisage pour CMOT consiste rajouter au-dessus des protocoles TCP et UDP une couche prsentation simplifie (LPP : Lightweight Presentation Protocol), les services d'application ACSE, et ROSE, le protocole CMIP et les services CMIS. Les diffrences essentielles entre SNMP et CMOT portent sur les relations entre managers et agents et sur la dfinition de la base de gestion (MIB). Dans CMOT, les relations sont en mode connect, la base de gestion est base sur la notion d'objets : les attributs et les mthodes.

SNMP2 Le protocole SNMP2 est une volution (comme son nom l'indique) du protocole SNMP. Les apports de SNMP2 :

plus de scurit au niveau de l'interrogation des agents. dialogue entre managers. amlioration des performances (communication uniquement en cas d'alerte).

PERFORMANCES
Avec SNMP, le Manager scrute priodiquement, tous les agents avec un intervalle de temps T : N < T/t N : nombre d'agents maximum. t : temps minimal d'une scrutation = mission de la requte + dlai de transmission + traitement dans le noeud + mission de la rponse + dlai de transmission + traitement dans le manager. Cette formule donne un N assez limit. Avec SNMP2 ou CMOT, la mthode employe est l'attente d'vnement. N sera beaucoup plus grand. ex : pour une mme frquence de rception : SNMP : 3160 agents. CMOT : 15 000 agents.

36

EXEMPLES D'ARCHITECTURE Exemples d'Architectures


Nous allons vous prsenter succintement HP Openview, Netview dIBM, ISM de Bull, Sunnet Manager de Sunsoft et quelques autres. De plus, on peut constater dans loffre actuelle une tendance regrouper la gestion de rseaux et la gestion de systmes dans les outils. HP Openview Fournisseur : Hewlett-Packard. Base d'informations de gestion : HP SMI (Structure of Management Information). modles proches de ceux de l'ISO. Fonctions : 6 :

get : extraction d'une donne appartenant un objet. set : criture d'une information appartenant un objet. create : cration d'une instance d'objet. delete : suppression d'une instance d'objet. action : active une action particulire d'un objet. event : envoi un vnement particulier vers des objets.

Standard de fait potentiel. Netview Fournisseur : I.B.M. Structure Gnrale : Architecture Hirarchique deux niveaux. Standard de fait potentiel. ISM Fournisseur : Bull. Proprits :

Base de donnes distribue oriente objet. Architecture horizontale. Utilise le protocole CMIS : sans imposer un type d'agent (CMIP, SNMP, ou autres).

Faiblesse : Son march reste encore relativement faible.

37

Sunnet Manager Fournisseur : Sunsoft. Proprits : Une des trois (avec IBM et HP) principales plates-formes. Futur :

Une nouvelle plate-forme : Solstice Enterprise Administration de systmes. Accepte diffrents protocoles. Partenariat auquel participent de grands fournisseurs ( Computer Associates, Legent, Open Vision, Compuware, Tivoli...) Approche Objets.

Autres

Tivoli - Fournisseur : Tivoli. Systems Management Server - Fournisseur : Microsoft (que sous Windows/NT, pour des clients Microsoft) Unicenter - Fournisseur : Computer Associates. (gestion de systmes surtout). XPE - Fournisseur : Legent. (gestion de systmes surtout).

Ce graphe reprsente le domaine couvert par chacun des outils.

Conclusion
SNMP garde largement l'avantage sur CMIP : d'un ct un protocole (SNMP) simple qui est fortement utilis et de l'autre (CMIP), un protocole largement suprieur mais pas d'offre. L'usager n'a pas le choix. En thorie, il y a un partage du monde des rseaux entre ces deux protocoles :

SNMP pour les rseaux locaux. CMIP pour celui des tlcommunications et des oprateurs.

MAIS, SNMP commence prendre des parts de march sur le territoire de CMIP : SAT, constructeur tlcoms a, fin 1993, opt pour SNMP. Ceci est peut-tre d au fait que l'ATM mergera probablement d'abord dans les rseaux locaux grs par SNMP. Cependant, de plus en plus, les constructeurs de plates-formes ouvertes d'administration de rseau offrent les deux protocoles. Dans ce domaine, l'offre est trs jeune. Aucun produit ne s'impose vraiment comme rfrence. Et de plus en plus, la notion de gestion de rseaux est couple celle de gestion de systmes distribus.

Lexique
ACSE : 38

Application Control Service Element. AE : Application Entity. AP : Application Process. ASE : Application Service Element. ASN.1 : Abstract Syntax Notation. CCITT : Comit Consultatif International Tlgraphique Tlphonique. CMIP : Common Management Information Protocol. CMIS : Common Management Information Service. CMISE : Common Management Information Service Element. CMOT : CMIS Over TCP/IP. ISO : International Standard Organization. LAN : Local Area Network. OIM : OSI Internet Management. ROSE : Remote Operation Service Element. RTSE : Reliable Transfer Service Element. SGMP : Simple Gateway Monitoring Protocol. SNMP : Simple Network Management Protocol.

39

UDP : User Datagram Protocol. WAN : Wide Area Network.

Bibliographie
GESTION DES RESEAUX INFORMATIQUES : JP et M Claude - Ed Eyrolles - 1993. GESTION DE RESEAUX : Arpege - Ed Masson - 1992. RESEAUX LOCAUX : Samuel Pierre - Ed Eyrolles - 1991. COMPRENDRE LES RESEAUX D'ENTREPRISE : Philippe Gomez et Pierre Bichon - Ed Eyrolles - 1993. 01 INFORMATIQUE : Num : 1345 - 17/02/95 - Dossier Administration de Systemes.

40