SlideShare une entreprise Scribd logo
1  sur  80
Télécharger pour lire hors ligne
REPUBLIQUE TUNISIENNE
Ministère de l’Enseignement Supérieur, de la Recherche scientifique et de la
Technologie
Université Privée Montplaisir Tunis
Agrément N° 01-2001
PROJET DE FIN D’ETUDE
POUR L’OBTENTION DU
Diplôme National d’Ingénieur
En
Réseaux et Télécommunications
Elaboré par :Tidiane Sylla
Encadreurs :Dr Salem Hasnaoui
Mr Cherif Rezgui
Année Universitaire 2011-2012
Université Privée Montplaisir Tunis
Site web : http ://www.fmci.ens.tn - Email : contact@fmci.ens.tn
UMT Quartier Montplaisir Rue Aboubaker El Bokri 1073 Tunis Tunisie
Tel : (216) 71 901 660 / Fax : (216) 71 904 425
Au Nom d’ALLAH, Le Tout Miséricordieux, Le Très
Miséricordieux
À mes chers Parents, À mon Père et ami de mon Père Mohamed Nimaga,
qui ont toujours été présent malgré la distance, qui m’ont soutenus et accom-
pagnés de “Dou’a” et de “Baraka” tout au long de mon parcours.
i
Remerciements
Je suis profondément reconnaissant à mes deux encadreurs Mr Cherif Rezgui et Mr Salem Hasnaoui
pour m’avoir fait le grand honneur de diriger mon projet dans les meilleures conditions, ainsi que pour
leurs encadrements, leurs conseils et leurs disponibilités.
Je témoigner ma reconnaissance à Monsieur Slaheddine Jarboui pour son aide pour l’obtention de
ce stage à Tunisie Telecom. Je remercie également Mr Imed Toumi, Mr Houssem Jarraya, Mr Abdallah
Abaza, Mr Maher Ben Hassine, Mr Saber Ben Gharbia, Mr Soufiane Mathloulhi, et à Mr Saif Eddine
Abidi pour leurs aides précieuses, leurs conseils et les facilités qu’ils m’ont offert au sein du NOC DATA,
ainsi que tous le personnel de la Direction Exécutive des Backbones pour leurs collaborations.
Comme je n’y manquerai pas de remercier mes professeurs, membre du Jury pour l’honneur qu’ils ont
fait en acceptant de faire partie de mon Jury.
Je remercie également tous ceux qui de près ou de loin ont contribués à l’élaboration de ce rapport.
ii
Résumé
Durant ce projet, nous nous sommes intéressés aux points suivants relatifs au Backbone ATM Nortel
de Tunisie Telecom. Le premier point concerne le problème du travail en ligne de commandes. Le deuxième
point concerne l’archivage des configurations des différents commutateurs. Pour remédier à ce problème,
nous avons mis en place un processus de sauvegarde automatique et périodique. Le troisième point
s’attache à la gestion des alarmes et à la gestion de la congestion des liaisons inter-sites, pour ce faire nous
avons développé un processus pour le recueil des alarmes générées par les commutateurs et l’avertissement
des opérateurs de ces incidents, et mise en place un service pour la supervision du trafic des liaisons inter-
sites ce qui permet d’éviter toutes congestions sur ces liaisons.
Mots clés : Backbone, ATM, Frame Relay, Backup, SNMP, Telnet, FTP, NMS.
Abstract
During this project, we were interested in the following points relating to Nortel ATM Backbone
of Tunisie Telecom. The first concerns the problem of working on the command line. The second point
concerns the archiving of configurations of different switches. To remedy this problem, we set up a backup
process automatic and periodic. The third point focuses on alarm management and management of inter-
site congestion, to do this we have developed a process for collecting alarms generated by the switches
and warning operators of these incidents, and setting up a service for monitoring inter-site traffic which
avoids any congestion on these routes.
Key words : Backbone, ATM, Frame Relay, Backup, SNMP, Telnet, FTP, NMS.
iii
Table des matières
Dédicaces i
Remerciements ii
Résumé iii
Liste des acronymes vi
Table des figures x
Introduction Générale 1
1 Présentation du Projet 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Backbone ATM de Tunisie Telecom 5
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Les équipements d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Les équipements du Cœur du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 La gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 But et domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2.1 L’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2.2 La supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2.3 La maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Principes de la gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5 Le Protocole Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.6 Autres protocoles de gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.7 Gestion du réseau de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . . 17
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iv
TABLE DES MATIÈRES v
3 Conception 18
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1 La spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Les exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3 Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.4 Identification des utilisateurs du système . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Spécification des exigences d’après les cas d’utilisation . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 Identification des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Traçabilité avec exigences textuelles . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Spécification détaillée des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Diagramme de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Diagramme d’états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Implémentation 43
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Technologie de développement web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Le service TraficInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2 Le service AlarmeManage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3 Le service BackupAuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.4 NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Conclusion Générale 58
A L’ATM 59
Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.1 L’adressage dans le réseau ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2 La couche Physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.3 La qualité de service QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.4 La signalisation et le routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B Frame Relay 64
Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.1 Circuits virtuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.2 Le contrôle d’admission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Bibliographie 68
Liste des acronymes
AAL ATM Adaptation Layer
Aal1Ces ATM Adaptation Layer 1 Circuit Emulation Service
ABR Available Bit Rate
ADSL Asymetric Digital Subscriber Line
AJAX Asynchronous Javascript And XML
API Application Programming Interface
ASN Abstract Syntax Notation
ASP.NET Active Server Page .NET
ATD Asynchronous Time Division
ATM Asynchronous Transfert Mode
BC Burst Committed Size
BE Burst Excess Size
BECN Backward Explicit Congestion Notification
B-ISDN Broadband - Integrated Service Digital Network
CBR Constant Bit Rate
CCS Common Channel Signaling
CIR Commited Information Rate
CLLM Consolided Link Layer Management
CLR Common Language Runtime
CMIP Common Management information Protocol
CMIS Common Management information Service
CNET Centre Nationale Etude et de Télécommunication
DCE Data Communication Equipment
DLCI Data Link Connection Identifier
DNA Data Network Address
DS0 Digital Signal 0
DSLAM Digital Subscriber Line Access Multiplexer
DTE Data Terminal Equipment
E1 E-Carrier 1
EIR Excess Information Rate
ETTD Equipement Terminal de Traitement de Données
FECN Forward Explicit Congestion Notification
vi
TABLE DES MATIÈRES vii
FR Frame Relay
FRAD Frame Relay Access Device
FRUNI Frame Relay User Network Interface
FSI Fournisseur de Services Internet
FSM Finite State Machine
FTP File Transfert Protocol
FTPS File Transfert Protocol Secure
HTML Hyper Text Markup Language
HTTPS Hyper Text Transfert Protocol Secure
IDE Integrated Development Environment
IETF International Engineering Task Force
IISP Interim Inter Switching Protocol
IP Internetworking Protocol
LAN Local Area Network
LMI Local Management Interface
LP Logical Processor
LS Liaison Spécialisée
MIB Management Information Base
MPLS Multi-Protocol Label Switching
MSA32 Multi Service Access 32
NMS Network Management System
NNI Node Network Interface
OC-X Optical Carrier – X
OID Object IDentifier
OSI Open Systems Interconnexion
PNNI Private Network to Network Interface
POP Point Of Presence
PVC Permanent Virtual Circuit
QoS Quality of Service
RDLCI Remote Data Link Connection Identifier
RDNA Remote Data Network Address
RFC Request For Comment
RNIS Réseau Numérique à Intégration de Service
SDH Synchronous Digital Hierarchy
SDSL Symetric Digital Subscriber Line
SMI Structure of Managed Information
SMTP Simple Mail Transfert Protocol
SNMP Simple Network Management Protocol
TABLE DES MATIÈRES viii
SOAP Simple Object Access Protocol
SONET Synchronous Optical Network
SS7 Signaling System 7
SSH Secure Shell
SSL Secure Sockets Layer
STM-1 Synchronous Transfert Mode 1
SVC Switched Virtual Circuit
TCP Transmit Control Protocol
TDM Time Division Multiplexing
TLS Transport Layer Security
UBR Unspecified Bite Rate
UDP User Datagram Protocol
UIT Union International des Télécommunications
UML Unified Modeling Language
UNI User Network Interface
UP Unified Process
VBR-NRT Variable Bit Rate - Non Real Time
VBR-RT Variable Bit Rate - Real Time
VCC Virtual Circuit Connection
VCI Virtual Circuit Identifier
VES Virtual Execution System
VP Virtual Path
VPI Virtual Path Identifier
VSS Variable Speed Switch
XML eXtensible Markup Language
Table des figures
2.1 Exemple de Liaison Frame Relay sur ATM . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Exemple de Liaison Spécialisée à émulation de circuit sur ATM . . . . . . . . . . . . . . . 6
2.3 Réseau maillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Réseaux d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Nortel Passport 7480 El Kasbah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Nortel Passport 15000-VSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 Réseau ATM Nortel de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8 Relations entre manager, agents et protocole . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Architecture SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 Structure d’indexation des données dans la MIB-2 SNMP . . . . . . . . . . . . . . . . . . 15
2.11 Exemple de session Telnet sur un commutateur Nortel 7480 . . . . . . . . . . . . . . . . . 16
2.12 Gestion In-band sur le réseau ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Création des exigences dans Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Synoptique de la démarche de construction du modèle des cas d’utilisation, [Roques :2008}] 22
3.3 Acteurs du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Organisation des cas d’utilisation et des acteurs en packages (avec l’outil Enterprise Ar-
chitect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Cas d’utilisation création de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Cas d’utilisation modification de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 Cas d’utilisation supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Cas d’utilisation exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 Cas d’utilisation maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 Organisation complétée des cas d’utilisation et des acteurs . . . . . . . . . . . . . . . . . . 27
3.11 Matrice de traçabilité entre cas d’utilisation et exigences . . . . . . . . . . . . . . . . . . . 28
3.12 Diagramme de séquence système Créer une liaison Frame Relay port et circuit . . . . . . 33
3.13 Diagramme de séquence système Créer une liaison spécialisée émulée sur ATM . . . . . . 34
3.14 Diagramme de séquence système Lister les abonnés . . . . . . . . . . . . . . . . . . . . . . 34
3.15 Diagramme de séquence système Afficher les circuits virtuels d’un lien Physique Frame Relay 35
3.16 Diagramme de séquence système Gérer les multiplexeurs . . . . . . . . . . . . . . . . . . 35
3.17 Diagramme de séquence système Backup des configurations . . . . . . . . . . . . . . . . . 36
3.18 Diagramme de séquence système Gérer les espaces disque . . . . . . . . . . . . . . . . . . 36
3.19 Diagramme de séquence système Examen de la boucle locale . . . . . . . . . . . . . . . . 37
3.20 Diagramme de séquence supervision du trafic . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.21 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.22 Diagramme d’état Création liaison FR port et circuit . . . . . . . . . . . . . . . . . . . . . 40
3.23 Diagramme d’état Supervision du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
ix
TABLE DES FIGURES x
3.24 Diagramme d’état : Gérer l’espace disque . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.25 Schéma Conceptuel de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Ensemble Framework .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 IDE Microsoft Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Architecture du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Schéma de fonctionnement du service TraficInfo . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Fonctionnement du service AlarmeManage . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Fonctionnement du service BackupAuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7 Page de configuration de la sauvegarde automatique . . . . . . . . . . . . . . . . . . . . . 48
4.8 Page de connexion au NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.9 Page d’accueil du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.10 Listing des cartes d’un commutateur Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.11 Les lignes de la carte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.12 Les détails d’une ligne E1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.13 Page de création d’une nouvelle liaison Frame Relay . . . . . . . . . . . . . . . . . . . . . 51
4.14 Page de résumé Création Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.15 Création d’une LS à émulation de circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.16 Résumé de Création d’une LS à émulation de circuit . . . . . . . . . . . . . . . . . . . . . 52
4.17 Liste des abonnés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.18 Informations détaillées sur une liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.19 Test d’une liaison Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.20 Graphe d’évolution du trafic en fonction du temps . . . . . . . . . . . . . . . . . . . . . . 54
4.21 Occupation de l’espace disque d’un commutateur . . . . . . . . . . . . . . . . . . . . . . . 55
4.22 Sélection des fichiers à supprimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.23 Alarme(s) détectée(s) par NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.24 Liste des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.25 Traitement des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A.1 Format d’une cellule ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.2 La double identification d’ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.3 Architecture ATM, [Servin :2003] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.4 La signalisation dans ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.1 Représentation basique Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.2 Identification des liens logiques par le DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.3 Contrôle de gestion dans les réseaux haut débit . . . . . . . . . . . . . . . . . . . . . . . . 67
B.4 Contrôle de gestion dans les réseaux haut débit . . . . . . . . . . . . . . . . . . . . . . . . 67
B.5 Echange de message synchrone sur l’état des liens . . . . . . . . . . . . . . . . . . . . . . 68
Introduction Générale
L
es réseaux de télécommunications touchent de plus en plus notre vie quotidienne. On compte sur
les services offerts par les réseaux pour assurer les transactions bancaires, les recherches web, la
téléconférence. Les services rendus par les réseaux sont devenu indispensable. Face à cette évolution,
Tunisie Telecom a élargie et diversifiée son réseau qui est devenu complexe.
Pour gérer un tel réseau, et assurer la qualité des services qu’il rend, Tunisie Telecom doit recourir
à des applications très évoluées et intelligentes qui permettent de surveiller le réseau, de l’exploiter,
et d’agir quand un problème survient. Mais le coût de développement de ces applications par les tiers
(équipementiers, sociétés de développement, etc. . . ) est excessivement élevé.
Tunisie Telecom utilise les compétences de ses cadres pour le développement de telles applications.
C’est dans ce cadre que s’inscrit notre projet. Le projet que nous avons réalisé consiste au développement
d’une application de gestion des commutateurs ATM Nortel de Tunisie Telecom. A la fin de ce projet,
l’application qui sera développée, devra être un outil à part intégrante pour les agents du NOC (National
Operation Center) et ROCs (Regional Operation Centers) DATA de la direction exécutive des Backbones
de Tunisie Telecom.
Le premier chapitre sera réservé à la présentation de Tunisie Telecom, du cadre général du projet, ainsi
qu’à la problématique et à l’objectif fixé pour notre projet.
Le deuxième chapitre s’articulera autour de la description du Backbone ATM de Tunisie Telecom ainsi
que de sa gestion.
Le troisième chapitre sera consacré à la conception de la future application.
Le quatrième chapitre présentera les outils et l’environnement de développement, le développement des
services et de l’application lui-même.
1
Chapitre 1
Présentation du Projet
Introduction
Dans ce chapitre, nous allons présenter notre stage. Pour se faire, nous présentons d’abord notre
organisme d’accueil à savoir ‘Tunisie Telecom’, par la suite nous décrirons la problématique et les objectifs
spécifiques à atteindre de notre projet.
1.1 Présentation de l’organisme d’accueil
Le 1er janvier 1996, l’office national des télécommunications (ONT) ou « TUNISIE TELECOM » est
entrée en activité en tant qu’opérateur de télécommunication doté de sa propre autonomie et son propre
réseau (sous la forme juridique d’établissement public à caractère industriel et commercial).
Tunisie Télécom a pour mission d’assurer toutes les activités relatives au domaine des télécommuni-
cations :
– La coopération avec les organismes similaires et l’application des traités internationaux en matière
de télécommunication
– L’installation, le développement, l’entretien et l’exploitation des réseaux publics de télécommuni-
cation et en particulier, les réseaux de téléphone et de transmission de données.
– La promotion de nouveaux services de télécommunication à travers l’installation de l’équipement
technologique dans le domaine la contribution au développement aux études et recherches scienti-
fiques liées au secteur des télécommunications.
National operating Center – NOC DATA Sous tutelle de la Direction des Backbones, Le NOC
DATA, est le centre national des opérations de gestion, de maintenance, et de supervision des réseaux de
transmission de données à l’échelle nationale.
Il a pour tâche :
– La gestion des équipements de transmission de données (Commutateurs, Multiplexeurs, DSLAM
etc.)
– L’administration des équipements (la sauvegarde des fichiers de configurations. . . )
– La supervision des réseaux de transmission sur tout le territoire national 24h/24 et 7j/7
– La Supervision des températures des équipements ;
– Supervise les alarmes sur les équipements sur les liaisons ;
– Ouverture des tickets pour les conservés (CTDR, Centre de transmission) ;
2
CHAPITRE 1. PRÉSENTATION DU PROJET 3
– La gestion des abonnés :
– L’étude des nouvelles demandes des liaisons de transmission de donnée (LS national et interna-
tional, frame Relay, SDSL, et etc.), depuis la saisie dans l’ACTEL (agence commerciale) jusqu’à
la mise en service par le CTDR (centre de transmission de Données régional) concerné.
– Les configurations nécessaires pour la mise en service des créations des nouveaux abonnés tel que
Frame Relay, ligne spécialisée national et international, ADSL, SDSL, et ATM.
Le NOC comprend des groupes de soutien qui ont pour tâche :
– Configuration des nouveaux sites, installation, Backup, mise à jour de nouvelles cartes
– Intervenir dans les grands problèmes sur les réseaux
– Suivre la stabilité des réseaux
– Mise à jour des DSLAM (upgrade : nouveau soft)
– Basculement des sites, trafic
– Statistique sur les liaisons internes (inter-sites) pour détecter s’il y a une congestion et d’améliorer
la qualité du trafic
– Et etc.
1.2 Problématique
Dans la situation actuelle, le traitement des requêtes de nouvelle connexion Frame Relay, de liaison
spécialisée émulée sur ATM, la supervision des lignes Frame-Relay, la gestion des espaces disque, etc. . .
se font en ligne de commandes. Le problème de gestion de la congestion des liaisons inter-sites. Vu le
nombre important de tâches, il est très fastidieux de les effectuer en ligne de commandes, il n’offre pas
une vue synthétique de l’infrastructure, les erreurs de configurations sont très fréquentes. La sauvegarde
manuelle des fichiers de configuration des commutateurs entraine souvent leurs pertes et parfois l’oublie
de la sauvegarde de ces fichiers sont suivi de conséquences désastreuses. Tous ces problèmes causent une
mauvaise exploitation des ressources disponibles et une grande perte de temps.
Pour maintenir ces réseaux opérationnel et disponible, des techniques et des outils avancés ont dû
être inventés pour assurer son fonctionnement et son administration. Notre projet vise à remédier à des
problèmes tels que :
– Travail fastidieux, et entrainant une grande perte de temps en ligne de commandes
– Sauvegarde manuelle des fichiers de configuration
– Manque de suivi efficace des commutateurs ATM Nortel (Volume de trafic, états des interfaces,
espace disque, alarmes . . . )
– Gestion de la congestion des liaisons inter-sites. . .
1.3 Objectifs
Le NOC DATA de Tunisie Telecom a décidé de se doter d’un outil de travail efficace et performant
qui leur permettra de remplir plus amplement les différentes missions qui les ont été confié et de remédier
aux nombreux problèmes cités ci-dessus.
L’objectif fondamental de ce projet est de permettre aux utilisateurs de créer des liaisons Frame
Relay, de liaisons spécialisée émulée sur ATM, de mieux gérer la congestion, de superviser en temps réel
les liaisons inter-sites, la gestion automatique de la sauvegarde des fichiers de configurations etc. . . via
une interface web interactive et attractive. Cette application sera particulièrement utile dans l’exécution
des différentes tâches assignées aux agents du NOC DATA de Tunisie Telecom.
CHAPITRE 1. PRÉSENTATION DU PROJET 4
L’application devra donc être facilement évolutive pour pouvoir implémenter très rapidement de nou-
velles fonctionnalités importantes.
Conclusion
Au terme de ce chapitre, nous avons présenté l’organisme d’accueil, et dégagé la problématique. Nous
avons également défini les objectifs de notre projet. Le prochain chapitre sera consacré au Backbone ATM
de Tunisie Telecom.
Chapitre 2
Backbone ATM de Tunisie Telecom
Introduction
Littéralement appelé épine dorsale ou encore cœur du réseau, le Backbone constitue le centre névral-
gique du réseau de transport de données à l’échelle d’un territoire national. Sur ce réseau viennent se
greffer les réseaux des fournisseurs de services internet, des réseaux de grandes entreprises, etc. C’est la
partie qui supporte le gros du trafic, en utilisant les technologies de transmission de données les plus
rapides et une grande bande passante sur des distantes importantes. Les liaisons qui forment le Backbone
sont constituées majoritairement de câble à fibres optiques. A Tunisie Telecom, ce réseau fédérateur est
subdivisé en deux parties : Le Backbone ATM et le Backbone IP/MPLS. La suite de ce chapitre sera
consacrée au Backbone ATM et de sa gestion.
2.1 Description
Le Backbone ATM national dont Tunisie Telecom s’occupe de son évolution ainsi que de sa gestion
est constitué de près de 20 commutateurs ATM Nortel et de 20 commutateurs ATM Alcatel éparpillé sur
tout le territoire tunisien. Ces commutateurs sont caractérisés par leur bonne performance, ils assurent
une couverture maximale du pays, leur fonction principale est de permettre un transport fluide et efficace
du trafic transitant sur le Backbone.
Les clients ne sont pas directement connectés via les commutateurs principaux, mais à travers des
multiplexeurs d’accès qui sont à leurs tours connectés aux commutateurs d’accès qui permettent d’assurer
l’interconnections des différents types d’utilisateurs (LS, FR, ADSL). Les clients sont essentiellement les
banques, les grandes entreprises, les Fournisseurs de services internet FSI, les agences nationaux ou
internationaux, etc.
Figure 2.1 – Exemple de Liaison Frame Relay sur ATM
5
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 6
Figure 2.2 – Exemple de Liaison Spécialisée à émulation de circuit sur ATM
Le Backbone ATM de Tunisie Telecom est un réseau maillé. Un réseau maillé, est un réseau dans
lequel deux stations, clientes du réseau, peuvent être mis en relation par différents chemins (figure 2.3).
Ce type de réseau, permettant de multiple choix de chemins vers une même destination, est très résistant
à la défaillance d’un nœud et autorise une optimisation de l’emploi des ressources en répartissant la charge
entre les différents nœuds. Cela permet d’éviter d’avoir des points sensibles, qui en cas de panne, coupent
la connexion d’une partie du réseau.
Figure 2.3 – Réseau maillé
Pour assurer la fiabilité du Backbone, une architecture redondante est mise en place pour l’intercon-
nexion des commutateurs principaux. Un site doit être relié au moins à deux sites différents pour assurer
à la fois le basculement du trafic en cas de panne ainsi que le partage de charge (Load Balancing) en
cas de congestion. En effet la redondance est une caractéristique essentielle au fonctionnement d’un tel
réseau.
Le terme redondance est utilisé pour désigner deux serveurs ou deux cartes de contrôles (Contient
la configuration du commutateur) dédoublé. Si l’un des serveurs tombe en panne le deuxième prend
automatiquement le relais empêchant ainsi l’arrêt de la supervision du réseau ; un seul des deux (peut
être plusieurs) fonctionne à la fois, le second démarrant qu’en cas de panne du premier. En effet les
serveurs permettent de bien assurer la surveillance du réseau. Pour les cartes de contrôles, la redondance
permet d’éviter l’arrêt d’une portion du réseau si la première carte tombe en défaillance, la deuxième
prendra automatiquement la relève. C’est un atout majeur pour un réseau en production car il permet
au réseau d’assurer une très grande fiabilité.
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 7
2.2 Architecture
Le Backbone multiservices ATM/Frame-Relay Nortel est constitué de commutateurs d’accès, commu-
tateurs principaux et de multiplexeurs d’accès.
2.2.1 Les équipements d’accès
Les multiplexeurs d’accès permettent le multiplexage et le démultiplexage des flux des différents clients
en entrée et en sortie du réseau. Les multiplexeurs d’accès multiservice rassemblent, brassent les flux en
provenance du client vers le réseau IP/MPLS, ATM, International, etc. sur des liens à fibres optiques,
paire torsadée. Ces unités sont au sein des points de présence (POP : Point Of Presence) appartenant à
Tunisie Telecom.
Figure 2.4 – Réseaux d’accès
Un multiplexeur a une ou plusieurs liaisons avec d’autres multiplexeurs pouvant être Master ou Slave.
Le terme Master (Maitre) ou Slave (Esclave) désigne le fait que la gestion du multiplexeur Slave s’effectue
via le multiplexeur Master.
Le multiplexeur d’accès (figure 2.4) fait passer le trafic à destination du Backbone IP/MPLS (Internet
Protocol/Multi Protocol Label Switching) sur une liaison STM-1 (Synchronous Transfert Mode-1 équi-
valent de 155 Mbps) à fibre optique jusqu’au routeur MPLS. Le trafic destiné au Backbone ATM passe
par une liaison E1/T1 (2 Mbps) jusqu’au commutateur d’accès ATM. Il assure également à travers un lien
2 Mbps une liaison international, cette liaison est généralement attribuée aux ambassades, aux centres
d’appels et d’autres entreprises étrangères. Une autre liaison 2 Mbps peut être attribuée aux fournisseurs
de services internet FSI souhaitant avoir des clients qui veulent des liaisons spécialisées internet.
Les multiplexeurs d’accès utilisés par Tunisie Telecom sont des multiplexeurs Patton, Paradyne et
Sagem.
2.2.2 Les équipements du Cœur du réseau
Les commutateurs d’accès ATM sont des commutateurs situés au bord du Backbone ATM de Tunisie
Telecom, faisant eux même parties du Backbone. Ils connectent les réseaux locaux (LAN) des utilisateurs
finaux au réseau fédérateur de l’opérateur. Ils permettent également la conversion des trames provenant
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 8
des LAN du client en des cellules ATM et vice versa. Ils l’établissement de circuit virtuel dans le réseau
ATM et envoient le trafic sur le Backbone ATM. Ils agrègent les liens de faible débit à partir des réseaux
clients en très haut débit sur le Backbone et vice versa.
Les commutateurs principaux sont des commutateurs de très grandes capacités placés dans le cœur
du réseau (Backbone) et servant à interconnecter des commutateurs d’accès. Bien que ces commutateurs
peuvent être très intelligent, ils ne fonctionnent que dans la couche 2 du modèle de référence OSI (Open
Systems Interconnection). Encore appelés brasseurs, ils assurent la commutation de faisceaux virtuels en
interne dans le réseau. La gamme Nortel Passport 7480 est utilisée comme commutateurs d’accès.
Commutateur Nortel Passport 7480 :
Le Commutateur Nortel Passport 7480 livre une gamme puissante d’interfaces à base de norme et des
services, y compris Frame Relay, l’ATM et IP. Le Passport 7480 offre l’acheminement des services multi
protocoles, la gestion intelligente du trafic et supporte simultanément la voix, des données, la vidéo et
l’image. Il offre une très grande fiabilité et la redondance exigée par les fournisseurs de services.
Il est composé de deux Control Processor (CP) et de Function Processors (FP). Le Control Processor
(CP) contrôle tout le traitement qui s’effectue dans le commutateur. Il gère les FPs (Function Processors)
sur le Shelf (étagère sur lequel sont rangés les FPs) et fournit des fonctionnalités systèmes de base telles
que la surveillance du Self et le traitement alarmes. Le CP fournit également l’horloge du bus, le stockage
de fichiers, la collecte de données, le maintien de la table de routage à jour, le traitement des commandes,
et des interfaces pour la gestion. Le commutateur Passport 7480 comprend deux CP, l’un actif et le
deuxième en standby (veille). Si le premier tombe en panne, le second prend la relève.
Les Function Processors(FPs) sont des d’interfaces de communications qui relient les segments réseaux
au commutateur. Ils permettent l’exécution en temps réel des processus qui sont essentiels à la prestation
des services (réseaux). Chaque FP supporte un ou plusieurs services. On peut citer entre autre E1 MSA32
(Multi Service Access) Function Processor, E3 Function Processor, OC-3 Function Processor etc...
Dans le cadre des télécommunications numériques, où une simple paire physique de fils peut être
utilisée pour transporter de nombreuses communications vocales simultanées au moyen du multiplexage
temporel TDM (Time Division Multiplexing), des standards à l’échelle mondiale ont été créés et déployés.
La Conférence Européenne des administrations des Postes et Télécommunications (CEPT) a standardisé
le système E-carrier, qui pourrait se traduire en transporteur E. Ce nouveau standard constitue une révi-
sion et une amélioration de la précédente technologie américaine T-carrier. E-carrier est à présent adopté
par l’Union Internationale des Télécommunications, section de la standardisation des télécommunications
(UIT-T). E-carrier est à présent utilisé dans presque tous les pays de la planète hors des États-Unis, du
Canada et du Japon. Un E1 transporte 32 tranches temporelles (Time Slots) et un E3 en transporte
512, dont une tranche servant à délimiter les trames. Chaque tranche de temps transporte un DS0 (64
Kbps) soit l’équivalent de 2 Mbps pour E1 et 34 Mbps pour E3. Les circuits E1 sont très utilisés pour
connecter des entreprises de moyenne ou grande taille, des commutateurs distants et la plupart du temps
entre commutateurs. Les lignes E3 sont utilisées entre commutateurs, entre les opérateurs et fournisseurs
de services internet (ex : Globalnet, Planet).
Basé sur un signal optique multiple de 51,84 Mbps, le standard OC (Optical Carrier) a été défini selon
le modèle SONET (Synchronous Optical Network). Il répertorie plusieurs types de lignes en fonction de
leur débit. Sa syntaxe est OC-x avec le x comme coefficient multiplicateur. OC-3 est l’équivalent de
3*51,84 = 155 Mbps. L’équivalent d’OC-3 dans la hiérarchie SDH (Synchronous Digital Hierarchy) en
europe est STM-1.
Le Passport 7480 comprend plusieurs 3 ports OC-3 qui permet de relier aux commutateurs princi-
paux et à d’autres commutateurs d’accès. Il comprend également plusieurs cartes E1 MSA-32, et qui
comprennent chacun 32 E1. Chaque E1 supporte simultanément plusieurs types de services Frame Relay,
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 9
AAL1 Circuit Emulation Service (Aal1Ces), ATM Service et etc.
Figure 2.5 – Nortel Passport 7480 El Kasbah
La gamme Nortel Passport 15000-VSS est utilisée comme commutateurs principaux.
Commutateur Nortel Passport 15000-VSS (Variable Speed Switch) :
Le commutateur Nortel Passport 15000-VSS est un combiné de commutateur d’accès et de commuta-
teur principal multiservices. En plus de l’ATM, il délivre un large éventail d’interfaces et services très haut
débit basés sur standard, y compris le Frame Relay, l’émulation de circuit, la voix et l’IP. Ces interfaces
fournissent une grande variété d’accès et d’agrégation de vitesse de DS-0 (64 Kbps) à OC-48 (2 488,32
Mbps). Il est composé du Passport 7480 et du Passport 15000. Le Passport 15000 est un commutateur
de données basé sur ATM qui peut être déployé comme commutateurs principal pour un réseau de com-
mutateurs d’accès existant. En outre de l’ATM, il délivre une gamme puissante d’interfaces et de services
basés sur des standards y compris le Frame Relay et IP. Il offre une très grande redondance, d’évolutivité
et une très grande capacité d’agrégation et d’intégration SDH/SONET (optionnel).
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 10
Figure 2.6 – Nortel Passport 15000-VSS
En outre de leur capacité de gestion intelligente du trafic, ils supportent simultanément les trafics
de la voix, les données, la vidéo et l’image, en un mot des commutateurs multiservices. Ils offrent une
redondance complète, évolutive à grande capacité, haute vitesse d’accès et de raccordement au réseau. De
configuration matérielle et logiciel modulaire, on peut modifier la configuration des composants matériels
et logiciels pour chaque site selon les besoins.
Figure 2.7 – Réseau ATM Nortel de Tunisie Telecom
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 11
2.3 La gestion de réseau
Le Backbone ATM de Tunisie Télécom est l’un des réseaux les plus étendus dans toute la Tunisie.
Devant la complexité d’un tel réseau, le concept gestion de réseau est devenu une nécessité afin d’assurer
son administration et pouvoir faire des prévisions.
2.3.1 But et domaine d’application
La notion de gestion s’applique essentiellement dans un contexte de réseau privé. L’idée maîtresse
de la supervision est de contrôler la fiabilité et la pérennité du réseau, des services informatiques afin
de mesurer la Qualité de Service (QoS, Quality of Service). Cette notion de QoS n’est pas récente,
mais elle est devenue le point d’intérêt central des stratégies de développement d’entreprise. La situation
économique actuelle peu favorable exige des entreprises qu’elles contrôlent leurs dépenses. La tendance
n’est pas à l’investissement dans de nouvelles technologies, mais à l’optimisation et au rendement de
l’existant à moindre coût. De plus, l’évolution des méthodes de travail au sein même de l’entreprise veut
qu’une part de plus en plus importante de l’activité de celle-ci sollicite les outils informatiques. Dans le
cas des sociétés de services en informatique, c’est toute l’activité des ingénieurs et dirigeants qui reposent
intégralement sur la bonne disponibilité des services informatiques et réseaux. C’est dans cette volonté
de contrôle que s’intègre la supervision de réseaux. L’objectif des opérateurs d’un centre de supervision
est donc de pouvoir connaître en permanence l’état du réseau, et d’être averti en temps réel des différents
incidents pour réduire au maximum les délais d’intervention et de coupure du service, et d’exploiter au
mieux les capacités du réseau.
A présent, de nouveaux besoins se font sentir. Le premier besoin est de rompre la contrainte de
proximité de l’équipement à gérer. Avec les protocoles de gestion de réseau actuels, le réseau est utilisé
afin de permettre la gestion des équipements le composant. On se trouve donc dans le cas d’une gestion
du réseau par le réseau. Le second besoin concerne la dépendance humaine. La complexité des réseaux
s’accroissant, la tâche de gestion du réseau exige une telle masse d’informations à traiter qu’elle dépasse
la capacité de l’être humain. En effet, il faut remarquer que chaque information individuelle sur un
équipement ne peut être utilisée telle quelle, elle n’est significative que dans le contexte du réseau global.
Les considérations énoncées ci-dessus permettent d’identifier les besoins de la gestion des réseaux :
– S’adapter à toutes les tailles de réseaux.
– Gérer des équipements hétérogènes et possiblement complexes.
– Permettre les opérations de gestion à distance.
– Assister l’utilisateur en :
– Automatisant certaines tâches.
– Aidant l’utilisateur dans les tâches qui ne sont pas automatisées.
Fournissant une vue adaptée du réseau selon les opérations à réaliser.
2.3.2 Fonctionnalités
Une bonne gestion de réseau permet l’utilisation optimale de toutes les ressources offertes par le
réseau. La gestion de réseau a trois fonctions : l’exploitation, la supervision et la maintenance.
2.3.2.1 L’exploitation
Un système de gestion de réseau doit permettre l’exploitation du réseau au mieux de ses capacités et des
services que ce dernier propose. Si nous prenons l’exemple du Backbone ATM de Tunisie Telecom, il doit
permettre la gestion des abonnés présents sur chaque partie du réseau (Frame Relay, ATM, IP/MPLS,
etc.) c’est-à-dire ajouter, modifier ou résilier sur tous les éléments du réseau (soit les cartes vers les
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 12
abonnés ou les cartes vers le cœur du réseau). L’exploitation du réseau consiste aussi à ajouter de nouveau
équipement au réseau afin de l’étendre (multiplexeur, commutateur ou routeur etc.), à sauvegarder les
fichiers de configurations des équipements etc. La tâche d’exploitation d’un réseau est délicat d’autant
plus qu’on doit prendre le soin de ne jamais dépasser les quantités de ressources que le réseau met à notre
disposition.
2.3.2.2 La supervision
Un logiciel qui fait de la gestion de réseau doit amasser toutes les informations de gestion dont il a
besoin. Ces informations parviennent de chacun des éléments du réseau. Pour les obtenir, une étape de
découverte des éléments de réseau est effectuée, puis les requêtes sont envoyées aux éléments un à un pour
en tirer les informations de gestion. Ces informations de gestion comprennent toutes sortes d’informations
reliées à un élément de réseau : le type d’équipement, le nombre de paquets qui passent sur chaque port
d’un routeur, l’usager qui utilise une station de travail...
Pour effectuer cette tâche, une technique pour démasquer les éléments de réseaux est nécessaire.
Un protocole pour obtenir les informations de gestion est aussi nécessaire. SNMP est un protocole qui
permet de réaliser ces fonctionnalités. Une fois que l’on a les informations de gestion, il est important
de les interpréter correctement. Par exemple : 5000 paquets par seconde sur un port d’un routeur est
peut-être normal ou peut-être le signe d’une surcharge et d’une dégradation de la qualité du service
offert. Même si on connaît la charge exacte d’un routeur, cette information ne suffit pas pour prendre des
décisions pertinentes de gestion.
Les manufacturiers d’équipements offrent quelquefois des logiciels qui savent interpréter les informa-
tions de gestion de leurs équipements de gestion. Toutefois, une interprétation automatique complète et
correcte de l’état d’un réseau et de ses équipements est difficile à réaliser. L’intervention humaine est
souvent requise pour interpréter les données ou pour placer des bornes acceptables.
2.3.2.3 La maintenance
Quand des informations de gestion sont obtenues et interprétées, il est quelquefois nécessaire d’agir. Il
doit être possible de demander à un équipement, par exemple, de se réinitialiser, de couper ou d’activer
des services...
Pour ce faire, un protocole de gestion doit transmettre un ordre (requête) à l’équipement approprié
pour déclencher l’action. En raison de l’absence de sécurité par le passé, cette fonctionnalité a rarement
été utilisée.
2.3.3 Principes de la gestion de réseau
Les architectures de gestion de réseau sont classées dans la catégorie des systèmes client/serveur. On
peut donc identifier trois composants :
– La partie client, appelée manager, est l’entité qui va superviser les opérations de gestion. Elle sert
d’interface entre l’utilisateur et le serveur. Il peut y avoir, le cas échéant, plusieurs managers.
– La partie serveur, appelée agent représente un ou plusieurs équipements. Un agent sert d’interface
entre l’équipement et le manager. Il peut également servir d’interface entre plusieurs autres agents
et le manager. L’agent permet de fournir une vue abstraite de l’équipement et masque ainsi les
différences qui existent entre les équipements. Il y a bien entendu plusieurs agents dans un réseau.
– Le protocole est le langage utilisé par le manager et l’agent pour communiquer (SNMP, CMIS,
CMIP, . . . ) Il est mis en œuvre par le biais d’un réseau. Ce protocole permet au manager d’interroger
l’agent (dans le cas du monitoring) ou de lui demander de modifier l’état de l’équipement (dans le
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 13
cas de la configuration). Le protocole est également utilisé par l’agent afin d’avertir le manager de
l’occurrence d’événements.
Figure 2.8 – Relations entre manager, agents et protocole
Dans le cadre de notre projet nous avons opté pour l’utilisation du protocole SNMP (Simple Network
Management Protocol) qui offre une grande panoplie de fonctionnalités et disponible sur les commutateurs
Nortel. Comme son nom l’indique, c’est un protocole très simple à utiliser du fait du nombre très limités
de ses requêtes : GET, GET-NEXT, SET, et les TRAP.
2.3.4 SNMP
L’activité de recherche et de standardisation au niveau de SNMP est menée sous l’égide de l’IETF
(Internet Engineering Task Force). La première version de SNMP a vu le jour en 1989. La seconde
version, appelée SNMP v2 a été standardisée en 1992 [RFC1905]. Cette version apporte essentiellement
des changements au niveau de la sécurité et de la confidentialité des opérations de gestion. Suite à des
problèmes apparus lors de la mise en opération de la seconde version du protocole, ces aspects ont été
classés obsolètes en 1996 lors d’un des meetings trisannuel de l’IETF. Ce dernier rebondissement a eu pour
effet, d’une part de renvoyer SNMP à son état de 1989 et d’autre part, de déclencher les recherches sur
SNMP v3. Les travaux se poursuivent actuellement et petit à petit les différents éléments de l’architecture
SNMP v3 sont proposés à la communauté scientifique [RFC2274]. SNMP v3 (dans les aspects qui sont
actuellement définis) est en passe de devenir un standard car il est accepté par le working group SNMP
v3 en tant que proposed standard. A l’heure actuelle, SNMP v1 reste la version la plus utilisée. De plus,
les résultats obtenus avec SNMP v1 sont immédiatement applicables à SNMP-v2.
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 14
SNMP suit l’architecture client/serveur, le client étant le manager et le serveur l’agent. Contrairement
aux architectures client/serveur habituelles où un serveur interagit avec plusieurs clients, SNMP est
l’exemple d’un schéma inverse : un client, souvent unique, communique avec plusieurs serveurs. Il y a un
agent par équipement à gérer. L’agent conserve une série de variables qui modélisent l’équipement. Le
manager, au travers de l’agent, consulte et/ou modifie les valeurs des variables à l’aide d’opérations de
management. Des changements d’état internes à l’équipement modifient eux aussi les valeurs des variables.
La manière dont l’agent doit être informé de ces changements n’est pas spécifiée dans SNMP. L’ensemble
des variables gérées est appelé MIB (Management Information Base). Le manager interagit avec l’agent
via un protocole de communication qui spécifie la dynamique de la communication (mécanismes de
question/réponse), ainsi que la structure des messages échangés.
Figure 2.9 – Architecture SNMP
La Management Information Base (MIB) contient les variables qui forment le modèle informationnel
de l’équipement. Les variables sont organisées sous une forme arborescente. Les nœuds intermédiaires
servent uniquement de points de rattachement pour les branches, ils ne contiennent aucune valeur. Les
feuilles par contre stockent des valeurs.
La MIB déclaration est décrite à l’aide d’un langage spécifié dans un standard appelé Structure of
Managed Information (SMI). Pour SNMP v1, ce standard est le Request For Comment 1155 [RFC1155].
Le langage utilise pour sa définition la syntaxe ASN.1. Chaque objet qui y est déclaré inclut les
informations suivantes :
– Un nom.
– Un type : il s’agit soit d’un type simple : INTEGER, OCTET-STRING, NULL, soit d’un type de
construction : SEQUENCE-OF, SEQUENCE, soit d’un type spécifique : NetworkAddress, IpAd-
dress, Counter, Gauge, TimeTicks.
– Un modificateur d’accès : read-write, read-only, write-only, not-acessible.
– Un modificateur de statut : mandatory, optional, obsolete.
– Une description : il s’agit d’un texte en langage naturel, qui décrit l’utilité de l’objet.
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 15
Figure 2.10 – Structure d’indexation des données dans la MIB-2 SNMP
L’objet snmpInPkts dans MIB II :
snmpInPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The total number of Messages delivered to
the SNMP entity from the transport service."
: := { snmp 1 }
Les objets et instances sont nommés par un identificateur que l’on appelle Object IDentifier. Il s’agit
d’une suite de nombres séparés par des points. La dot notation fournit un chemin dans l’arbre à partir
de la racine. La racine est identifiée par le nombre ’1’. Le nombre suivant, c’est-à-dire le second nombre
dans la dot notation, identifie le numéro du fils de la racine. On procède récursivement jusqu’à la fin de
l’object identifier. A titre d’exemple, l’objet snmpInPkts possède comme object identifier 1.3.6.1.2.1.11.1.
Les cinq premiers identificateurs sont fixes car ils correspondent à la racine de toute l’arborescence de
management :
iso(1).org(3).dod(6).internet(1).mgmt(2)
Le sixième identificateur correspond à mib2(1) qui est la MIB permettant de gérer un stack TCP/IP
standard. L’objet snmpInPkts est le premier fils en partant de la gauche du groupe snmp qui lui-même
a l’identificateur 11. On utilise comme notation abrégée snmp(11). L’object identifier d’une instance est
construit sur base de l’Object IDentifier de l’objet correspondant. Suivant que l’instance appartienne
à une table (un ensemble de lignes) ou soit une instance isolée (appelée variable simple) le schéma de
construction est différent. Dans le cas des variables simples, on postfixe l’identificateur de l’objet par un
numéro d’instance. Les instances sont numérotées à partir de zéro. L’instance correspondant à l’objet
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 16
snmpInPkts sera donc identifiée par 1.3.6.1.2.1.11.1.0. Si une instance supplémentaire existe (ce qui
n’est pas le cas ici), elle porte l’identificateur 1.3.6.1.2.1.11.1.1 et ainsi de suite. L’accès à des instances
appartenant à des tables est plus complexe, car SNMP utilise le concept d’adressage associatif.
La simplicité de SNMP est en partie due à la simplicité de ses opérations de gestion. Il y en a quatre :
– GET : permet au manager de récupérer la valeur contenue dans une instance.
– SET : permet au manager d’assigner une valeur à une instance.
– GET-NEXT : permet à partir d’un point de l’arborescence de trouver l’instance la plus proche.
– TRAP : permet à l’agent d’envoyer une notification spontanée au manager.
Le port standard utiliser par SNMP pour la communication est le port UDP 161, en utilisant les sockets ;
La distinction est faite entre une opération SNMP et une requête SNMP. Les relations entre ces deux
concepts sont les suivantes :
– Une requête SNMP contient plusieurs opérations.
– Toutes les opérations d’une requête doivent être du même type (ex : uniquement des GET).
2.3.5 Le Protocole Telnet
Le premier protocole historique est Telnet. Ce protocole TCP est largement utilisé pour le contrôle
à distance de matériel réseau. La conception est excessivement simple : une fois que l’on est connecté
à la machine distante, les touches tapées au clavier sont directement transmises à la machine distante
et Telnet nous renvoie les réponses de ladite machine. Généralement, la machine distante commence la
transaction par nous demander un mot de passe d’accès, puis nous donne accès à un shell (terminal) sur
lequel nous pouvons lancer nos commandes.
Figure 2.11 – Exemple de session Telnet sur un commutateur Nortel 7480
Ci-dessus nous pouvons analyser l’exemple d’une session Telnet sur un commutateur Nortel. Ici « d
Fruni/21905 dlci/* » nous affiche la liste des circuits du Frame Relay N° 21905.
Telnet n’est pas un protocole fournissant une interface commune à tous les matériels réseau. Chaque
constructeur inclut son propre gestionnaire Telnet personnalisé, et la gestion du réseau n’est donc pas
uniforme suivant le type de matériel. Telnet assure intrinsèquement la fiabilité de la transaction de par
l’utilisation du protocole TCP, toutefois la communication entre l’administrateur et le matériel n’est pas
cryptée et la seule sécurité apportée est l’authentification initiale. Le protocole SSH (Secure SHell) comble
cette lacune en cryptant la transaction via le protocole SSL. Toutefois l’interface reste propre à chaque
matériel et ne permet pas d’effectuer des transactions parallèles ou une gestion uniforme de ceux-ci.
CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 17
2.3.6 Autres protocoles de gestion de réseau
D’autres protocoles de gestion existent. CMIP (Common Management Information Protocol), proto-
cole OSI de gestion de réseau, utilisant les services CMIS (Common Management Information Service)
pour leur administration, supervision comprise, à distance. Il a été repris par IBM dans son AUA (Ar-
chitecture Unifiée d’Applications) version française de son SAA (Systems Architecture Applications). Du
point de vue fonctionnel, il est bien plus riche que SNMP mais plus difficile à mettre en œuvre. Il n’est
pas très utilisé.
2.3.7 Gestion du réseau de Tunisie Telecom
Pour Tunisie Telecom, l’infrastructure de gestion de réseau est du type In-band, c’est-à-dire que
les informations de gestion du réseau passent par les mêmes chemins que les données que le réseau doit
transporter (les données utiles) ce qui est l’opposé de la gestion Out-of-band. Pour différencier les données
du trafic et les données de gestion on utilise les vp/vcc différents.
Figure 2.12 – Gestion In-band sur le réseau ATM
Conclusion
Au terme de ce chapitre, nous avons eu une vue global du Backbone ATM de Tunisie Telecom. Dans
un premier temps nous avons décrit le Backbone ATM de Tunisie Telecom, ensuite nous nous sommes
penché sur le Réseau ATM Nortel. Nous avons également décrit le réseau d’accès au Backbone ATM, et
nous avons présenté les équipements constitutifs du Backbone ATM Nortel de Tunisie Telecom et enfin
sa gestion. Par souci de confidentialité, nous ne pouvons pas dévoiler certaines informations.
Chapitre 3
Conception
Introduction
La programmation orientée objet est une technique qui est à la base de tous les nouveaux projets de
développement logiciels. La mise en œuvre de logiciels réseau n’échappe pas à cette tendance. Comme
tous les autres projets logiciels, les logiciels réseaux (y compris les applications web) peuvent profiter
des avantages de l’orientée objet. Cette technique permet la construction d’un programme solide, bien
structuré, facile à visualiser et qui est facile à modifier et à maintenir. Le recours à la modélisation est
depuis longtemps une pratique indispensable au développement logiciel, car un modèle est prévu pour
arriver à anticiper les résultats du codage. Un modèle est en effet une représentation abstraite d’un
système à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre les
différents intervenants au sein d’un projet. Le modèle sert donc des objectifs différents suivant l’activité
de développement et sera construit avec des points de vue plus détaillés : dans les activités de spécification
des exigences, les activités d’analyse et les activités de conception.
Depuis quelques années, la modélisation objet avec le langage UML (Unified Modeling Language) est
devenue incontournable sur la plupart des projets informatiques. UML se définit comme un langage de
modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter
des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de
vue. Dans ce projet, nous avons utilisé le processus unifié pour la modélisation de notre application web.
Le Processus Unifié (UP, pour Unified Process) est un processus de développement logiciel «itératif
et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » :
– Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui
aident à mieux suivre l’avancement global. À la fin de chaque itération, une partie exécutable du
système final est produite, de façon incrémentale.
– Centré sur l’architecture : tout système complexe doit être décomposé en parties modulaires afin
de garantir une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique,
matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte.
– Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout
levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre des
itérations.
– Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et des exigences
des utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits avec précision et
priorisés. [3]
Dans la suite de ce chapitre, nous détaillerons dans un premier temps les exigences fonctionnelles de
l’application NMS ATM Nortel, nous ajouterons ensuite les exigences non-fonctionnelles. Nous définirons
18
CHAPITRE 3. CONCEPTION 19
également les utilisateurs du futur système, les différents diagrammes UML à savoir : Diagramme des cas
d’utilisations, diagramme de séquences, diagramme de classes et diagramme d’états transition.
3.1 La spécification des besoins
Lors de la création d’un logiciel la tâche de spécification est la toute première à accomplir. Elle
consiste pour l’ingénieur à questionner le client sur ses besoins afin d’analyser et de détailler ses besoins.
En d’autres termes la spécification établit ce que le système doit faire (le QUOI) et les contraintes sous
lesquelles il doit opérer. Cela implique une communication permanente entre le concepteur et le client.
L’analyse et l’explicitation des besoins est une phase primordiale dans la conception de tout système. De
plus, à ce stade d’analyse, il est impératif de bien comprendre les besoins des clients, car chaque petite
lacune ou malentendu peut aboutir en cascade à une application non-utilisable.
3.1.1 Les exigences fonctionnelles
L’application Web NMS ATM Nortel devra regrouper les fonctionnalités nécessaires de gestion des
liaisons, de supervisions, et de maintenances du réseau d’accès DATA, en gros on définit les services du
système. La définition des exigences fonctionnelles doit répondre à la question le QUOI du système.
L’administration via l’interface web porte sur les services suivants cités et décris ci-dessous.
La création de liaisons Frame Relay Port et Circuit : Elle consiste à créer une nouvelle liaison Frame
Relay physique pour un abonné sur la quelle reposerait des circuits virtuels permanent entre deux Com-
mutateurs A et B. Pour cette tâche de création, l’utilisateur fourni le DNA (Data Network Address),
RDNA (Remote Data Network Address), le débit port et le débit du circuit initial (qui devra être in-
férieur ou égal au débit physique). Les DNA sont fournies par les centres régionaux et sont uniques. A
travers chaque DNA, on connaitra le commutateur concerné, la carte, la ligne E1 et le canal sur lequel
l’abonné a été affecté. Chaque canal est subdivisé en 32 intervalles de temps appelés Time Slots délivrant
chacun un débit physique de 64 Kbits/s. Pour un abonné qui a besoin d’un débit de 128 Kbits/s, on lui
attribuera alors 2 Time Slot et ainsi de suite. Le FRUNI (Frame Relay User Network Interface) qui est
constitué du LP, E1 et Canal sera automatiquement déduit du DNA et du RDNA. Pour les DLCI (Data
Link Connection Identifier) et RDLCI (Remote Data Link Connection Identifier), ça sera à la charge de
l’application de savoir exactement quelles valeurs utilisées en fonction de celles qui sont déjà allouées, ces
valeurs étant unique qu’au niveau local et sont compris entre 16 et 1023.
La création de nouveaux circuits : Consiste à la création d’un nouveau circuit virtuel sur une liaison
Frame Relay existante. Cette création devra précéder la tâche de création Port et circuit. Les données
fournies par l’utilisateur sont le DNA, le RDNA et le débit circuit. La procédure est presque identique
dans le cas précédant.
La création de liaisons spécialisées émulée sur ATM : Cette tâche consiste à créer une composante
couche 2 Aal1Ces (ATM Adaptation Layer 1 Circuit Emulation Service) entre deux commutateurs A et B.
Pour ce faire, l’utilisateur devra fournir les informations sur les ressources physiques allouées à l’abonné,
il s’agit du numéro de la carte Lp (Logical Processor), la ligne E1, et le canal.
Modification du débit circuit d’une liaison Frame Relay : Dans ce cas de figure, l’utilisateur donne les
DNA et le RDNA, les DLCI et RDLCI et le nouveau débit circuit, l’application vérifie sur le commutateur
que les informations fournies sont exactes et procède à la modification.
Modification du débit port d’une liaison Frame Relay : L’utilisateur fourni le DNA, les nouveaux
Times Slots, par la suite l’application procède à la modification.
Résiliation d’un circuit : Pour la résiliation d’un circuit, la procédure de vérification est la même que
pour la modification. Une fois la vérification terminée, le circuit sera alors résilié.
CHAPITRE 3. CONCEPTION 20
Résiliation d’une liaison Frame Relay : Après la vérification des informations fournies par l’utilisateur,
la liaison sera simplement résilié (Toutes les ressources allouées à l’abonné, time slots, circuits etc. . . seront
libérées).
Etat de lien des circuits virtuels permanents et du lien physique d’un abonné (LMI).
La liste des Multiplexeur reliés à un LP (carte du Commutateur comportant plusieurs liens E1 de 2
Mbits/s). La Liste des abonnés présents sur un LP/x et sur un lien physique E1/y.
L’état de lien des Liaisons spécialisées émulées (Aal1Ces /*), ou d’une seule liaison (plus détaillé).
Gestion des Multiplexeurs : Consiste à ajouter un nouveau multiplexeur à un commutateur en lui
affectant une jonction 2 Mbits/s. Les informations qui devront être fourni par l’utilisateur sont l’adresse
IP du multiplexeur et les intervalles de temps de gestion.
La sauvegarde des fichiers de configuration de façon automatique suivant une chronologie bien déter-
minée (ex : chaque jour à minuit).
Supervision du trafic : Visualisation de l’intensité du trafic (Emission/Réception) sur une liaison STM-
x (Synchronous Transfert Mode) par une courbe évoluant en fonction du temps pour des fins statistiques
(connaitre le trafic max aux heures de pointes pour entreprendre les actions nécessaires qui permettront
de résoudre cela).
Les tâches de maintenance telles que le Test de boucle local jusqu’à l’abonné, La gestion de l’espace
disque des commutateurs, la gestion des alarmes générées sur chaque commutateur.
3.1.2 Exigences non fonctionnelles
Les exigences non fonctionnelles permettent de définir des critères qui n’ont aucun impact sur le
fonctionnement de notre application. Par exemple les exigences de qualité, les exigences de sécurité,
d’ergonomie etc.
De ce fait, NMS ATM Nortel devra être sécurisée par mot de passe, son accès devra se faire par une
connexion chiffrée en utilisant des certificats (https/SSL). Son interface devra être simple et convivial,
elle doit être évolutive. Pour un souci de performance, l’application ne devra pas être très consommatrice
de ressource mémoire, ne doit pas générer des trafics supplémentaires pour ne pas gêner le trafic utile.
3.1.3 Gestion des exigences
La gestion des exigences est l’ensemble des activités permettant de définir et de suivre les exigences
d’un système au cours d’un projet. Elle permet de :
– s’assurer de la cohérence entre ce que fait réellement le projet et ce qu’il doit faire ;
– faciliter l’analyse d’impact en cas de changement.
Les principaux outils de gestion des exigences sont : DOORS (IBM – Telelogic), RequisitePro (IBM -
Rational), et CaliberRM(Borland), Enterprise Architect (Sparx Systems).
Nous allons profiter d’une capacité particulière de l’outil EA (Enterprise Architect), à savoir la pos-
sibilité de décrire les exigences comme des éléments de modélisation à part entière.
CHAPITRE 3. CONCEPTION 21
Figure 3.1 – Création des exigences dans Enterprise Architect
3.1.4 Identification des utilisateurs du système
L’identification des utilisateurs du système et leurs rôles respectifs, est une étape très importante dans
les spécifications d’un système. Il permet de définir le QUI FAIT QUOI ? Pour NMS ATM Nortel, après
l’identification des utilisateurs, nous avons pu établir les usagers cités et décrit ci-dessous.
– Administrateur : Il aura tous les droits sur l’application.
– Opérateur : Il aura le droit de faire les taches de routine comme la création, la modification et etc.
– Superviseur : il aura seulement le droit de faire la supervision des équipements mais ne pourra
entreprendre aucune action.
3.2 Spécification des exigences d’après les cas d’utilisation
Acteurs et cas d’utilisation sont les concepts UML fondamentaux pour la spécification des exigences.
L’expression préliminaire des besoins donne lieu à une modélisation par les cas d’utilisation et à une
maquette d’interface homme-machine (IHM). Dans cette partie, nous allons détailler la modélisation des
cas d’utilisation. La réalisation d’une maquette graphique est une activité courante mettant en jeu des
outils de dessin. Elle montre rapidement l’aspect visuel (le « look ») de l’application. Un cas d’utilisation
décrit une séquence d’action entre l’acteur et le système.
Les différentes étapes de la démarche que nous allons adopter afin d’aboutir au modèle de cas d’utilisation
sont les suivantes :
– Identifier les acteurs,
– Identifier les cas d’utilisation,
– Structurer les cas d’utilisation en packages,
– Ajouter les relations entre cas d’utilisation,
– Finaliser un ou plusieurs diagramme(s) de cas d’utilisation par package.
CHAPITRE 3. CONCEPTION 22
Figure 3.2 – Synoptique de la démarche de construction du modèle des cas d’utilisation, [Roques :2008}]
3.2.1 Identification des acteurs
Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou
autre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifier
directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs
de données.
Les acteurs humains pour NMS ATM Nortel sont les suivants :
– Administrateur : Il aura tous les droits sur l’application.
– Opérateur : Il aura le droit de faire les taches de routine comme la création, la modification et etc.
– Superviseur : il aura seulement le droit de faire la supervision des équipements mais ne pourra
entreprendre aucune action.
Nous allons également prendre en compte les commutateurs, qui l’application devra gérer.
L’ensemble des acteurs est représenté graphiquement sur la figure 3.3 autour d’un rectangle figurant le
système à l’étude. La représentation graphique standard de l’acteur en UML est l’icône appelée stick man,
avec le nom de l’acteur sous le dessin. On peut également figurer un acteur sous la forme rectangulaire
d’une classe, avec le mot-clé <‌<actor>‌>. Une bonne recommandation consiste à faire prévaloir l’utili-
sation de la forme graphique du stick man pour les acteurs humains et une représentation rectangulaire
pour les systèmes connectés.
CHAPITRE 3. CONCEPTION 23
Figure 3.3 – Acteurs du NMS ATM Nortel
3.2.2 Identification des cas d’utilisation
Un cas d’utilisation représente l’ensemble de séquences d’actions qui sont réalisées par le système et qui
produisent un résultat observable intéressant pour un acteur particulier. Dans la phase de spécifications
des exigences fonctionnelles, le modèle des cas d’utilisation considère le système comme une boite noire
et décrit les interactions entre le ou les acteurs et le système sous forme textuel, qui consistent aux
commandes de l’utilisateur et les réponses du système.
Pour chaque acteur identifié précédemment, il convient de rechercher les différentes intentions « métier
» selon lequel il utilise le système.
Ces cas d’utilisation principaux ont été bien mis en évidence par l’expression des besoins préliminaires
du chapitre précédent, à savoir :
– Créer une liaison Frame Relay Port et Circuit,
– Créer une liaison Frame Relay Circuit,
– Créer une liaison spécialisée émulée sur ATM,
– Modifier le débit d’un port,
– Modifier le débit d’un circuit,
– Résilier un port,
– Résilier un circuit,
– Afficher une LS Aal1Ces,
– Afficher les PVC/Lien Physique,
– Afficher liaison E1/E3/etc.,
– Examiner Boucle locale,
– Gérer les Alarmes,
– Gérer les MUX,
– Gérer les espaces disques,
– Sauvegarder les fichiers de configuration,
– Lister les MUX,
– Lister les abonnés,
– Lister les E3,
– Superviser le trafic.
CHAPITRE 3. CONCEPTION 24
Pour améliorer notre modèle, nous allons organiser les cas d’utilisation et les regrouper en ensembles
fonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’UML, le package. Le package est
un mécanisme général de regroupement d’élément UML, qui peut être utilisé par exemple pour regrouper
des cas d’utilisation, mais aussi des acteurs, des classes, etc. . .
Les acteurs ont également été regroupés dans un package séparé sur lequel s’appuient les packages de
cas d’utilisation. L’organisation générale du modèle dans un outil de modélisation est représentée sur la
figure 3.3. Le sigle UC pour use case est souvent utilisé pour raccourcir le nom des packages.
Figure 3.4 – Organisation des cas d’utilisation et des acteurs en packages (avec l’outil Enterprise Archi-
tect)
On obtient un diagramme (figure 3.5) représentant sur un schéma les cas d’utilisation (ovales) reliés par
associations (lignes) à leurs acteurs.
Figure 3.5 – Cas d’utilisation création de liaisons
CHAPITRE 3. CONCEPTION 25
Il est à noter que chaque cas d’utilisation doit avoir un objectif en soi et pouvoir être réalisé indépen-
damment des autres. Il arrive que deux acteurs, ou plus, présentent des similitudes dans leurs relations
aux cas d’utilisation. On peut l’exprimer en créant un acteur généralisé, éventuellement abstrait, qui
modélise les aspects communs aux différents acteurs concrets.
Dans notre cas, User est la généralisation des rôles Administrateur et Opérateur, qui peuvent tous
les deux réalisés les différentes tâches de créations. Ils peuvent (Administrateur et Opérateur) également
effectuer les modifications ou des résiliations de liaisons (voir figure 3.6). Les commutateurs A et B
sont nécessaires à la création de la liaison puisque le lien est créé entre les deux commutateurs. Il faut
aussi noter que pour créer un nouveau circuit, le port doit être déjà présent d’où la relation d’inclusion
formalisée par le mot-clé « include ». Le cas d’utilisation S’authentifier ne représente pas un objectif à
part à entière de l’utilisateur, mais plutôt un objectif de niveau intermédiaire qu’il faut conserver pour
plus de sécurité, car n’importe qui ne devra pas être capable d’accéder à l’application sinon cela aurait
des conséquences sévères.
A tout moment sur demande des clients, l’opérateur peut modifier le débit d’un port ou d’un circuit
sur ordre et les tâches de résiliation de port et de circuit reviennent à l’administrateur parce que ces
tâches requièrent un niveau d’autorisation plus élevé.
Figure 3.6 – Cas d’utilisation modification de liaisons
Il faut également tenir compte que la modification du débit d’un port et la résiliation d’un port ne
s’effectuent que sur un seul commutateur. Pour modifier le débit d’un circuit, les deux commutateurs sur
lesquels le circuit est créé entre jeu ; la modification du débit s’effectue alors sur les deux commutateurs.
La résiliation d’un port requiert que tous les circuits qui ont été créés sur ce port aient été résiliés au
préalable, dans le cas échéant la résiliation du port n’est pas possible.
Tous les acteurs du système peuvent réaliser la supervision. Cela ne demande pas de privilège particu-
lier. Les cas d’utilisation pour la supervision sont représentés dans la figure 3.7. En effet, le fait d’afficher
les multiplexeurs reliés à un commutateur, ou de lister les abonnés d’une ligne, etc. . . ne demande pas
un niveau de privilège élevé, donc tous les acteurs (Superviseur, Opérateur et Administrateur) peuvent
réaliser la supervision, d’autant plus que la supervision est une tâche assignée au superviseur. Chaque
utilisateur devra tout de même être authentifié avant de pouvoir réaliser quoi que ce soit sur le système.
CHAPITRE 3. CONCEPTION 26
Figure 3.7 – Cas d’utilisation supervision
L’ajout d’un nouveau multiplexeur, la sauvegarde des fichiers de configuration sont des tâches qui
peuvent être exécuté par un opérateur ou administrateur, car pour réaliser ces cas d’utilisation, l’acteur
devrait avoir un niveau de privilège un peu plus élevé. Un superviseur peut aussi connaitre l’état des lignes
E1, E3, l’état d’une liaison Frame Relay et avertir en cas de problème un opérateur ou un administrateur
pour qu’il intervienne et résoud le problème. Toutes ces tâches ne mettent qu’un seul commutateur en
jeu d’où la présence de l’acteur secondaire commutateur. Le diagramme de cas d’utilisation de ce package
est représenté sur la figure 3.8.
Figure 3.8 – Cas d’utilisation exploitation
CHAPITRE 3. CONCEPTION 27
Pour les tâches de maintenance, les cas d’utilisation que nous avons pu avoir sont : Le test de boucle
jusqu’à l’abonné, la gestion de l’espace disque des commutateurs et la gestion des alarmes générées par
les commutateurs. Les acteurs intervenant dans la réalisation de ces tâches sont l’opérateur et l’adminis-
trateur. En effet, ces tâches demandent un niveau de privilège élevé. Le diagramme de cas d’utilisation
pour les tâches de maintenance est représenté sur la figure 3.9.
Figure 3.9 – Cas d’utilisation maintenance
Une fois la structuration en package terminée, nous avons obtenu les packages suivants : Gestion des
liaisons, Exploitation et Maintenance et Supervision.
Figure 3.10 – Organisation complétée des cas d’utilisation et des acteurs
CHAPITRE 3. CONCEPTION 28
3.2.3 Traçabilité avec exigences textuelles
Lors de la spécification des exigences fonctionnelles, nous avons saisi un certain nombre d’exigences
dans Enterprise Architect. Nous allons maintenant établir la relation entre cas d’utilisation que nous
venons d’identifier et les exigences textuelles. Cette étude permet à la fois de valider la complétude des
cas d’utilisation, mais aussi d’améliorer celle des exigences textuelles. Enterprise Architect permet ainsi
de visualiser une matrice de traçabilité telle que représenter sur la figure 3.11.
Figure 3.11 – Matrice de traçabilité entre cas d’utilisation et exigences
3.3 Spécification détaillée des exigences
Dans cette partie, nous allons décrire de façon détaillée les cas d’utilisation que nous avons identifiés
dans la partie précédente. Nous complèterons cette description textuelle par une représentation graphique
UML très utile : le diagramme de séquence. Vu le nombre important de cas d’utilisation, on ne va pas
décrire chaque cas d’utilisation. Nous allons parler de quelques un, à savoir :
– Créer une liaison Frame Relay Port et Circuit
– Créer une liaison spécialisée émulée sur ATM
– Lister les abonnés
– Sauvegarder les fichiers de configuration
– Gérer les multiplexeurs
– Afficher les circuits virtuels d’un lien physique Frame-Relay
– Examiner Boucle Locale
– Gérer les espaces disques
– Superviser le trafic
CHAPITRE 3. CONCEPTION 29
3.3.1 Description textuelle des cas d’utilisation
La fiche de description textuelle d’un cas d’utilisation n’est pas normalisée par UML [3]. Nous avons
donc adopté celle qui est adaptée à notre problème. Ainsi les descriptions textuelles pour les cas d’utili-
sation cités plus haut sont les suivantes :
Créer Liaison Frame-Relay Port et Circuit
Acteur Principal
L’utilisateur (Acteur généraliser d’Administrateur et Operateur)
Acteurs Secondaires
Les deux commutateurs A et B
Objectif
L’utilisateur veut créer une nouvelle liaison Frame-Relay Port et Circuit entre le commutateur A et le
commutateur B.
Précondition
L’utilisateur s’est authentifié sur l’application.
Post condition
La liaison Frame Relay a été correctement créée et est opérationnelle.
Scénario nominal
1. L’utilisateur saisit le Nom du client, DNA, RDNA, débit physique, débit circuit.
2. L’utilisateur choisi les intervalles de temps à allouer au client.
3. L’utilisateur valide la création.
4. Le commutateur A exécute les instructions de création de la liaison.
5. Le commutateur B exécute les instructions de création de la liaison.
Alternatives
1a- L’utilisateur a fourni des informations erronées.
1. L’utilisateur modifie toutes les informations erronées.
2. L’utilisateur valide la création de la liaison.
Exigence Supplémentaire
Une fois le processus de création lancé, il ne doit pas être interrompu.
Créer une Liaison Spécialisée émulée sur ATM
Acteur Principal
L’utilisateur (Acteur généraliser d’Administrateur et Operateur)
Acteurs Secondaires
Les deux commutateurs A et B
Objectif
L’utilisateur veut créer une nouvelle liaison spécialisée à émulation de circuit entre le commutateur A et
le commutateur B.
Précondition
L’utilisateur s’est authentifié sur l’application
Post condition
La liaison a été correctement créée et est opérationnelle.
Scénario Nominal
1. L’utilisateur choisit les commutateurs A et B.
CHAPITRE 3. CONCEPTION 30
2. L’utilisateur saisit le nom de l’abonné, la carte, la ligne et le canal.
3. L’utilisateur choisit les intervalles de temps pour A, et pour B.
4. Il valide la création de la liaison.
Alternatives
1a- L’utilisateur a fourni des informations erronées.
. L’utilisateur modifie toutes les informations erronées.
2. L’utilisateur valide la création de la liaison.
Exigence Supplémentaire
Une fois le processus de création lancé, il ne doit pas être interrompu.
Lister les abonnés
Acteur Principal
L’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur)
Acteur Secondaire
Le Commutateur
Objectif
L’utilisateur veut avoir la liste des abonnés d’une liaison E1, par la suite il pourra avoir plus de détails
sur une liaison tel que le type de la liaison (Frame Relay/Aal1Ces), les ITs accordés à un abonné et etc.
Précondition
L’utilisateur s’est authentifié sur l’application.
Post Condition
Une liste d’abonné s’affiche à l’utilisateur.
Scenario nominal
1. L’utilisateur sélectionne le commutateur.
2. L’utilisateur choisi la carte.
3. L’utilisateur sélectionne la ligne.
4. La liste des abonnés sur cette ligne s’affiche.
Afficher les circuits virtuels d’un lien physique Frame-Relay
Acteur Principal
L’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur)
Acteur Secondaire
Le Commutateur
Objectif
L’utilisateur veut avoir l’état d’une liaison Frame-Relay (LMI) et la liste des circuits virtuels permanents
(PVC) et leurs états respectifs.
Précondition
L’utilisateur s’est authentifié sur l’application.
Post Condition
L’état de la liaison s’affiche (Fonctionnement normal, Arrêté, En cours de synchronisation).
Scenario nominal
1. L’utilisateur sélectionne le commutateur.
2. L’utilisateur entre l’identifiant FRUNI (Frame-Relay User Network Interface).
3. L’état de la liaison, les circuits virtuels avec leurs états respectifs s’affiche.
CHAPITRE 3. CONCEPTION 31
Gérer les multiplexeurs
Acteur Principal
L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur)
Acteur Secondaire
Le commutateur
Objectif
L’utilisateur veut ajouter un nouveau multiplexeur en affectant une jonction 2 Mbits/s au commutateur.
Précondition
L’utilisateur s’est authentifié sur l’application
Post Condition
La jonction s’est correctement effectuée et le commutateur voit le Multiplexeur ajouté.
Scénario Nominal
1. L’utilisateur sélectionne le commutateur.
2. Il choisit la carte et la ligne.
3. Il affecte un canal et des intervalles de temps pour la gestion.
4. L’utilisateur saisi l’adresse IP du multiplexeur à ajouter.
5. Il valide l’affectation de la jonction.
Backup des configurations
Acteur Principal
L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur).
Acteur Secondaire
Le commutateur.
Objectif
L’utilisateur veut sauvegarder le dernier fichier de configuration d’un commutateur.
Précondition
L’utilisateur s’est authentifié sur l’application.
Post Condition
Le fichier de configuration a été correctement sauvegardé.
Scénario Nominal
1. L’utilisateur choisit le commutateur.
2. Il choisit la dernière configuration.
3. Il télécharge le fichier sur le serveur.
Gérer les espaces disque
Acteur Principal
L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur).
Acteur Secondaire
Le commutateur.
Objectif
L’objectif de cette tâche est de supprimer les fichiers inutiles pour libérer de l’espace disque sur le com-
mutateur.
Précondition
L’utilisateur s’est authentifié sur l’application.
CHAPITRE 3. CONCEPTION 32
Post Condition
Une quantité considérable d’espace disque a été libérée sur le commutateur.
Scénario Nominal
1. L’utilisateur choisit le commutateur.
2. Il affiche la quantité d’espace disque occupée.
3. Il choisit les fichiers qu’il considère inutiles (les anciens fichiers).
4. Il efface ces fichiers un par un.
5. L’application informe l’utilisateur l’opération du succès de l’opération.
Examiner la boucle locale
Acteur Principal
L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur).
Acteur Secondaire
Le commutateur.
Objectif
Dans le but de la recherche d’éventuel problème de liaison, l’utilisateur veut tester la boucle local jusqu’à
l’abonné, pour par la suite voir où se situe le problème de la liaison.
Précondition
L’utilisateur s’est authentifié sur l’application.
Post Condition
Plusieurs résultats possibles. La liaison fonctionne correctement, la liaison ne fonctionne pas correctement.
Scénario Nominal
1. L’utilisateur choisit le commutateur.
2. Il choisit la carte, la ligne, et le canal.
3. Il fait une boucle coté multiplexeur et regarde les resultats retournés par le multiplexeur.
4. En fonction de ces résultats, il prend les décisions conséquentes qui s’imposent.
Superviser le trafic
Acteur Principal
L’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur).
Acteur Secondaire
Le commutateur.
Objectif
L’utilisateur souhaite visualiser l’intensité du trafic d’une liaison inter-sites.
Précondition
L’utilisateur s’est authentifié sur l’application.
Post Condition
Un graphe représentant l’intensité du trafic évoluant en fonction du temps s’affiche.
Scénario Nominal
1. L’utilisateur choisit le commutateur.
2. Il choisit une jonction inter-sites.
3. Un graphe représentant l’intensité du trafic en fonction du temps s’affiche.
CHAPITRE 3. CONCEPTION 33
3.3.2 Diagramme de séquence système
Les cas d’utilisation décrivent les interactions entre les acteurs avec l’application web que nous voulons
spécifier et concevoir. Lors de ces interactions, les acteurs produisent des messages qui affectent le système
informatique et appellent généralement une réponse de celui-ci. Nous allons isoler ces messages et les
représenter graphiquement sur des diagrammes de séquence UML.
Pour les messages, les DSS (diagrammes de séquence système) montrent non seulement les acteurs
externes qui interagissent directement avec le système mais également ce système (en tant que boite noire)
et les évènements déclenchés par les acteurs. L’ordre chronologique se déroule vers le bas et l’ordre des
messages doit suivre la séquence décrite dans les cas d’utilisation.
Nous allons représenter le DSS d’un scénario représentatif de chacun des cas d’utilisation décrit pré-
cédemment.
Créer Liaison Frame-Relay Port et Circuit
Il faut repartir de la description textuelle détaillée du cas d’utilisation et transformer chaque étape
en une flèche représentant un message. L’acteur principal (L’utilisateur) est représenté à gauche du
diagramme et le système NMS ATM Nortel entre l’utilisateur et les commutateurs qui sont les acteurs
secondaires. Le mot-clé « system » est utilisé dans le système boite noire pour le différencier plus nettement
des acteurs. (Figure 3.12)
Figure 3.12 – Diagramme de séquence système Créer une liaison Frame Relay port et circuit
CHAPITRE 3. CONCEPTION 34
Créer une liaison spécialisée émulée sur ATM
Figure 3.13 – Diagramme de séquence système Créer une liaison spécialisée émulée sur ATM
Lister les abonnés
Figure 3.14 – Diagramme de séquence système Lister les abonnés
CHAPITRE 3. CONCEPTION 35
Afficher les circuits virtuels d’un lien physique Frame-Relay
Figure 3.15 – Diagramme de séquence système Afficher les circuits virtuels d’un lien Physique Frame
Relay
Gérer les multiplexeurs
Figure 3.16 – Diagramme de séquence système Gérer les multiplexeurs
CHAPITRE 3. CONCEPTION 36
Backup des configurations
Figure 3.17 – Diagramme de séquence système Backup des configurations
Gérer les espaces disque
Figure 3.18 – Diagramme de séquence système Gérer les espaces disque
CHAPITRE 3. CONCEPTION 37
Examiner la boucle locale
Figure 3.19 – Diagramme de séquence système Examen de la boucle locale
Superviser le trafic
Figure 3.20 – Diagramme de séquence supervision du trafic
CHAPITRE 3. CONCEPTION 38
3.4 Diagramme des classes
Le diagramme des classes constitue l’un des pivots essentiels de la modélisation avec UML. En effet,
ce diagramme exprime de manière générale la structure statique d’un système, en termes de classes et de
relations entre ces classes [1]. De même qu’une classe décrit un ensemble d’objets, une association décrit
un ensemble de liens ; les objets sont instances des classes et les liens sont instances des relations. Un
diagramme des classes décrit de manière abstraite les liens potentiels d’un objet vers d’autres objets.
Une classe se représente à l’aide d’un rectangle comportant plusieurs compartiments. Les trois com-
partiments de base sont :
– la désignation de la classe,
– la description des attributs,
– la description des opérations.
Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une classe, l’attribut prend
une valeur. Par exemple un commutateur a comme attributs sont identifiant unique, son adresse IP,
son nom. . . Une opération est une fonction applicable aux objets d’une classe. Une opération permet de
décrire le comportement d’un objet. Un exemple d’opération sur la classe Commutateur est qu’on ajouter
un commutateur. Une méthode est l’implémentation d’une opération.
Figure 3.21 – Diagramme des classes
Dans notre cas, un commutateur est relié à un ou plusieurs multiplexeurs, et un multiplexeur n’est
relié qu’à un et un seul commutateur.
CHAPITRE 3. CONCEPTION 39
Un commutateur contient plusieurs cartes, d’où la relation d’agrégation entre commutateur et carte.
Une agrégation est un cas particulier d’association non symétrique exprimant une relation de conte-
nance. Le commutateur contient également plusieurs configurations. Une carte est composée de plusieurs
interfaces.
Un abonné a la possibilité d’avoir plusieurs liaisons Frame Relay ainsi qu’ATM, et ces liaisons ne
peuvent appartenir qu’à un seul Abonné. Chaque liaison Frame Relay et Aal1Ces est composé de circuit
virtuel caractérisé par entre autre le débit, les différents identifiants de bout en bout (DLCI, RDLCI,
Aal1Ces Number . . . ). La notation « Ordered » sur la relation de composition qui lie une liaison Frame
Relay et un circuit Frame Relay indique que les circuits créés sur un lien FR sont typiquement ordonné
par ordre de création, ceci permet de bien suivre l’ordre d’incrémentation du DLCI qui varie de 16 à 1023
par ordre croissant et un pas d’incrémentation de 1. Un exemple de création est que si on crée une liaison
FR, le premier circuit de ce lien aura comme DLCI 16, le circuit suivant qui sera créé sur ce lien aura
comme DLCI 17 et ainsi de suite.
3.5 Diagramme d’états
UML a bien repris le concept de machine à état fini FSM (Finite State Machine) en anglais, qui consiste
à s’intéresser au cycle de vie d’un objet générique d’une classe particulière au fil de ses interactions, dans
tous les cas possibles [3]. Cette vue locale d’un objet, qui décrit comment il réagit à des événements en
fonction de son état courant et comment il passe dans un nouvel état, est représentée graphiquement
sous la forme d’un diagramme d’états. Les diagrammmes d’états sont utilisés pour modéliser l’aspect
dynamique d’un système. Le diagramme d’états est une représentation graphique d’une machine à états
fini dans laquelle les noeuds représentent les états et les arcs représentent les transitions [1].
Un état représente une situation durant la vie d’un objet pendant laquelle : il satisfait une certaine
condition, il exécute une certaine activité, ou bien il attend un certain événement. Un objet passe par
une succession d’états durant son existence. Un état a une durée finie, variable selon la vie de l’objet, en
particulier en fonction des événements qui lui arrivent.
Une transition décrit la réaction d’un objet lorsqu’un évènement se produit (généralement l’objet
change d’état, mais pas forcément). En règle générale, une transition possède un événement déclencheur,
une condition de garde, un effet et un état cible.
En plus de la succession d’états « normaux » correspondant au cycle de vie d’un objet, le diagramme
d’états comprend également deux pseudo-états :
– L’état initial du diagramme d’état correspond à la création de l’instance
– L’état final du diagramme d’état correspond à la destruction de l’instance.
Dans notre cas, nous n’allons pas représenter une machine à état pour toutes nos classes. Nous représen-
terons celles qui ont un comportement dynamique complexe nécessitant une description plus poussé.
Dans la figure 3.22, nous avons représenté les états et transition lors de la vie normale de la création
d’une liaison FR port et circuit. La validation des informations de création de la liaison peut se heurter à
des erreurs de saisies. Chaque commutateur effectue les traitements à son niveau. Une fois que la création
est terminée sur le premier commutateur, la transition « lancement de la création » est franchie pour
lancer la création sur le second commutateur ; une fois toutes les instructions exécutées, un résumé de la
création s’affiche dans la quelle apparait l’état de la nouvelle liaison.
CHAPITRE 3. CONCEPTION 40
Figure 3.22 – Diagramme d’état Création liaison FR port et circuit
Figure 3.23 – Diagramme d’état Supervision du trafic
CHAPITRE 3. CONCEPTION 41
Figure 3.24 – Diagramme d’état : Gérer l’espace disque
3.6 Base de données
La base de données qui devra gérer les données de l’application (historique du trafic, des alarmes et
etc. . . ) est constituée des tables suivantes :
– Commutateurs : Cette table stockera les informations relatives à chaque commutateur qui sera gérer
par l’application à savoir son identifiant, nom et adresse IP ;
– Cartes : Cette table devra enregistrer les informations de toutes les cartes de tous les commutateurs
– Interfaces : Comme son nom l’indique, cette table devra recevoir les informations sur chaque inter-
face de toutes les cartes de tous les commutateurs, ceci permettra de suivre facilement les données
entrant et sortant sur chaque et interface et par la suite de pouvoir faire des analyses par des gra-
phiques évoluant en fonction du temps, de pouvoir suivre les alarmes générés au niveau de chaque
commutateur ;
– Infotrafic : cette table recevra les données sur le trafic provenant de chaque interface de tous les
commutateurs recensées par le service en charge de récolter les données de trafic périodiquement ;
– Infoalarm : cette table recevra les données d’alarmes récoltées par le service de surveillance des
alarmes ;
CHAPITRE 3. CONCEPTION 42
Le modèle conceptuel de données est le suivant :
Figure 3.25 – Schéma Conceptuel de la base de données
Conclusion
Nous venons, au terme de ce chapitre, de présenter le langage utilisé pour faire la conception de notre
application qui est le langage UML. Ensuite, nous avons dégagé à partir des besoins utilisateurs les diffé-
rents diagrammes UML, et la base de données qui sera utilisée pour stockage des données, qui par la suite
nous permettrons de codé proprement notre application. Le chapitre suivant sera sur l’implémentation
de l’application NMS ATM Nortel et l’observation des premiers résultats.
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel
Conception et Développement d'un Network Management System ATM Nortel

Contenu connexe

Tendances

Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...Abdallah YACOUBA
 
Ma présentation PFE
Ma présentation PFEMa présentation PFE
Ma présentation PFELouati Aicha
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachislim Hannachi
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...Hajer Dahech
 
Rapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwokRapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwokAbdessamad IDRISSI
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Mohamed Boubaya
 
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...tayebbousfiha1
 
Rapport du projet fin d'etudes
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudesTahani RIAHI
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFENadir Haouari
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdfBader Nassiri
 
Présentation10
Présentation10Présentation10
Présentation10hossam-10
 
Analyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reelAnalyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reelSid Ahmed Benkraoua
 
Réalisation d’une plateforme e-commerce de vente de prestations HTML dotée d...
Réalisation d’une plateforme e-commerce de vente de  prestations HTML dotée d...Réalisation d’une plateforme e-commerce de vente de  prestations HTML dotée d...
Réalisation d’une plateforme e-commerce de vente de prestations HTML dotée d...kadzaki
 
Rapport de stage à l’IUFM de Versailles
Rapport de stage à l’IUFM de VersaillesRapport de stage à l’IUFM de Versailles
Rapport de stage à l’IUFM de VersaillesFrédéric Sagez
 
Etude et mise en place d’une solution open source de gestion de la sécurité d...
Etude et mise en place d’une solution open source de gestion de la sécurité d...Etude et mise en place d’une solution open source de gestion de la sécurité d...
Etude et mise en place d’une solution open source de gestion de la sécurité d...Mohammed LAAZIZLI
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagioschristedy keihouad
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5YounessLaaouane
 
Mise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseauMise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseauRabeb Boumaiza
 
RAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdfRAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdfJoelChouamou
 

Tendances (20)

Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
Mémoire de fin de cycle présenté en vue de L’Obtention du Diplôme de Master P...
 
Ma présentation PFE
Ma présentation PFEMa présentation PFE
Ma présentation PFE
 
Mémoire : Cloud iaas Slim Hannachi
Mémoire :  Cloud iaas Slim HannachiMémoire :  Cloud iaas Slim Hannachi
Mémoire : Cloud iaas Slim Hannachi
 
Nagios
NagiosNagios
Nagios
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwokRapprot de satge supervision de résau par EyesOfNetwok
Rapprot de satge supervision de résau par EyesOfNetwok
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
Rapport de Stage PFE - Développement d'un Projet ALTEN MAROC Concernant le Sy...
 
Rapport du projet fin d'etudes
Rapport du projet fin d'etudesRapport du projet fin d'etudes
Rapport du projet fin d'etudes
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
 
Présentation10
Présentation10Présentation10
Présentation10
 
Analyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reelAnalyse trafic-urbain-temps-reel
Analyse trafic-urbain-temps-reel
 
Réalisation d’une plateforme e-commerce de vente de prestations HTML dotée d...
Réalisation d’une plateforme e-commerce de vente de  prestations HTML dotée d...Réalisation d’une plateforme e-commerce de vente de  prestations HTML dotée d...
Réalisation d’une plateforme e-commerce de vente de prestations HTML dotée d...
 
Rapport de stage à l’IUFM de Versailles
Rapport de stage à l’IUFM de VersaillesRapport de stage à l’IUFM de Versailles
Rapport de stage à l’IUFM de Versailles
 
Etude et mise en place d’une solution open source de gestion de la sécurité d...
Etude et mise en place d’une solution open source de gestion de la sécurité d...Etude et mise en place d’une solution open source de gestion de la sécurité d...
Etude et mise en place d’une solution open source de gestion de la sécurité d...
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagios
 
Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5Application web Gestion RH ASP.NET MVC5
Application web Gestion RH ASP.NET MVC5
 
Mise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseauMise en place d'une solution du supérvision réseau
Mise en place d'une solution du supérvision réseau
 
RAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdfRAPPORT DE STAGE SSI - Copie.pdf
RAPPORT DE STAGE SSI - Copie.pdf
 

En vedette

Application of GIS (Geographical information system)
Application of GIS (Geographical information system)Application of GIS (Geographical information system)
Application of GIS (Geographical information system)Fayaz Ahamed A P
 
Geographical information system (gis)
Geographical information system (gis)Geographical information system (gis)
Geographical information system (gis)RAKESH AHIRWAR
 
GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...
GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...
GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...GEOSYS ENTERPRISE PVT. LTD.
 
Geographical information system : GIS and Social Media
Geographical information system : GIS and Social Media Geographical information system : GIS and Social Media
Geographical information system : GIS and Social Media Imran Ghaznavi
 
GEOGRAPHICAL INFORMATION SYSTEM (GIS)
GEOGRAPHICAL INFORMATION SYSTEM (GIS)GEOGRAPHICAL INFORMATION SYSTEM (GIS)
GEOGRAPHICAL INFORMATION SYSTEM (GIS)Siva Mbbs
 

En vedette (10)

Gis
GisGis
Gis
 
Application of GIS (Geographical information system)
Application of GIS (Geographical information system)Application of GIS (Geographical information system)
Application of GIS (Geographical information system)
 
GIS Geographical Information System
GIS Geographical Information SystemGIS Geographical Information System
GIS Geographical Information System
 
Geographical information system (gis)
Geographical information system (gis)Geographical information system (gis)
Geographical information system (gis)
 
GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...
GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...
GIS Training in Hyderabad | GIS Coaching insistue in Hyderabad,Ameerpet | GIS...
 
Gis
Gis Gis
Gis
 
GIS PPT
GIS PPTGIS PPT
GIS PPT
 
Geographical information system : GIS and Social Media
Geographical information system : GIS and Social Media Geographical information system : GIS and Social Media
Geographical information system : GIS and Social Media
 
GEOGRAPHICAL INFORMATION SYSTEM (GIS)
GEOGRAPHICAL INFORMATION SYSTEM (GIS)GEOGRAPHICAL INFORMATION SYSTEM (GIS)
GEOGRAPHICAL INFORMATION SYSTEM (GIS)
 
Slideshare ppt
Slideshare pptSlideshare ppt
Slideshare ppt
 

Similaire à Conception et Développement d'un Network Management System ATM Nortel

rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...yosra fraiji
 
Wifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecuriteWifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecuriteRiadh Briki
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Alaaeddine Tlich
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsUniversité de Rennes 1
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfnesrine haloui
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...Mohamed Amine Mahmoudi
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesGenève Lab
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Nawres Farhat
 

Similaire à Conception et Développement d'un Network Management System ATM Nortel (20)

siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
 
Wifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecuriteWifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecurite
 
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
Mise en place d'une Plateforme de Supervision et de Détection d'Intrusion Sys...
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
Protection-dun-réseau-dentreprise-via-un-firewall.pdfProtection-dun-réseau-dentreprise-via-un-firewall.pdf
Protection-dun-réseau-dentreprise-via-un-firewall.pdf
 
Wifi pro
Wifi proWifi pro
Wifi pro
 
Rapport
RapportRapport
Rapport
 
these_sample
these_samplethese_sample
these_sample
 
Report Master
Report MasterReport Master
Report Master
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
ns.pdf
ns.pdfns.pdf
ns.pdf
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Le Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes TechnologiquesLe Référentiel Nouvelles Plateformes Technologiques
Le Référentiel Nouvelles Plateformes Technologiques
 
Rapport
RapportRapport
Rapport
 
Polycopie_CNA_CD.pdf
Polycopie_CNA_CD.pdfPolycopie_CNA_CD.pdf
Polycopie_CNA_CD.pdf
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Reseaux
ReseauxReseaux
Reseaux
 
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant...
 

Dernier

BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatiqueBOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatiqueidelewebmestre
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinidelewebmestre
 
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLBOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLidelewebmestre
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...idelewebmestre
 
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...idelewebmestre
 
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasBOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasidelewebmestre
 
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresBOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresidelewebmestre
 
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresBOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresidelewebmestre
 
BOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminantsBOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminantsidelewebmestre
 
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineBOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineidelewebmestre
 
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsBOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsidelewebmestre
 
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...idelewebmestre
 
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleurBOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleuridelewebmestre
 
BOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresBOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresidelewebmestre
 
Cadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en FranceCadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en Franceidelewebmestre
 
Agrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en DordogneAgrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en Dordogneidelewebmestre
 
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud PorcsBOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud Porcsidelewebmestre
 
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la NièvreAccompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la Nièvreidelewebmestre
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsidelewebmestre
 

Dernier (20)

BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatiqueBOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
BOW 2024 - 3 1 - Les infrastructures équestres et le changement climatique
 
BOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcinBOW 2024 - Le bâtiment multicritère porcin
BOW 2024 - Le bâtiment multicritère porcin
 
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VLBOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
BOW 2024 -3-9 - Matelas de logettes à eau refroidie VL
 
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
BOW 2024 - Nouveaux modes de logement pour des veaux de boucherie avec accès ...
 
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
BOW 2024 - 3-8 - Adaptation des bâtiments d'élevages de volailles au changeme...
 
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pasBOW 2024 - Dedans/Dehors quand voir ne suffit pas
BOW 2024 - Dedans/Dehors quand voir ne suffit pas
 
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitièresBOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
BOW 2024 -3-7- Impact bâtiment stress thermique Vaches laitières
 
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitièresBOW 2024 - 3-2 - Stress thermique impact vaches laitières
BOW 2024 - 3-2 - Stress thermique impact vaches laitières
 
BOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminantsBOW 2024-3-10 - Batcool Petits ruminants
BOW 2024-3-10 - Batcool Petits ruminants
 
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équineBOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
BOW 2024 - L'écurie ouverte : un concept inspirant pour la filière équine
 
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcinsBOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
BOW 24 - De la réflexion de groupe à l'immersion dans des bâtiments porcins
 
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...BOW 2024 - 3-3 -  Adaptation des bâtiments pour ruminants au changement clima...
BOW 2024 - 3-3 - Adaptation des bâtiments pour ruminants au changement clima...
 
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleurBOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
BOW 2024 - 3-5 - Des solutions numériques pour se préparer aux pics de chaleur
 
BOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitièresBOW 2024 - L'enrichissement du milieu des chèvres laitières
BOW 2024 - L'enrichissement du milieu des chèvres laitières
 
Cadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en FranceCadre réglementaire et développement de l'agrivoltaïsme en France
Cadre réglementaire et développement de l'agrivoltaïsme en France
 
Agrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en DordogneAgrivoltaïsme et filière ovine en Dordogne
Agrivoltaïsme et filière ovine en Dordogne
 
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud PorcsBOW 2024 - 3-6 - Adaptation climat chaud Porcs
BOW 2024 - 3-6 - Adaptation climat chaud Porcs
 
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la NièvreAccompagnement de l'agrivoltaïsme dans le département de la Nièvre
Accompagnement de l'agrivoltaïsme dans le département de la Nièvre
 
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminantsBow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
Bow 2024 - Plein air à l'intérieur des bâtiments d'élevage de ruminants
 
Webinaire lésions podales_04.04.2024.pptx
Webinaire lésions podales_04.04.2024.pptxWebinaire lésions podales_04.04.2024.pptx
Webinaire lésions podales_04.04.2024.pptx
 

Conception et Développement d'un Network Management System ATM Nortel

  • 1. REPUBLIQUE TUNISIENNE Ministère de l’Enseignement Supérieur, de la Recherche scientifique et de la Technologie Université Privée Montplaisir Tunis Agrément N° 01-2001 PROJET DE FIN D’ETUDE POUR L’OBTENTION DU Diplôme National d’Ingénieur En Réseaux et Télécommunications Elaboré par :Tidiane Sylla Encadreurs :Dr Salem Hasnaoui Mr Cherif Rezgui Année Universitaire 2011-2012 Université Privée Montplaisir Tunis Site web : http ://www.fmci.ens.tn - Email : contact@fmci.ens.tn UMT Quartier Montplaisir Rue Aboubaker El Bokri 1073 Tunis Tunisie Tel : (216) 71 901 660 / Fax : (216) 71 904 425
  • 2. Au Nom d’ALLAH, Le Tout Miséricordieux, Le Très Miséricordieux À mes chers Parents, À mon Père et ami de mon Père Mohamed Nimaga, qui ont toujours été présent malgré la distance, qui m’ont soutenus et accom- pagnés de “Dou’a” et de “Baraka” tout au long de mon parcours. i
  • 3. Remerciements Je suis profondément reconnaissant à mes deux encadreurs Mr Cherif Rezgui et Mr Salem Hasnaoui pour m’avoir fait le grand honneur de diriger mon projet dans les meilleures conditions, ainsi que pour leurs encadrements, leurs conseils et leurs disponibilités. Je témoigner ma reconnaissance à Monsieur Slaheddine Jarboui pour son aide pour l’obtention de ce stage à Tunisie Telecom. Je remercie également Mr Imed Toumi, Mr Houssem Jarraya, Mr Abdallah Abaza, Mr Maher Ben Hassine, Mr Saber Ben Gharbia, Mr Soufiane Mathloulhi, et à Mr Saif Eddine Abidi pour leurs aides précieuses, leurs conseils et les facilités qu’ils m’ont offert au sein du NOC DATA, ainsi que tous le personnel de la Direction Exécutive des Backbones pour leurs collaborations. Comme je n’y manquerai pas de remercier mes professeurs, membre du Jury pour l’honneur qu’ils ont fait en acceptant de faire partie de mon Jury. Je remercie également tous ceux qui de près ou de loin ont contribués à l’élaboration de ce rapport. ii
  • 4. Résumé Durant ce projet, nous nous sommes intéressés aux points suivants relatifs au Backbone ATM Nortel de Tunisie Telecom. Le premier point concerne le problème du travail en ligne de commandes. Le deuxième point concerne l’archivage des configurations des différents commutateurs. Pour remédier à ce problème, nous avons mis en place un processus de sauvegarde automatique et périodique. Le troisième point s’attache à la gestion des alarmes et à la gestion de la congestion des liaisons inter-sites, pour ce faire nous avons développé un processus pour le recueil des alarmes générées par les commutateurs et l’avertissement des opérateurs de ces incidents, et mise en place un service pour la supervision du trafic des liaisons inter- sites ce qui permet d’éviter toutes congestions sur ces liaisons. Mots clés : Backbone, ATM, Frame Relay, Backup, SNMP, Telnet, FTP, NMS. Abstract During this project, we were interested in the following points relating to Nortel ATM Backbone of Tunisie Telecom. The first concerns the problem of working on the command line. The second point concerns the archiving of configurations of different switches. To remedy this problem, we set up a backup process automatic and periodic. The third point focuses on alarm management and management of inter- site congestion, to do this we have developed a process for collecting alarms generated by the switches and warning operators of these incidents, and setting up a service for monitoring inter-site traffic which avoids any congestion on these routes. Key words : Backbone, ATM, Frame Relay, Backup, SNMP, Telnet, FTP, NMS. iii
  • 5. Table des matières Dédicaces i Remerciements ii Résumé iii Liste des acronymes vi Table des figures x Introduction Générale 1 1 Présentation du Projet 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Backbone ATM de Tunisie Telecom 5 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1 Les équipements d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Les équipements du Cœur du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 La gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1 But et domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2.1 L’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2.2 La supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2.3 La maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3 Principes de la gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.4 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.5 Le Protocole Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.6 Autres protocoles de gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.7 Gestion du réseau de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . . 17 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 iv
  • 6. TABLE DES MATIÈRES v 3 Conception 18 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 La spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 Les exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.3 Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.4 Identification des utilisateurs du système . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Spécification des exigences d’après les cas d’utilisation . . . . . . . . . . . . . . . . . . . . 21 3.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 Identification des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3 Traçabilité avec exigences textuelles . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3 Spécification détaillée des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2 Diagramme de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5 Diagramme d’états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.6 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4 Implémentation 43 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1 Technologie de développement web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.1 Le service TraficInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.2 Le service AlarmeManage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.3 Le service BackupAuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.3.4 NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Conclusion Générale 58 A L’ATM 59 Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.1 L’adressage dans le réseau ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2 La couche Physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.3 La qualité de service QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.4 La signalisation et le routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 B Frame Relay 64 Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 B.1 Circuits virtuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 B.2 Le contrôle d’admission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Bibliographie 68
  • 7. Liste des acronymes AAL ATM Adaptation Layer Aal1Ces ATM Adaptation Layer 1 Circuit Emulation Service ABR Available Bit Rate ADSL Asymetric Digital Subscriber Line AJAX Asynchronous Javascript And XML API Application Programming Interface ASN Abstract Syntax Notation ASP.NET Active Server Page .NET ATD Asynchronous Time Division ATM Asynchronous Transfert Mode BC Burst Committed Size BE Burst Excess Size BECN Backward Explicit Congestion Notification B-ISDN Broadband - Integrated Service Digital Network CBR Constant Bit Rate CCS Common Channel Signaling CIR Commited Information Rate CLLM Consolided Link Layer Management CLR Common Language Runtime CMIP Common Management information Protocol CMIS Common Management information Service CNET Centre Nationale Etude et de Télécommunication DCE Data Communication Equipment DLCI Data Link Connection Identifier DNA Data Network Address DS0 Digital Signal 0 DSLAM Digital Subscriber Line Access Multiplexer DTE Data Terminal Equipment E1 E-Carrier 1 EIR Excess Information Rate ETTD Equipement Terminal de Traitement de Données FECN Forward Explicit Congestion Notification vi
  • 8. TABLE DES MATIÈRES vii FR Frame Relay FRAD Frame Relay Access Device FRUNI Frame Relay User Network Interface FSI Fournisseur de Services Internet FSM Finite State Machine FTP File Transfert Protocol FTPS File Transfert Protocol Secure HTML Hyper Text Markup Language HTTPS Hyper Text Transfert Protocol Secure IDE Integrated Development Environment IETF International Engineering Task Force IISP Interim Inter Switching Protocol IP Internetworking Protocol LAN Local Area Network LMI Local Management Interface LP Logical Processor LS Liaison Spécialisée MIB Management Information Base MPLS Multi-Protocol Label Switching MSA32 Multi Service Access 32 NMS Network Management System NNI Node Network Interface OC-X Optical Carrier – X OID Object IDentifier OSI Open Systems Interconnexion PNNI Private Network to Network Interface POP Point Of Presence PVC Permanent Virtual Circuit QoS Quality of Service RDLCI Remote Data Link Connection Identifier RDNA Remote Data Network Address RFC Request For Comment RNIS Réseau Numérique à Intégration de Service SDH Synchronous Digital Hierarchy SDSL Symetric Digital Subscriber Line SMI Structure of Managed Information SMTP Simple Mail Transfert Protocol SNMP Simple Network Management Protocol
  • 9. TABLE DES MATIÈRES viii SOAP Simple Object Access Protocol SONET Synchronous Optical Network SS7 Signaling System 7 SSH Secure Shell SSL Secure Sockets Layer STM-1 Synchronous Transfert Mode 1 SVC Switched Virtual Circuit TCP Transmit Control Protocol TDM Time Division Multiplexing TLS Transport Layer Security UBR Unspecified Bite Rate UDP User Datagram Protocol UIT Union International des Télécommunications UML Unified Modeling Language UNI User Network Interface UP Unified Process VBR-NRT Variable Bit Rate - Non Real Time VBR-RT Variable Bit Rate - Real Time VCC Virtual Circuit Connection VCI Virtual Circuit Identifier VES Virtual Execution System VP Virtual Path VPI Virtual Path Identifier VSS Variable Speed Switch XML eXtensible Markup Language
  • 10. Table des figures 2.1 Exemple de Liaison Frame Relay sur ATM . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Exemple de Liaison Spécialisée à émulation de circuit sur ATM . . . . . . . . . . . . . . . 6 2.3 Réseau maillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Réseaux d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 Nortel Passport 7480 El Kasbah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6 Nortel Passport 15000-VSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.7 Réseau ATM Nortel de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.8 Relations entre manager, agents et protocole . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.9 Architecture SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.10 Structure d’indexation des données dans la MIB-2 SNMP . . . . . . . . . . . . . . . . . . 15 2.11 Exemple de session Telnet sur un commutateur Nortel 7480 . . . . . . . . . . . . . . . . . 16 2.12 Gestion In-band sur le réseau ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Création des exigences dans Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Synoptique de la démarche de construction du modèle des cas d’utilisation, [Roques :2008}] 22 3.3 Acteurs du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Organisation des cas d’utilisation et des acteurs en packages (avec l’outil Enterprise Ar- chitect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 Cas d’utilisation création de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.6 Cas d’utilisation modification de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.7 Cas d’utilisation supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.8 Cas d’utilisation exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9 Cas d’utilisation maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.10 Organisation complétée des cas d’utilisation et des acteurs . . . . . . . . . . . . . . . . . . 27 3.11 Matrice de traçabilité entre cas d’utilisation et exigences . . . . . . . . . . . . . . . . . . . 28 3.12 Diagramme de séquence système Créer une liaison Frame Relay port et circuit . . . . . . 33 3.13 Diagramme de séquence système Créer une liaison spécialisée émulée sur ATM . . . . . . 34 3.14 Diagramme de séquence système Lister les abonnés . . . . . . . . . . . . . . . . . . . . . . 34 3.15 Diagramme de séquence système Afficher les circuits virtuels d’un lien Physique Frame Relay 35 3.16 Diagramme de séquence système Gérer les multiplexeurs . . . . . . . . . . . . . . . . . . 35 3.17 Diagramme de séquence système Backup des configurations . . . . . . . . . . . . . . . . . 36 3.18 Diagramme de séquence système Gérer les espaces disque . . . . . . . . . . . . . . . . . . 36 3.19 Diagramme de séquence système Examen de la boucle locale . . . . . . . . . . . . . . . . 37 3.20 Diagramme de séquence supervision du trafic . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.21 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.22 Diagramme d’état Création liaison FR port et circuit . . . . . . . . . . . . . . . . . . . . . 40 3.23 Diagramme d’état Supervision du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 ix
  • 11. TABLE DES FIGURES x 3.24 Diagramme d’état : Gérer l’espace disque . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.25 Schéma Conceptuel de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1 Ensemble Framework .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2 IDE Microsoft Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3 Architecture du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4 Schéma de fonctionnement du service TraficInfo . . . . . . . . . . . . . . . . . . . . . . . . 46 4.5 Fonctionnement du service AlarmeManage . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.6 Fonctionnement du service BackupAuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.7 Page de configuration de la sauvegarde automatique . . . . . . . . . . . . . . . . . . . . . 48 4.8 Page de connexion au NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.9 Page d’accueil du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.10 Listing des cartes d’un commutateur Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.11 Les lignes de la carte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.12 Les détails d’une ligne E1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.13 Page de création d’une nouvelle liaison Frame Relay . . . . . . . . . . . . . . . . . . . . . 51 4.14 Page de résumé Création Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.15 Création d’une LS à émulation de circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.16 Résumé de Création d’une LS à émulation de circuit . . . . . . . . . . . . . . . . . . . . . 52 4.17 Liste des abonnés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.18 Informations détaillées sur une liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.19 Test d’une liaison Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.20 Graphe d’évolution du trafic en fonction du temps . . . . . . . . . . . . . . . . . . . . . . 54 4.21 Occupation de l’espace disque d’un commutateur . . . . . . . . . . . . . . . . . . . . . . . 55 4.22 Sélection des fichiers à supprimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.23 Alarme(s) détectée(s) par NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.24 Liste des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.25 Traitement des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 A.1 Format d’une cellule ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2 La double identification d’ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.3 Architecture ATM, [Servin :2003] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 A.4 La signalisation dans ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 B.1 Représentation basique Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 B.2 Identification des liens logiques par le DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . 66 B.3 Contrôle de gestion dans les réseaux haut débit . . . . . . . . . . . . . . . . . . . . . . . . 67 B.4 Contrôle de gestion dans les réseaux haut débit . . . . . . . . . . . . . . . . . . . . . . . . 67 B.5 Echange de message synchrone sur l’état des liens . . . . . . . . . . . . . . . . . . . . . . 68
  • 12. Introduction Générale L es réseaux de télécommunications touchent de plus en plus notre vie quotidienne. On compte sur les services offerts par les réseaux pour assurer les transactions bancaires, les recherches web, la téléconférence. Les services rendus par les réseaux sont devenu indispensable. Face à cette évolution, Tunisie Telecom a élargie et diversifiée son réseau qui est devenu complexe. Pour gérer un tel réseau, et assurer la qualité des services qu’il rend, Tunisie Telecom doit recourir à des applications très évoluées et intelligentes qui permettent de surveiller le réseau, de l’exploiter, et d’agir quand un problème survient. Mais le coût de développement de ces applications par les tiers (équipementiers, sociétés de développement, etc. . . ) est excessivement élevé. Tunisie Telecom utilise les compétences de ses cadres pour le développement de telles applications. C’est dans ce cadre que s’inscrit notre projet. Le projet que nous avons réalisé consiste au développement d’une application de gestion des commutateurs ATM Nortel de Tunisie Telecom. A la fin de ce projet, l’application qui sera développée, devra être un outil à part intégrante pour les agents du NOC (National Operation Center) et ROCs (Regional Operation Centers) DATA de la direction exécutive des Backbones de Tunisie Telecom. Le premier chapitre sera réservé à la présentation de Tunisie Telecom, du cadre général du projet, ainsi qu’à la problématique et à l’objectif fixé pour notre projet. Le deuxième chapitre s’articulera autour de la description du Backbone ATM de Tunisie Telecom ainsi que de sa gestion. Le troisième chapitre sera consacré à la conception de la future application. Le quatrième chapitre présentera les outils et l’environnement de développement, le développement des services et de l’application lui-même. 1
  • 13. Chapitre 1 Présentation du Projet Introduction Dans ce chapitre, nous allons présenter notre stage. Pour se faire, nous présentons d’abord notre organisme d’accueil à savoir ‘Tunisie Telecom’, par la suite nous décrirons la problématique et les objectifs spécifiques à atteindre de notre projet. 1.1 Présentation de l’organisme d’accueil Le 1er janvier 1996, l’office national des télécommunications (ONT) ou « TUNISIE TELECOM » est entrée en activité en tant qu’opérateur de télécommunication doté de sa propre autonomie et son propre réseau (sous la forme juridique d’établissement public à caractère industriel et commercial). Tunisie Télécom a pour mission d’assurer toutes les activités relatives au domaine des télécommuni- cations : – La coopération avec les organismes similaires et l’application des traités internationaux en matière de télécommunication – L’installation, le développement, l’entretien et l’exploitation des réseaux publics de télécommuni- cation et en particulier, les réseaux de téléphone et de transmission de données. – La promotion de nouveaux services de télécommunication à travers l’installation de l’équipement technologique dans le domaine la contribution au développement aux études et recherches scienti- fiques liées au secteur des télécommunications. National operating Center – NOC DATA Sous tutelle de la Direction des Backbones, Le NOC DATA, est le centre national des opérations de gestion, de maintenance, et de supervision des réseaux de transmission de données à l’échelle nationale. Il a pour tâche : – La gestion des équipements de transmission de données (Commutateurs, Multiplexeurs, DSLAM etc.) – L’administration des équipements (la sauvegarde des fichiers de configurations. . . ) – La supervision des réseaux de transmission sur tout le territoire national 24h/24 et 7j/7 – La Supervision des températures des équipements ; – Supervise les alarmes sur les équipements sur les liaisons ; – Ouverture des tickets pour les conservés (CTDR, Centre de transmission) ; 2
  • 14. CHAPITRE 1. PRÉSENTATION DU PROJET 3 – La gestion des abonnés : – L’étude des nouvelles demandes des liaisons de transmission de donnée (LS national et interna- tional, frame Relay, SDSL, et etc.), depuis la saisie dans l’ACTEL (agence commerciale) jusqu’à la mise en service par le CTDR (centre de transmission de Données régional) concerné. – Les configurations nécessaires pour la mise en service des créations des nouveaux abonnés tel que Frame Relay, ligne spécialisée national et international, ADSL, SDSL, et ATM. Le NOC comprend des groupes de soutien qui ont pour tâche : – Configuration des nouveaux sites, installation, Backup, mise à jour de nouvelles cartes – Intervenir dans les grands problèmes sur les réseaux – Suivre la stabilité des réseaux – Mise à jour des DSLAM (upgrade : nouveau soft) – Basculement des sites, trafic – Statistique sur les liaisons internes (inter-sites) pour détecter s’il y a une congestion et d’améliorer la qualité du trafic – Et etc. 1.2 Problématique Dans la situation actuelle, le traitement des requêtes de nouvelle connexion Frame Relay, de liaison spécialisée émulée sur ATM, la supervision des lignes Frame-Relay, la gestion des espaces disque, etc. . . se font en ligne de commandes. Le problème de gestion de la congestion des liaisons inter-sites. Vu le nombre important de tâches, il est très fastidieux de les effectuer en ligne de commandes, il n’offre pas une vue synthétique de l’infrastructure, les erreurs de configurations sont très fréquentes. La sauvegarde manuelle des fichiers de configuration des commutateurs entraine souvent leurs pertes et parfois l’oublie de la sauvegarde de ces fichiers sont suivi de conséquences désastreuses. Tous ces problèmes causent une mauvaise exploitation des ressources disponibles et une grande perte de temps. Pour maintenir ces réseaux opérationnel et disponible, des techniques et des outils avancés ont dû être inventés pour assurer son fonctionnement et son administration. Notre projet vise à remédier à des problèmes tels que : – Travail fastidieux, et entrainant une grande perte de temps en ligne de commandes – Sauvegarde manuelle des fichiers de configuration – Manque de suivi efficace des commutateurs ATM Nortel (Volume de trafic, états des interfaces, espace disque, alarmes . . . ) – Gestion de la congestion des liaisons inter-sites. . . 1.3 Objectifs Le NOC DATA de Tunisie Telecom a décidé de se doter d’un outil de travail efficace et performant qui leur permettra de remplir plus amplement les différentes missions qui les ont été confié et de remédier aux nombreux problèmes cités ci-dessus. L’objectif fondamental de ce projet est de permettre aux utilisateurs de créer des liaisons Frame Relay, de liaisons spécialisée émulée sur ATM, de mieux gérer la congestion, de superviser en temps réel les liaisons inter-sites, la gestion automatique de la sauvegarde des fichiers de configurations etc. . . via une interface web interactive et attractive. Cette application sera particulièrement utile dans l’exécution des différentes tâches assignées aux agents du NOC DATA de Tunisie Telecom.
  • 15. CHAPITRE 1. PRÉSENTATION DU PROJET 4 L’application devra donc être facilement évolutive pour pouvoir implémenter très rapidement de nou- velles fonctionnalités importantes. Conclusion Au terme de ce chapitre, nous avons présenté l’organisme d’accueil, et dégagé la problématique. Nous avons également défini les objectifs de notre projet. Le prochain chapitre sera consacré au Backbone ATM de Tunisie Telecom.
  • 16. Chapitre 2 Backbone ATM de Tunisie Telecom Introduction Littéralement appelé épine dorsale ou encore cœur du réseau, le Backbone constitue le centre névral- gique du réseau de transport de données à l’échelle d’un territoire national. Sur ce réseau viennent se greffer les réseaux des fournisseurs de services internet, des réseaux de grandes entreprises, etc. C’est la partie qui supporte le gros du trafic, en utilisant les technologies de transmission de données les plus rapides et une grande bande passante sur des distantes importantes. Les liaisons qui forment le Backbone sont constituées majoritairement de câble à fibres optiques. A Tunisie Telecom, ce réseau fédérateur est subdivisé en deux parties : Le Backbone ATM et le Backbone IP/MPLS. La suite de ce chapitre sera consacrée au Backbone ATM et de sa gestion. 2.1 Description Le Backbone ATM national dont Tunisie Telecom s’occupe de son évolution ainsi que de sa gestion est constitué de près de 20 commutateurs ATM Nortel et de 20 commutateurs ATM Alcatel éparpillé sur tout le territoire tunisien. Ces commutateurs sont caractérisés par leur bonne performance, ils assurent une couverture maximale du pays, leur fonction principale est de permettre un transport fluide et efficace du trafic transitant sur le Backbone. Les clients ne sont pas directement connectés via les commutateurs principaux, mais à travers des multiplexeurs d’accès qui sont à leurs tours connectés aux commutateurs d’accès qui permettent d’assurer l’interconnections des différents types d’utilisateurs (LS, FR, ADSL). Les clients sont essentiellement les banques, les grandes entreprises, les Fournisseurs de services internet FSI, les agences nationaux ou internationaux, etc. Figure 2.1 – Exemple de Liaison Frame Relay sur ATM 5
  • 17. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 6 Figure 2.2 – Exemple de Liaison Spécialisée à émulation de circuit sur ATM Le Backbone ATM de Tunisie Telecom est un réseau maillé. Un réseau maillé, est un réseau dans lequel deux stations, clientes du réseau, peuvent être mis en relation par différents chemins (figure 2.3). Ce type de réseau, permettant de multiple choix de chemins vers une même destination, est très résistant à la défaillance d’un nœud et autorise une optimisation de l’emploi des ressources en répartissant la charge entre les différents nœuds. Cela permet d’éviter d’avoir des points sensibles, qui en cas de panne, coupent la connexion d’une partie du réseau. Figure 2.3 – Réseau maillé Pour assurer la fiabilité du Backbone, une architecture redondante est mise en place pour l’intercon- nexion des commutateurs principaux. Un site doit être relié au moins à deux sites différents pour assurer à la fois le basculement du trafic en cas de panne ainsi que le partage de charge (Load Balancing) en cas de congestion. En effet la redondance est une caractéristique essentielle au fonctionnement d’un tel réseau. Le terme redondance est utilisé pour désigner deux serveurs ou deux cartes de contrôles (Contient la configuration du commutateur) dédoublé. Si l’un des serveurs tombe en panne le deuxième prend automatiquement le relais empêchant ainsi l’arrêt de la supervision du réseau ; un seul des deux (peut être plusieurs) fonctionne à la fois, le second démarrant qu’en cas de panne du premier. En effet les serveurs permettent de bien assurer la surveillance du réseau. Pour les cartes de contrôles, la redondance permet d’éviter l’arrêt d’une portion du réseau si la première carte tombe en défaillance, la deuxième prendra automatiquement la relève. C’est un atout majeur pour un réseau en production car il permet au réseau d’assurer une très grande fiabilité.
  • 18. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 7 2.2 Architecture Le Backbone multiservices ATM/Frame-Relay Nortel est constitué de commutateurs d’accès, commu- tateurs principaux et de multiplexeurs d’accès. 2.2.1 Les équipements d’accès Les multiplexeurs d’accès permettent le multiplexage et le démultiplexage des flux des différents clients en entrée et en sortie du réseau. Les multiplexeurs d’accès multiservice rassemblent, brassent les flux en provenance du client vers le réseau IP/MPLS, ATM, International, etc. sur des liens à fibres optiques, paire torsadée. Ces unités sont au sein des points de présence (POP : Point Of Presence) appartenant à Tunisie Telecom. Figure 2.4 – Réseaux d’accès Un multiplexeur a une ou plusieurs liaisons avec d’autres multiplexeurs pouvant être Master ou Slave. Le terme Master (Maitre) ou Slave (Esclave) désigne le fait que la gestion du multiplexeur Slave s’effectue via le multiplexeur Master. Le multiplexeur d’accès (figure 2.4) fait passer le trafic à destination du Backbone IP/MPLS (Internet Protocol/Multi Protocol Label Switching) sur une liaison STM-1 (Synchronous Transfert Mode-1 équi- valent de 155 Mbps) à fibre optique jusqu’au routeur MPLS. Le trafic destiné au Backbone ATM passe par une liaison E1/T1 (2 Mbps) jusqu’au commutateur d’accès ATM. Il assure également à travers un lien 2 Mbps une liaison international, cette liaison est généralement attribuée aux ambassades, aux centres d’appels et d’autres entreprises étrangères. Une autre liaison 2 Mbps peut être attribuée aux fournisseurs de services internet FSI souhaitant avoir des clients qui veulent des liaisons spécialisées internet. Les multiplexeurs d’accès utilisés par Tunisie Telecom sont des multiplexeurs Patton, Paradyne et Sagem. 2.2.2 Les équipements du Cœur du réseau Les commutateurs d’accès ATM sont des commutateurs situés au bord du Backbone ATM de Tunisie Telecom, faisant eux même parties du Backbone. Ils connectent les réseaux locaux (LAN) des utilisateurs finaux au réseau fédérateur de l’opérateur. Ils permettent également la conversion des trames provenant
  • 19. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 8 des LAN du client en des cellules ATM et vice versa. Ils l’établissement de circuit virtuel dans le réseau ATM et envoient le trafic sur le Backbone ATM. Ils agrègent les liens de faible débit à partir des réseaux clients en très haut débit sur le Backbone et vice versa. Les commutateurs principaux sont des commutateurs de très grandes capacités placés dans le cœur du réseau (Backbone) et servant à interconnecter des commutateurs d’accès. Bien que ces commutateurs peuvent être très intelligent, ils ne fonctionnent que dans la couche 2 du modèle de référence OSI (Open Systems Interconnection). Encore appelés brasseurs, ils assurent la commutation de faisceaux virtuels en interne dans le réseau. La gamme Nortel Passport 7480 est utilisée comme commutateurs d’accès. Commutateur Nortel Passport 7480 : Le Commutateur Nortel Passport 7480 livre une gamme puissante d’interfaces à base de norme et des services, y compris Frame Relay, l’ATM et IP. Le Passport 7480 offre l’acheminement des services multi protocoles, la gestion intelligente du trafic et supporte simultanément la voix, des données, la vidéo et l’image. Il offre une très grande fiabilité et la redondance exigée par les fournisseurs de services. Il est composé de deux Control Processor (CP) et de Function Processors (FP). Le Control Processor (CP) contrôle tout le traitement qui s’effectue dans le commutateur. Il gère les FPs (Function Processors) sur le Shelf (étagère sur lequel sont rangés les FPs) et fournit des fonctionnalités systèmes de base telles que la surveillance du Self et le traitement alarmes. Le CP fournit également l’horloge du bus, le stockage de fichiers, la collecte de données, le maintien de la table de routage à jour, le traitement des commandes, et des interfaces pour la gestion. Le commutateur Passport 7480 comprend deux CP, l’un actif et le deuxième en standby (veille). Si le premier tombe en panne, le second prend la relève. Les Function Processors(FPs) sont des d’interfaces de communications qui relient les segments réseaux au commutateur. Ils permettent l’exécution en temps réel des processus qui sont essentiels à la prestation des services (réseaux). Chaque FP supporte un ou plusieurs services. On peut citer entre autre E1 MSA32 (Multi Service Access) Function Processor, E3 Function Processor, OC-3 Function Processor etc... Dans le cadre des télécommunications numériques, où une simple paire physique de fils peut être utilisée pour transporter de nombreuses communications vocales simultanées au moyen du multiplexage temporel TDM (Time Division Multiplexing), des standards à l’échelle mondiale ont été créés et déployés. La Conférence Européenne des administrations des Postes et Télécommunications (CEPT) a standardisé le système E-carrier, qui pourrait se traduire en transporteur E. Ce nouveau standard constitue une révi- sion et une amélioration de la précédente technologie américaine T-carrier. E-carrier est à présent adopté par l’Union Internationale des Télécommunications, section de la standardisation des télécommunications (UIT-T). E-carrier est à présent utilisé dans presque tous les pays de la planète hors des États-Unis, du Canada et du Japon. Un E1 transporte 32 tranches temporelles (Time Slots) et un E3 en transporte 512, dont une tranche servant à délimiter les trames. Chaque tranche de temps transporte un DS0 (64 Kbps) soit l’équivalent de 2 Mbps pour E1 et 34 Mbps pour E3. Les circuits E1 sont très utilisés pour connecter des entreprises de moyenne ou grande taille, des commutateurs distants et la plupart du temps entre commutateurs. Les lignes E3 sont utilisées entre commutateurs, entre les opérateurs et fournisseurs de services internet (ex : Globalnet, Planet). Basé sur un signal optique multiple de 51,84 Mbps, le standard OC (Optical Carrier) a été défini selon le modèle SONET (Synchronous Optical Network). Il répertorie plusieurs types de lignes en fonction de leur débit. Sa syntaxe est OC-x avec le x comme coefficient multiplicateur. OC-3 est l’équivalent de 3*51,84 = 155 Mbps. L’équivalent d’OC-3 dans la hiérarchie SDH (Synchronous Digital Hierarchy) en europe est STM-1. Le Passport 7480 comprend plusieurs 3 ports OC-3 qui permet de relier aux commutateurs princi- paux et à d’autres commutateurs d’accès. Il comprend également plusieurs cartes E1 MSA-32, et qui comprennent chacun 32 E1. Chaque E1 supporte simultanément plusieurs types de services Frame Relay,
  • 20. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 9 AAL1 Circuit Emulation Service (Aal1Ces), ATM Service et etc. Figure 2.5 – Nortel Passport 7480 El Kasbah La gamme Nortel Passport 15000-VSS est utilisée comme commutateurs principaux. Commutateur Nortel Passport 15000-VSS (Variable Speed Switch) : Le commutateur Nortel Passport 15000-VSS est un combiné de commutateur d’accès et de commuta- teur principal multiservices. En plus de l’ATM, il délivre un large éventail d’interfaces et services très haut débit basés sur standard, y compris le Frame Relay, l’émulation de circuit, la voix et l’IP. Ces interfaces fournissent une grande variété d’accès et d’agrégation de vitesse de DS-0 (64 Kbps) à OC-48 (2 488,32 Mbps). Il est composé du Passport 7480 et du Passport 15000. Le Passport 15000 est un commutateur de données basé sur ATM qui peut être déployé comme commutateurs principal pour un réseau de com- mutateurs d’accès existant. En outre de l’ATM, il délivre une gamme puissante d’interfaces et de services basés sur des standards y compris le Frame Relay et IP. Il offre une très grande redondance, d’évolutivité et une très grande capacité d’agrégation et d’intégration SDH/SONET (optionnel).
  • 21. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 10 Figure 2.6 – Nortel Passport 15000-VSS En outre de leur capacité de gestion intelligente du trafic, ils supportent simultanément les trafics de la voix, les données, la vidéo et l’image, en un mot des commutateurs multiservices. Ils offrent une redondance complète, évolutive à grande capacité, haute vitesse d’accès et de raccordement au réseau. De configuration matérielle et logiciel modulaire, on peut modifier la configuration des composants matériels et logiciels pour chaque site selon les besoins. Figure 2.7 – Réseau ATM Nortel de Tunisie Telecom
  • 22. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 11 2.3 La gestion de réseau Le Backbone ATM de Tunisie Télécom est l’un des réseaux les plus étendus dans toute la Tunisie. Devant la complexité d’un tel réseau, le concept gestion de réseau est devenu une nécessité afin d’assurer son administration et pouvoir faire des prévisions. 2.3.1 But et domaine d’application La notion de gestion s’applique essentiellement dans un contexte de réseau privé. L’idée maîtresse de la supervision est de contrôler la fiabilité et la pérennité du réseau, des services informatiques afin de mesurer la Qualité de Service (QoS, Quality of Service). Cette notion de QoS n’est pas récente, mais elle est devenue le point d’intérêt central des stratégies de développement d’entreprise. La situation économique actuelle peu favorable exige des entreprises qu’elles contrôlent leurs dépenses. La tendance n’est pas à l’investissement dans de nouvelles technologies, mais à l’optimisation et au rendement de l’existant à moindre coût. De plus, l’évolution des méthodes de travail au sein même de l’entreprise veut qu’une part de plus en plus importante de l’activité de celle-ci sollicite les outils informatiques. Dans le cas des sociétés de services en informatique, c’est toute l’activité des ingénieurs et dirigeants qui reposent intégralement sur la bonne disponibilité des services informatiques et réseaux. C’est dans cette volonté de contrôle que s’intègre la supervision de réseaux. L’objectif des opérateurs d’un centre de supervision est donc de pouvoir connaître en permanence l’état du réseau, et d’être averti en temps réel des différents incidents pour réduire au maximum les délais d’intervention et de coupure du service, et d’exploiter au mieux les capacités du réseau. A présent, de nouveaux besoins se font sentir. Le premier besoin est de rompre la contrainte de proximité de l’équipement à gérer. Avec les protocoles de gestion de réseau actuels, le réseau est utilisé afin de permettre la gestion des équipements le composant. On se trouve donc dans le cas d’une gestion du réseau par le réseau. Le second besoin concerne la dépendance humaine. La complexité des réseaux s’accroissant, la tâche de gestion du réseau exige une telle masse d’informations à traiter qu’elle dépasse la capacité de l’être humain. En effet, il faut remarquer que chaque information individuelle sur un équipement ne peut être utilisée telle quelle, elle n’est significative que dans le contexte du réseau global. Les considérations énoncées ci-dessus permettent d’identifier les besoins de la gestion des réseaux : – S’adapter à toutes les tailles de réseaux. – Gérer des équipements hétérogènes et possiblement complexes. – Permettre les opérations de gestion à distance. – Assister l’utilisateur en : – Automatisant certaines tâches. – Aidant l’utilisateur dans les tâches qui ne sont pas automatisées. Fournissant une vue adaptée du réseau selon les opérations à réaliser. 2.3.2 Fonctionnalités Une bonne gestion de réseau permet l’utilisation optimale de toutes les ressources offertes par le réseau. La gestion de réseau a trois fonctions : l’exploitation, la supervision et la maintenance. 2.3.2.1 L’exploitation Un système de gestion de réseau doit permettre l’exploitation du réseau au mieux de ses capacités et des services que ce dernier propose. Si nous prenons l’exemple du Backbone ATM de Tunisie Telecom, il doit permettre la gestion des abonnés présents sur chaque partie du réseau (Frame Relay, ATM, IP/MPLS, etc.) c’est-à-dire ajouter, modifier ou résilier sur tous les éléments du réseau (soit les cartes vers les
  • 23. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 12 abonnés ou les cartes vers le cœur du réseau). L’exploitation du réseau consiste aussi à ajouter de nouveau équipement au réseau afin de l’étendre (multiplexeur, commutateur ou routeur etc.), à sauvegarder les fichiers de configurations des équipements etc. La tâche d’exploitation d’un réseau est délicat d’autant plus qu’on doit prendre le soin de ne jamais dépasser les quantités de ressources que le réseau met à notre disposition. 2.3.2.2 La supervision Un logiciel qui fait de la gestion de réseau doit amasser toutes les informations de gestion dont il a besoin. Ces informations parviennent de chacun des éléments du réseau. Pour les obtenir, une étape de découverte des éléments de réseau est effectuée, puis les requêtes sont envoyées aux éléments un à un pour en tirer les informations de gestion. Ces informations de gestion comprennent toutes sortes d’informations reliées à un élément de réseau : le type d’équipement, le nombre de paquets qui passent sur chaque port d’un routeur, l’usager qui utilise une station de travail... Pour effectuer cette tâche, une technique pour démasquer les éléments de réseaux est nécessaire. Un protocole pour obtenir les informations de gestion est aussi nécessaire. SNMP est un protocole qui permet de réaliser ces fonctionnalités. Une fois que l’on a les informations de gestion, il est important de les interpréter correctement. Par exemple : 5000 paquets par seconde sur un port d’un routeur est peut-être normal ou peut-être le signe d’une surcharge et d’une dégradation de la qualité du service offert. Même si on connaît la charge exacte d’un routeur, cette information ne suffit pas pour prendre des décisions pertinentes de gestion. Les manufacturiers d’équipements offrent quelquefois des logiciels qui savent interpréter les informa- tions de gestion de leurs équipements de gestion. Toutefois, une interprétation automatique complète et correcte de l’état d’un réseau et de ses équipements est difficile à réaliser. L’intervention humaine est souvent requise pour interpréter les données ou pour placer des bornes acceptables. 2.3.2.3 La maintenance Quand des informations de gestion sont obtenues et interprétées, il est quelquefois nécessaire d’agir. Il doit être possible de demander à un équipement, par exemple, de se réinitialiser, de couper ou d’activer des services... Pour ce faire, un protocole de gestion doit transmettre un ordre (requête) à l’équipement approprié pour déclencher l’action. En raison de l’absence de sécurité par le passé, cette fonctionnalité a rarement été utilisée. 2.3.3 Principes de la gestion de réseau Les architectures de gestion de réseau sont classées dans la catégorie des systèmes client/serveur. On peut donc identifier trois composants : – La partie client, appelée manager, est l’entité qui va superviser les opérations de gestion. Elle sert d’interface entre l’utilisateur et le serveur. Il peut y avoir, le cas échéant, plusieurs managers. – La partie serveur, appelée agent représente un ou plusieurs équipements. Un agent sert d’interface entre l’équipement et le manager. Il peut également servir d’interface entre plusieurs autres agents et le manager. L’agent permet de fournir une vue abstraite de l’équipement et masque ainsi les différences qui existent entre les équipements. Il y a bien entendu plusieurs agents dans un réseau. – Le protocole est le langage utilisé par le manager et l’agent pour communiquer (SNMP, CMIS, CMIP, . . . ) Il est mis en œuvre par le biais d’un réseau. Ce protocole permet au manager d’interroger l’agent (dans le cas du monitoring) ou de lui demander de modifier l’état de l’équipement (dans le
  • 24. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 13 cas de la configuration). Le protocole est également utilisé par l’agent afin d’avertir le manager de l’occurrence d’événements. Figure 2.8 – Relations entre manager, agents et protocole Dans le cadre de notre projet nous avons opté pour l’utilisation du protocole SNMP (Simple Network Management Protocol) qui offre une grande panoplie de fonctionnalités et disponible sur les commutateurs Nortel. Comme son nom l’indique, c’est un protocole très simple à utiliser du fait du nombre très limités de ses requêtes : GET, GET-NEXT, SET, et les TRAP. 2.3.4 SNMP L’activité de recherche et de standardisation au niveau de SNMP est menée sous l’égide de l’IETF (Internet Engineering Task Force). La première version de SNMP a vu le jour en 1989. La seconde version, appelée SNMP v2 a été standardisée en 1992 [RFC1905]. Cette version apporte essentiellement des changements au niveau de la sécurité et de la confidentialité des opérations de gestion. Suite à des problèmes apparus lors de la mise en opération de la seconde version du protocole, ces aspects ont été classés obsolètes en 1996 lors d’un des meetings trisannuel de l’IETF. Ce dernier rebondissement a eu pour effet, d’une part de renvoyer SNMP à son état de 1989 et d’autre part, de déclencher les recherches sur SNMP v3. Les travaux se poursuivent actuellement et petit à petit les différents éléments de l’architecture SNMP v3 sont proposés à la communauté scientifique [RFC2274]. SNMP v3 (dans les aspects qui sont actuellement définis) est en passe de devenir un standard car il est accepté par le working group SNMP v3 en tant que proposed standard. A l’heure actuelle, SNMP v1 reste la version la plus utilisée. De plus, les résultats obtenus avec SNMP v1 sont immédiatement applicables à SNMP-v2.
  • 25. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 14 SNMP suit l’architecture client/serveur, le client étant le manager et le serveur l’agent. Contrairement aux architectures client/serveur habituelles où un serveur interagit avec plusieurs clients, SNMP est l’exemple d’un schéma inverse : un client, souvent unique, communique avec plusieurs serveurs. Il y a un agent par équipement à gérer. L’agent conserve une série de variables qui modélisent l’équipement. Le manager, au travers de l’agent, consulte et/ou modifie les valeurs des variables à l’aide d’opérations de management. Des changements d’état internes à l’équipement modifient eux aussi les valeurs des variables. La manière dont l’agent doit être informé de ces changements n’est pas spécifiée dans SNMP. L’ensemble des variables gérées est appelé MIB (Management Information Base). Le manager interagit avec l’agent via un protocole de communication qui spécifie la dynamique de la communication (mécanismes de question/réponse), ainsi que la structure des messages échangés. Figure 2.9 – Architecture SNMP La Management Information Base (MIB) contient les variables qui forment le modèle informationnel de l’équipement. Les variables sont organisées sous une forme arborescente. Les nœuds intermédiaires servent uniquement de points de rattachement pour les branches, ils ne contiennent aucune valeur. Les feuilles par contre stockent des valeurs. La MIB déclaration est décrite à l’aide d’un langage spécifié dans un standard appelé Structure of Managed Information (SMI). Pour SNMP v1, ce standard est le Request For Comment 1155 [RFC1155]. Le langage utilise pour sa définition la syntaxe ASN.1. Chaque objet qui y est déclaré inclut les informations suivantes : – Un nom. – Un type : il s’agit soit d’un type simple : INTEGER, OCTET-STRING, NULL, soit d’un type de construction : SEQUENCE-OF, SEQUENCE, soit d’un type spécifique : NetworkAddress, IpAd- dress, Counter, Gauge, TimeTicks. – Un modificateur d’accès : read-write, read-only, write-only, not-acessible. – Un modificateur de statut : mandatory, optional, obsolete. – Une description : il s’agit d’un texte en langage naturel, qui décrit l’utilité de l’objet.
  • 26. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 15 Figure 2.10 – Structure d’indexation des données dans la MIB-2 SNMP L’objet snmpInPkts dans MIB II : snmpInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of Messages delivered to the SNMP entity from the transport service." : := { snmp 1 } Les objets et instances sont nommés par un identificateur que l’on appelle Object IDentifier. Il s’agit d’une suite de nombres séparés par des points. La dot notation fournit un chemin dans l’arbre à partir de la racine. La racine est identifiée par le nombre ’1’. Le nombre suivant, c’est-à-dire le second nombre dans la dot notation, identifie le numéro du fils de la racine. On procède récursivement jusqu’à la fin de l’object identifier. A titre d’exemple, l’objet snmpInPkts possède comme object identifier 1.3.6.1.2.1.11.1. Les cinq premiers identificateurs sont fixes car ils correspondent à la racine de toute l’arborescence de management : iso(1).org(3).dod(6).internet(1).mgmt(2) Le sixième identificateur correspond à mib2(1) qui est la MIB permettant de gérer un stack TCP/IP standard. L’objet snmpInPkts est le premier fils en partant de la gauche du groupe snmp qui lui-même a l’identificateur 11. On utilise comme notation abrégée snmp(11). L’object identifier d’une instance est construit sur base de l’Object IDentifier de l’objet correspondant. Suivant que l’instance appartienne à une table (un ensemble de lignes) ou soit une instance isolée (appelée variable simple) le schéma de construction est différent. Dans le cas des variables simples, on postfixe l’identificateur de l’objet par un numéro d’instance. Les instances sont numérotées à partir de zéro. L’instance correspondant à l’objet
  • 27. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 16 snmpInPkts sera donc identifiée par 1.3.6.1.2.1.11.1.0. Si une instance supplémentaire existe (ce qui n’est pas le cas ici), elle porte l’identificateur 1.3.6.1.2.1.11.1.1 et ainsi de suite. L’accès à des instances appartenant à des tables est plus complexe, car SNMP utilise le concept d’adressage associatif. La simplicité de SNMP est en partie due à la simplicité de ses opérations de gestion. Il y en a quatre : – GET : permet au manager de récupérer la valeur contenue dans une instance. – SET : permet au manager d’assigner une valeur à une instance. – GET-NEXT : permet à partir d’un point de l’arborescence de trouver l’instance la plus proche. – TRAP : permet à l’agent d’envoyer une notification spontanée au manager. Le port standard utiliser par SNMP pour la communication est le port UDP 161, en utilisant les sockets ; La distinction est faite entre une opération SNMP et une requête SNMP. Les relations entre ces deux concepts sont les suivantes : – Une requête SNMP contient plusieurs opérations. – Toutes les opérations d’une requête doivent être du même type (ex : uniquement des GET). 2.3.5 Le Protocole Telnet Le premier protocole historique est Telnet. Ce protocole TCP est largement utilisé pour le contrôle à distance de matériel réseau. La conception est excessivement simple : une fois que l’on est connecté à la machine distante, les touches tapées au clavier sont directement transmises à la machine distante et Telnet nous renvoie les réponses de ladite machine. Généralement, la machine distante commence la transaction par nous demander un mot de passe d’accès, puis nous donne accès à un shell (terminal) sur lequel nous pouvons lancer nos commandes. Figure 2.11 – Exemple de session Telnet sur un commutateur Nortel 7480 Ci-dessus nous pouvons analyser l’exemple d’une session Telnet sur un commutateur Nortel. Ici « d Fruni/21905 dlci/* » nous affiche la liste des circuits du Frame Relay N° 21905. Telnet n’est pas un protocole fournissant une interface commune à tous les matériels réseau. Chaque constructeur inclut son propre gestionnaire Telnet personnalisé, et la gestion du réseau n’est donc pas uniforme suivant le type de matériel. Telnet assure intrinsèquement la fiabilité de la transaction de par l’utilisation du protocole TCP, toutefois la communication entre l’administrateur et le matériel n’est pas cryptée et la seule sécurité apportée est l’authentification initiale. Le protocole SSH (Secure SHell) comble cette lacune en cryptant la transaction via le protocole SSL. Toutefois l’interface reste propre à chaque matériel et ne permet pas d’effectuer des transactions parallèles ou une gestion uniforme de ceux-ci.
  • 28. CHAPITRE 2. BACKBONE ATM DE TUNISIE TELECOM 17 2.3.6 Autres protocoles de gestion de réseau D’autres protocoles de gestion existent. CMIP (Common Management Information Protocol), proto- cole OSI de gestion de réseau, utilisant les services CMIS (Common Management Information Service) pour leur administration, supervision comprise, à distance. Il a été repris par IBM dans son AUA (Ar- chitecture Unifiée d’Applications) version française de son SAA (Systems Architecture Applications). Du point de vue fonctionnel, il est bien plus riche que SNMP mais plus difficile à mettre en œuvre. Il n’est pas très utilisé. 2.3.7 Gestion du réseau de Tunisie Telecom Pour Tunisie Telecom, l’infrastructure de gestion de réseau est du type In-band, c’est-à-dire que les informations de gestion du réseau passent par les mêmes chemins que les données que le réseau doit transporter (les données utiles) ce qui est l’opposé de la gestion Out-of-band. Pour différencier les données du trafic et les données de gestion on utilise les vp/vcc différents. Figure 2.12 – Gestion In-band sur le réseau ATM Conclusion Au terme de ce chapitre, nous avons eu une vue global du Backbone ATM de Tunisie Telecom. Dans un premier temps nous avons décrit le Backbone ATM de Tunisie Telecom, ensuite nous nous sommes penché sur le Réseau ATM Nortel. Nous avons également décrit le réseau d’accès au Backbone ATM, et nous avons présenté les équipements constitutifs du Backbone ATM Nortel de Tunisie Telecom et enfin sa gestion. Par souci de confidentialité, nous ne pouvons pas dévoiler certaines informations.
  • 29. Chapitre 3 Conception Introduction La programmation orientée objet est une technique qui est à la base de tous les nouveaux projets de développement logiciels. La mise en œuvre de logiciels réseau n’échappe pas à cette tendance. Comme tous les autres projets logiciels, les logiciels réseaux (y compris les applications web) peuvent profiter des avantages de l’orientée objet. Cette technique permet la construction d’un programme solide, bien structuré, facile à visualiser et qui est facile à modifier et à maintenir. Le recours à la modélisation est depuis longtemps une pratique indispensable au développement logiciel, car un modèle est prévu pour arriver à anticiper les résultats du codage. Un modèle est en effet une représentation abstraite d’un système à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre les différents intervenants au sein d’un projet. Le modèle sert donc des objectifs différents suivant l’activité de développement et sera construit avec des points de vue plus détaillés : dans les activités de spécification des exigences, les activités d’analyse et les activités de conception. Depuis quelques années, la modélisation objet avec le langage UML (Unified Modeling Language) est devenue incontournable sur la plupart des projets informatiques. UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. Dans ce projet, nous avons utilisé le processus unifié pour la modélisation de notre application web. Le Processus Unifié (UP, pour Unified Process) est un processus de développement logiciel «itératif et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » : – Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui aident à mieux suivre l’avancement global. À la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale. – Centré sur l’architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte. – Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre des itérations. – Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits avec précision et priorisés. [3] Dans la suite de ce chapitre, nous détaillerons dans un premier temps les exigences fonctionnelles de l’application NMS ATM Nortel, nous ajouterons ensuite les exigences non-fonctionnelles. Nous définirons 18
  • 30. CHAPITRE 3. CONCEPTION 19 également les utilisateurs du futur système, les différents diagrammes UML à savoir : Diagramme des cas d’utilisations, diagramme de séquences, diagramme de classes et diagramme d’états transition. 3.1 La spécification des besoins Lors de la création d’un logiciel la tâche de spécification est la toute première à accomplir. Elle consiste pour l’ingénieur à questionner le client sur ses besoins afin d’analyser et de détailler ses besoins. En d’autres termes la spécification établit ce que le système doit faire (le QUOI) et les contraintes sous lesquelles il doit opérer. Cela implique une communication permanente entre le concepteur et le client. L’analyse et l’explicitation des besoins est une phase primordiale dans la conception de tout système. De plus, à ce stade d’analyse, il est impératif de bien comprendre les besoins des clients, car chaque petite lacune ou malentendu peut aboutir en cascade à une application non-utilisable. 3.1.1 Les exigences fonctionnelles L’application Web NMS ATM Nortel devra regrouper les fonctionnalités nécessaires de gestion des liaisons, de supervisions, et de maintenances du réseau d’accès DATA, en gros on définit les services du système. La définition des exigences fonctionnelles doit répondre à la question le QUOI du système. L’administration via l’interface web porte sur les services suivants cités et décris ci-dessous. La création de liaisons Frame Relay Port et Circuit : Elle consiste à créer une nouvelle liaison Frame Relay physique pour un abonné sur la quelle reposerait des circuits virtuels permanent entre deux Com- mutateurs A et B. Pour cette tâche de création, l’utilisateur fourni le DNA (Data Network Address), RDNA (Remote Data Network Address), le débit port et le débit du circuit initial (qui devra être in- férieur ou égal au débit physique). Les DNA sont fournies par les centres régionaux et sont uniques. A travers chaque DNA, on connaitra le commutateur concerné, la carte, la ligne E1 et le canal sur lequel l’abonné a été affecté. Chaque canal est subdivisé en 32 intervalles de temps appelés Time Slots délivrant chacun un débit physique de 64 Kbits/s. Pour un abonné qui a besoin d’un débit de 128 Kbits/s, on lui attribuera alors 2 Time Slot et ainsi de suite. Le FRUNI (Frame Relay User Network Interface) qui est constitué du LP, E1 et Canal sera automatiquement déduit du DNA et du RDNA. Pour les DLCI (Data Link Connection Identifier) et RDLCI (Remote Data Link Connection Identifier), ça sera à la charge de l’application de savoir exactement quelles valeurs utilisées en fonction de celles qui sont déjà allouées, ces valeurs étant unique qu’au niveau local et sont compris entre 16 et 1023. La création de nouveaux circuits : Consiste à la création d’un nouveau circuit virtuel sur une liaison Frame Relay existante. Cette création devra précéder la tâche de création Port et circuit. Les données fournies par l’utilisateur sont le DNA, le RDNA et le débit circuit. La procédure est presque identique dans le cas précédant. La création de liaisons spécialisées émulée sur ATM : Cette tâche consiste à créer une composante couche 2 Aal1Ces (ATM Adaptation Layer 1 Circuit Emulation Service) entre deux commutateurs A et B. Pour ce faire, l’utilisateur devra fournir les informations sur les ressources physiques allouées à l’abonné, il s’agit du numéro de la carte Lp (Logical Processor), la ligne E1, et le canal. Modification du débit circuit d’une liaison Frame Relay : Dans ce cas de figure, l’utilisateur donne les DNA et le RDNA, les DLCI et RDLCI et le nouveau débit circuit, l’application vérifie sur le commutateur que les informations fournies sont exactes et procède à la modification. Modification du débit port d’une liaison Frame Relay : L’utilisateur fourni le DNA, les nouveaux Times Slots, par la suite l’application procède à la modification. Résiliation d’un circuit : Pour la résiliation d’un circuit, la procédure de vérification est la même que pour la modification. Une fois la vérification terminée, le circuit sera alors résilié.
  • 31. CHAPITRE 3. CONCEPTION 20 Résiliation d’une liaison Frame Relay : Après la vérification des informations fournies par l’utilisateur, la liaison sera simplement résilié (Toutes les ressources allouées à l’abonné, time slots, circuits etc. . . seront libérées). Etat de lien des circuits virtuels permanents et du lien physique d’un abonné (LMI). La liste des Multiplexeur reliés à un LP (carte du Commutateur comportant plusieurs liens E1 de 2 Mbits/s). La Liste des abonnés présents sur un LP/x et sur un lien physique E1/y. L’état de lien des Liaisons spécialisées émulées (Aal1Ces /*), ou d’une seule liaison (plus détaillé). Gestion des Multiplexeurs : Consiste à ajouter un nouveau multiplexeur à un commutateur en lui affectant une jonction 2 Mbits/s. Les informations qui devront être fourni par l’utilisateur sont l’adresse IP du multiplexeur et les intervalles de temps de gestion. La sauvegarde des fichiers de configuration de façon automatique suivant une chronologie bien déter- minée (ex : chaque jour à minuit). Supervision du trafic : Visualisation de l’intensité du trafic (Emission/Réception) sur une liaison STM- x (Synchronous Transfert Mode) par une courbe évoluant en fonction du temps pour des fins statistiques (connaitre le trafic max aux heures de pointes pour entreprendre les actions nécessaires qui permettront de résoudre cela). Les tâches de maintenance telles que le Test de boucle local jusqu’à l’abonné, La gestion de l’espace disque des commutateurs, la gestion des alarmes générées sur chaque commutateur. 3.1.2 Exigences non fonctionnelles Les exigences non fonctionnelles permettent de définir des critères qui n’ont aucun impact sur le fonctionnement de notre application. Par exemple les exigences de qualité, les exigences de sécurité, d’ergonomie etc. De ce fait, NMS ATM Nortel devra être sécurisée par mot de passe, son accès devra se faire par une connexion chiffrée en utilisant des certificats (https/SSL). Son interface devra être simple et convivial, elle doit être évolutive. Pour un souci de performance, l’application ne devra pas être très consommatrice de ressource mémoire, ne doit pas générer des trafics supplémentaires pour ne pas gêner le trafic utile. 3.1.3 Gestion des exigences La gestion des exigences est l’ensemble des activités permettant de définir et de suivre les exigences d’un système au cours d’un projet. Elle permet de : – s’assurer de la cohérence entre ce que fait réellement le projet et ce qu’il doit faire ; – faciliter l’analyse d’impact en cas de changement. Les principaux outils de gestion des exigences sont : DOORS (IBM – Telelogic), RequisitePro (IBM - Rational), et CaliberRM(Borland), Enterprise Architect (Sparx Systems). Nous allons profiter d’une capacité particulière de l’outil EA (Enterprise Architect), à savoir la pos- sibilité de décrire les exigences comme des éléments de modélisation à part entière.
  • 32. CHAPITRE 3. CONCEPTION 21 Figure 3.1 – Création des exigences dans Enterprise Architect 3.1.4 Identification des utilisateurs du système L’identification des utilisateurs du système et leurs rôles respectifs, est une étape très importante dans les spécifications d’un système. Il permet de définir le QUI FAIT QUOI ? Pour NMS ATM Nortel, après l’identification des utilisateurs, nous avons pu établir les usagers cités et décrit ci-dessous. – Administrateur : Il aura tous les droits sur l’application. – Opérateur : Il aura le droit de faire les taches de routine comme la création, la modification et etc. – Superviseur : il aura seulement le droit de faire la supervision des équipements mais ne pourra entreprendre aucune action. 3.2 Spécification des exigences d’après les cas d’utilisation Acteurs et cas d’utilisation sont les concepts UML fondamentaux pour la spécification des exigences. L’expression préliminaire des besoins donne lieu à une modélisation par les cas d’utilisation et à une maquette d’interface homme-machine (IHM). Dans cette partie, nous allons détailler la modélisation des cas d’utilisation. La réalisation d’une maquette graphique est une activité courante mettant en jeu des outils de dessin. Elle montre rapidement l’aspect visuel (le « look ») de l’application. Un cas d’utilisation décrit une séquence d’action entre l’acteur et le système. Les différentes étapes de la démarche que nous allons adopter afin d’aboutir au modèle de cas d’utilisation sont les suivantes : – Identifier les acteurs, – Identifier les cas d’utilisation, – Structurer les cas d’utilisation en packages, – Ajouter les relations entre cas d’utilisation, – Finaliser un ou plusieurs diagramme(s) de cas d’utilisation par package.
  • 33. CHAPITRE 3. CONCEPTION 22 Figure 3.2 – Synoptique de la démarche de construction du modèle des cas d’utilisation, [Roques :2008}] 3.2.1 Identification des acteurs Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données. Les acteurs humains pour NMS ATM Nortel sont les suivants : – Administrateur : Il aura tous les droits sur l’application. – Opérateur : Il aura le droit de faire les taches de routine comme la création, la modification et etc. – Superviseur : il aura seulement le droit de faire la supervision des équipements mais ne pourra entreprendre aucune action. Nous allons également prendre en compte les commutateurs, qui l’application devra gérer. L’ensemble des acteurs est représenté graphiquement sur la figure 3.3 autour d’un rectangle figurant le système à l’étude. La représentation graphique standard de l’acteur en UML est l’icône appelée stick man, avec le nom de l’acteur sous le dessin. On peut également figurer un acteur sous la forme rectangulaire d’une classe, avec le mot-clé <‌<actor>‌>. Une bonne recommandation consiste à faire prévaloir l’utili- sation de la forme graphique du stick man pour les acteurs humains et une représentation rectangulaire pour les systèmes connectés.
  • 34. CHAPITRE 3. CONCEPTION 23 Figure 3.3 – Acteurs du NMS ATM Nortel 3.2.2 Identification des cas d’utilisation Un cas d’utilisation représente l’ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Dans la phase de spécifications des exigences fonctionnelles, le modèle des cas d’utilisation considère le système comme une boite noire et décrit les interactions entre le ou les acteurs et le système sous forme textuel, qui consistent aux commandes de l’utilisateur et les réponses du système. Pour chaque acteur identifié précédemment, il convient de rechercher les différentes intentions « métier » selon lequel il utilise le système. Ces cas d’utilisation principaux ont été bien mis en évidence par l’expression des besoins préliminaires du chapitre précédent, à savoir : – Créer une liaison Frame Relay Port et Circuit, – Créer une liaison Frame Relay Circuit, – Créer une liaison spécialisée émulée sur ATM, – Modifier le débit d’un port, – Modifier le débit d’un circuit, – Résilier un port, – Résilier un circuit, – Afficher une LS Aal1Ces, – Afficher les PVC/Lien Physique, – Afficher liaison E1/E3/etc., – Examiner Boucle locale, – Gérer les Alarmes, – Gérer les MUX, – Gérer les espaces disques, – Sauvegarder les fichiers de configuration, – Lister les MUX, – Lister les abonnés, – Lister les E3, – Superviser le trafic.
  • 35. CHAPITRE 3. CONCEPTION 24 Pour améliorer notre modèle, nous allons organiser les cas d’utilisation et les regrouper en ensembles fonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’UML, le package. Le package est un mécanisme général de regroupement d’élément UML, qui peut être utilisé par exemple pour regrouper des cas d’utilisation, mais aussi des acteurs, des classes, etc. . . Les acteurs ont également été regroupés dans un package séparé sur lequel s’appuient les packages de cas d’utilisation. L’organisation générale du modèle dans un outil de modélisation est représentée sur la figure 3.3. Le sigle UC pour use case est souvent utilisé pour raccourcir le nom des packages. Figure 3.4 – Organisation des cas d’utilisation et des acteurs en packages (avec l’outil Enterprise Archi- tect) On obtient un diagramme (figure 3.5) représentant sur un schéma les cas d’utilisation (ovales) reliés par associations (lignes) à leurs acteurs. Figure 3.5 – Cas d’utilisation création de liaisons
  • 36. CHAPITRE 3. CONCEPTION 25 Il est à noter que chaque cas d’utilisation doit avoir un objectif en soi et pouvoir être réalisé indépen- damment des autres. Il arrive que deux acteurs, ou plus, présentent des similitudes dans leurs relations aux cas d’utilisation. On peut l’exprimer en créant un acteur généralisé, éventuellement abstrait, qui modélise les aspects communs aux différents acteurs concrets. Dans notre cas, User est la généralisation des rôles Administrateur et Opérateur, qui peuvent tous les deux réalisés les différentes tâches de créations. Ils peuvent (Administrateur et Opérateur) également effectuer les modifications ou des résiliations de liaisons (voir figure 3.6). Les commutateurs A et B sont nécessaires à la création de la liaison puisque le lien est créé entre les deux commutateurs. Il faut aussi noter que pour créer un nouveau circuit, le port doit être déjà présent d’où la relation d’inclusion formalisée par le mot-clé « include ». Le cas d’utilisation S’authentifier ne représente pas un objectif à part à entière de l’utilisateur, mais plutôt un objectif de niveau intermédiaire qu’il faut conserver pour plus de sécurité, car n’importe qui ne devra pas être capable d’accéder à l’application sinon cela aurait des conséquences sévères. A tout moment sur demande des clients, l’opérateur peut modifier le débit d’un port ou d’un circuit sur ordre et les tâches de résiliation de port et de circuit reviennent à l’administrateur parce que ces tâches requièrent un niveau d’autorisation plus élevé. Figure 3.6 – Cas d’utilisation modification de liaisons Il faut également tenir compte que la modification du débit d’un port et la résiliation d’un port ne s’effectuent que sur un seul commutateur. Pour modifier le débit d’un circuit, les deux commutateurs sur lesquels le circuit est créé entre jeu ; la modification du débit s’effectue alors sur les deux commutateurs. La résiliation d’un port requiert que tous les circuits qui ont été créés sur ce port aient été résiliés au préalable, dans le cas échéant la résiliation du port n’est pas possible. Tous les acteurs du système peuvent réaliser la supervision. Cela ne demande pas de privilège particu- lier. Les cas d’utilisation pour la supervision sont représentés dans la figure 3.7. En effet, le fait d’afficher les multiplexeurs reliés à un commutateur, ou de lister les abonnés d’une ligne, etc. . . ne demande pas un niveau de privilège élevé, donc tous les acteurs (Superviseur, Opérateur et Administrateur) peuvent réaliser la supervision, d’autant plus que la supervision est une tâche assignée au superviseur. Chaque utilisateur devra tout de même être authentifié avant de pouvoir réaliser quoi que ce soit sur le système.
  • 37. CHAPITRE 3. CONCEPTION 26 Figure 3.7 – Cas d’utilisation supervision L’ajout d’un nouveau multiplexeur, la sauvegarde des fichiers de configuration sont des tâches qui peuvent être exécuté par un opérateur ou administrateur, car pour réaliser ces cas d’utilisation, l’acteur devrait avoir un niveau de privilège un peu plus élevé. Un superviseur peut aussi connaitre l’état des lignes E1, E3, l’état d’une liaison Frame Relay et avertir en cas de problème un opérateur ou un administrateur pour qu’il intervienne et résoud le problème. Toutes ces tâches ne mettent qu’un seul commutateur en jeu d’où la présence de l’acteur secondaire commutateur. Le diagramme de cas d’utilisation de ce package est représenté sur la figure 3.8. Figure 3.8 – Cas d’utilisation exploitation
  • 38. CHAPITRE 3. CONCEPTION 27 Pour les tâches de maintenance, les cas d’utilisation que nous avons pu avoir sont : Le test de boucle jusqu’à l’abonné, la gestion de l’espace disque des commutateurs et la gestion des alarmes générées par les commutateurs. Les acteurs intervenant dans la réalisation de ces tâches sont l’opérateur et l’adminis- trateur. En effet, ces tâches demandent un niveau de privilège élevé. Le diagramme de cas d’utilisation pour les tâches de maintenance est représenté sur la figure 3.9. Figure 3.9 – Cas d’utilisation maintenance Une fois la structuration en package terminée, nous avons obtenu les packages suivants : Gestion des liaisons, Exploitation et Maintenance et Supervision. Figure 3.10 – Organisation complétée des cas d’utilisation et des acteurs
  • 39. CHAPITRE 3. CONCEPTION 28 3.2.3 Traçabilité avec exigences textuelles Lors de la spécification des exigences fonctionnelles, nous avons saisi un certain nombre d’exigences dans Enterprise Architect. Nous allons maintenant établir la relation entre cas d’utilisation que nous venons d’identifier et les exigences textuelles. Cette étude permet à la fois de valider la complétude des cas d’utilisation, mais aussi d’améliorer celle des exigences textuelles. Enterprise Architect permet ainsi de visualiser une matrice de traçabilité telle que représenter sur la figure 3.11. Figure 3.11 – Matrice de traçabilité entre cas d’utilisation et exigences 3.3 Spécification détaillée des exigences Dans cette partie, nous allons décrire de façon détaillée les cas d’utilisation que nous avons identifiés dans la partie précédente. Nous complèterons cette description textuelle par une représentation graphique UML très utile : le diagramme de séquence. Vu le nombre important de cas d’utilisation, on ne va pas décrire chaque cas d’utilisation. Nous allons parler de quelques un, à savoir : – Créer une liaison Frame Relay Port et Circuit – Créer une liaison spécialisée émulée sur ATM – Lister les abonnés – Sauvegarder les fichiers de configuration – Gérer les multiplexeurs – Afficher les circuits virtuels d’un lien physique Frame-Relay – Examiner Boucle Locale – Gérer les espaces disques – Superviser le trafic
  • 40. CHAPITRE 3. CONCEPTION 29 3.3.1 Description textuelle des cas d’utilisation La fiche de description textuelle d’un cas d’utilisation n’est pas normalisée par UML [3]. Nous avons donc adopté celle qui est adaptée à notre problème. Ainsi les descriptions textuelles pour les cas d’utili- sation cités plus haut sont les suivantes : Créer Liaison Frame-Relay Port et Circuit Acteur Principal L’utilisateur (Acteur généraliser d’Administrateur et Operateur) Acteurs Secondaires Les deux commutateurs A et B Objectif L’utilisateur veut créer une nouvelle liaison Frame-Relay Port et Circuit entre le commutateur A et le commutateur B. Précondition L’utilisateur s’est authentifié sur l’application. Post condition La liaison Frame Relay a été correctement créée et est opérationnelle. Scénario nominal 1. L’utilisateur saisit le Nom du client, DNA, RDNA, débit physique, débit circuit. 2. L’utilisateur choisi les intervalles de temps à allouer au client. 3. L’utilisateur valide la création. 4. Le commutateur A exécute les instructions de création de la liaison. 5. Le commutateur B exécute les instructions de création de la liaison. Alternatives 1a- L’utilisateur a fourni des informations erronées. 1. L’utilisateur modifie toutes les informations erronées. 2. L’utilisateur valide la création de la liaison. Exigence Supplémentaire Une fois le processus de création lancé, il ne doit pas être interrompu. Créer une Liaison Spécialisée émulée sur ATM Acteur Principal L’utilisateur (Acteur généraliser d’Administrateur et Operateur) Acteurs Secondaires Les deux commutateurs A et B Objectif L’utilisateur veut créer une nouvelle liaison spécialisée à émulation de circuit entre le commutateur A et le commutateur B. Précondition L’utilisateur s’est authentifié sur l’application Post condition La liaison a été correctement créée et est opérationnelle. Scénario Nominal 1. L’utilisateur choisit les commutateurs A et B.
  • 41. CHAPITRE 3. CONCEPTION 30 2. L’utilisateur saisit le nom de l’abonné, la carte, la ligne et le canal. 3. L’utilisateur choisit les intervalles de temps pour A, et pour B. 4. Il valide la création de la liaison. Alternatives 1a- L’utilisateur a fourni des informations erronées. . L’utilisateur modifie toutes les informations erronées. 2. L’utilisateur valide la création de la liaison. Exigence Supplémentaire Une fois le processus de création lancé, il ne doit pas être interrompu. Lister les abonnés Acteur Principal L’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur) Acteur Secondaire Le Commutateur Objectif L’utilisateur veut avoir la liste des abonnés d’une liaison E1, par la suite il pourra avoir plus de détails sur une liaison tel que le type de la liaison (Frame Relay/Aal1Ces), les ITs accordés à un abonné et etc. Précondition L’utilisateur s’est authentifié sur l’application. Post Condition Une liste d’abonné s’affiche à l’utilisateur. Scenario nominal 1. L’utilisateur sélectionne le commutateur. 2. L’utilisateur choisi la carte. 3. L’utilisateur sélectionne la ligne. 4. La liste des abonnés sur cette ligne s’affiche. Afficher les circuits virtuels d’un lien physique Frame-Relay Acteur Principal L’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur) Acteur Secondaire Le Commutateur Objectif L’utilisateur veut avoir l’état d’une liaison Frame-Relay (LMI) et la liste des circuits virtuels permanents (PVC) et leurs états respectifs. Précondition L’utilisateur s’est authentifié sur l’application. Post Condition L’état de la liaison s’affiche (Fonctionnement normal, Arrêté, En cours de synchronisation). Scenario nominal 1. L’utilisateur sélectionne le commutateur. 2. L’utilisateur entre l’identifiant FRUNI (Frame-Relay User Network Interface). 3. L’état de la liaison, les circuits virtuels avec leurs états respectifs s’affiche.
  • 42. CHAPITRE 3. CONCEPTION 31 Gérer les multiplexeurs Acteur Principal L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur) Acteur Secondaire Le commutateur Objectif L’utilisateur veut ajouter un nouveau multiplexeur en affectant une jonction 2 Mbits/s au commutateur. Précondition L’utilisateur s’est authentifié sur l’application Post Condition La jonction s’est correctement effectuée et le commutateur voit le Multiplexeur ajouté. Scénario Nominal 1. L’utilisateur sélectionne le commutateur. 2. Il choisit la carte et la ligne. 3. Il affecte un canal et des intervalles de temps pour la gestion. 4. L’utilisateur saisi l’adresse IP du multiplexeur à ajouter. 5. Il valide l’affectation de la jonction. Backup des configurations Acteur Principal L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur). Acteur Secondaire Le commutateur. Objectif L’utilisateur veut sauvegarder le dernier fichier de configuration d’un commutateur. Précondition L’utilisateur s’est authentifié sur l’application. Post Condition Le fichier de configuration a été correctement sauvegardé. Scénario Nominal 1. L’utilisateur choisit le commutateur. 2. Il choisit la dernière configuration. 3. Il télécharge le fichier sur le serveur. Gérer les espaces disque Acteur Principal L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur). Acteur Secondaire Le commutateur. Objectif L’objectif de cette tâche est de supprimer les fichiers inutiles pour libérer de l’espace disque sur le com- mutateur. Précondition L’utilisateur s’est authentifié sur l’application.
  • 43. CHAPITRE 3. CONCEPTION 32 Post Condition Une quantité considérable d’espace disque a été libérée sur le commutateur. Scénario Nominal 1. L’utilisateur choisit le commutateur. 2. Il affiche la quantité d’espace disque occupée. 3. Il choisit les fichiers qu’il considère inutiles (les anciens fichiers). 4. Il efface ces fichiers un par un. 5. L’application informe l’utilisateur l’opération du succès de l’opération. Examiner la boucle locale Acteur Principal L’utilisateur (Acteur généraliser de l’Administrateur et Opérateur). Acteur Secondaire Le commutateur. Objectif Dans le but de la recherche d’éventuel problème de liaison, l’utilisateur veut tester la boucle local jusqu’à l’abonné, pour par la suite voir où se situe le problème de la liaison. Précondition L’utilisateur s’est authentifié sur l’application. Post Condition Plusieurs résultats possibles. La liaison fonctionne correctement, la liaison ne fonctionne pas correctement. Scénario Nominal 1. L’utilisateur choisit le commutateur. 2. Il choisit la carte, la ligne, et le canal. 3. Il fait une boucle coté multiplexeur et regarde les resultats retournés par le multiplexeur. 4. En fonction de ces résultats, il prend les décisions conséquentes qui s’imposent. Superviser le trafic Acteur Principal L’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur). Acteur Secondaire Le commutateur. Objectif L’utilisateur souhaite visualiser l’intensité du trafic d’une liaison inter-sites. Précondition L’utilisateur s’est authentifié sur l’application. Post Condition Un graphe représentant l’intensité du trafic évoluant en fonction du temps s’affiche. Scénario Nominal 1. L’utilisateur choisit le commutateur. 2. Il choisit une jonction inter-sites. 3. Un graphe représentant l’intensité du trafic en fonction du temps s’affiche.
  • 44. CHAPITRE 3. CONCEPTION 33 3.3.2 Diagramme de séquence système Les cas d’utilisation décrivent les interactions entre les acteurs avec l’application web que nous voulons spécifier et concevoir. Lors de ces interactions, les acteurs produisent des messages qui affectent le système informatique et appellent généralement une réponse de celui-ci. Nous allons isoler ces messages et les représenter graphiquement sur des diagrammes de séquence UML. Pour les messages, les DSS (diagrammes de séquence système) montrent non seulement les acteurs externes qui interagissent directement avec le système mais également ce système (en tant que boite noire) et les évènements déclenchés par les acteurs. L’ordre chronologique se déroule vers le bas et l’ordre des messages doit suivre la séquence décrite dans les cas d’utilisation. Nous allons représenter le DSS d’un scénario représentatif de chacun des cas d’utilisation décrit pré- cédemment. Créer Liaison Frame-Relay Port et Circuit Il faut repartir de la description textuelle détaillée du cas d’utilisation et transformer chaque étape en une flèche représentant un message. L’acteur principal (L’utilisateur) est représenté à gauche du diagramme et le système NMS ATM Nortel entre l’utilisateur et les commutateurs qui sont les acteurs secondaires. Le mot-clé « system » est utilisé dans le système boite noire pour le différencier plus nettement des acteurs. (Figure 3.12) Figure 3.12 – Diagramme de séquence système Créer une liaison Frame Relay port et circuit
  • 45. CHAPITRE 3. CONCEPTION 34 Créer une liaison spécialisée émulée sur ATM Figure 3.13 – Diagramme de séquence système Créer une liaison spécialisée émulée sur ATM Lister les abonnés Figure 3.14 – Diagramme de séquence système Lister les abonnés
  • 46. CHAPITRE 3. CONCEPTION 35 Afficher les circuits virtuels d’un lien physique Frame-Relay Figure 3.15 – Diagramme de séquence système Afficher les circuits virtuels d’un lien Physique Frame Relay Gérer les multiplexeurs Figure 3.16 – Diagramme de séquence système Gérer les multiplexeurs
  • 47. CHAPITRE 3. CONCEPTION 36 Backup des configurations Figure 3.17 – Diagramme de séquence système Backup des configurations Gérer les espaces disque Figure 3.18 – Diagramme de séquence système Gérer les espaces disque
  • 48. CHAPITRE 3. CONCEPTION 37 Examiner la boucle locale Figure 3.19 – Diagramme de séquence système Examen de la boucle locale Superviser le trafic Figure 3.20 – Diagramme de séquence supervision du trafic
  • 49. CHAPITRE 3. CONCEPTION 38 3.4 Diagramme des classes Le diagramme des classes constitue l’un des pivots essentiels de la modélisation avec UML. En effet, ce diagramme exprime de manière générale la structure statique d’un système, en termes de classes et de relations entre ces classes [1]. De même qu’une classe décrit un ensemble d’objets, une association décrit un ensemble de liens ; les objets sont instances des classes et les liens sont instances des relations. Un diagramme des classes décrit de manière abstraite les liens potentiels d’un objet vers d’autres objets. Une classe se représente à l’aide d’un rectangle comportant plusieurs compartiments. Les trois com- partiments de base sont : – la désignation de la classe, – la description des attributs, – la description des opérations. Un attribut est une propriété élémentaire d’une classe. Pour chaque objet d’une classe, l’attribut prend une valeur. Par exemple un commutateur a comme attributs sont identifiant unique, son adresse IP, son nom. . . Une opération est une fonction applicable aux objets d’une classe. Une opération permet de décrire le comportement d’un objet. Un exemple d’opération sur la classe Commutateur est qu’on ajouter un commutateur. Une méthode est l’implémentation d’une opération. Figure 3.21 – Diagramme des classes Dans notre cas, un commutateur est relié à un ou plusieurs multiplexeurs, et un multiplexeur n’est relié qu’à un et un seul commutateur.
  • 50. CHAPITRE 3. CONCEPTION 39 Un commutateur contient plusieurs cartes, d’où la relation d’agrégation entre commutateur et carte. Une agrégation est un cas particulier d’association non symétrique exprimant une relation de conte- nance. Le commutateur contient également plusieurs configurations. Une carte est composée de plusieurs interfaces. Un abonné a la possibilité d’avoir plusieurs liaisons Frame Relay ainsi qu’ATM, et ces liaisons ne peuvent appartenir qu’à un seul Abonné. Chaque liaison Frame Relay et Aal1Ces est composé de circuit virtuel caractérisé par entre autre le débit, les différents identifiants de bout en bout (DLCI, RDLCI, Aal1Ces Number . . . ). La notation « Ordered » sur la relation de composition qui lie une liaison Frame Relay et un circuit Frame Relay indique que les circuits créés sur un lien FR sont typiquement ordonné par ordre de création, ceci permet de bien suivre l’ordre d’incrémentation du DLCI qui varie de 16 à 1023 par ordre croissant et un pas d’incrémentation de 1. Un exemple de création est que si on crée une liaison FR, le premier circuit de ce lien aura comme DLCI 16, le circuit suivant qui sera créé sur ce lien aura comme DLCI 17 et ainsi de suite. 3.5 Diagramme d’états UML a bien repris le concept de machine à état fini FSM (Finite State Machine) en anglais, qui consiste à s’intéresser au cycle de vie d’un objet générique d’une classe particulière au fil de ses interactions, dans tous les cas possibles [3]. Cette vue locale d’un objet, qui décrit comment il réagit à des événements en fonction de son état courant et comment il passe dans un nouvel état, est représentée graphiquement sous la forme d’un diagramme d’états. Les diagrammmes d’états sont utilisés pour modéliser l’aspect dynamique d’un système. Le diagramme d’états est une représentation graphique d’une machine à états fini dans laquelle les noeuds représentent les états et les arcs représentent les transitions [1]. Un état représente une situation durant la vie d’un objet pendant laquelle : il satisfait une certaine condition, il exécute une certaine activité, ou bien il attend un certain événement. Un objet passe par une succession d’états durant son existence. Un état a une durée finie, variable selon la vie de l’objet, en particulier en fonction des événements qui lui arrivent. Une transition décrit la réaction d’un objet lorsqu’un évènement se produit (généralement l’objet change d’état, mais pas forcément). En règle générale, une transition possède un événement déclencheur, une condition de garde, un effet et un état cible. En plus de la succession d’états « normaux » correspondant au cycle de vie d’un objet, le diagramme d’états comprend également deux pseudo-états : – L’état initial du diagramme d’état correspond à la création de l’instance – L’état final du diagramme d’état correspond à la destruction de l’instance. Dans notre cas, nous n’allons pas représenter une machine à état pour toutes nos classes. Nous représen- terons celles qui ont un comportement dynamique complexe nécessitant une description plus poussé. Dans la figure 3.22, nous avons représenté les états et transition lors de la vie normale de la création d’une liaison FR port et circuit. La validation des informations de création de la liaison peut se heurter à des erreurs de saisies. Chaque commutateur effectue les traitements à son niveau. Une fois que la création est terminée sur le premier commutateur, la transition « lancement de la création » est franchie pour lancer la création sur le second commutateur ; une fois toutes les instructions exécutées, un résumé de la création s’affiche dans la quelle apparait l’état de la nouvelle liaison.
  • 51. CHAPITRE 3. CONCEPTION 40 Figure 3.22 – Diagramme d’état Création liaison FR port et circuit Figure 3.23 – Diagramme d’état Supervision du trafic
  • 52. CHAPITRE 3. CONCEPTION 41 Figure 3.24 – Diagramme d’état : Gérer l’espace disque 3.6 Base de données La base de données qui devra gérer les données de l’application (historique du trafic, des alarmes et etc. . . ) est constituée des tables suivantes : – Commutateurs : Cette table stockera les informations relatives à chaque commutateur qui sera gérer par l’application à savoir son identifiant, nom et adresse IP ; – Cartes : Cette table devra enregistrer les informations de toutes les cartes de tous les commutateurs – Interfaces : Comme son nom l’indique, cette table devra recevoir les informations sur chaque inter- face de toutes les cartes de tous les commutateurs, ceci permettra de suivre facilement les données entrant et sortant sur chaque et interface et par la suite de pouvoir faire des analyses par des gra- phiques évoluant en fonction du temps, de pouvoir suivre les alarmes générés au niveau de chaque commutateur ; – Infotrafic : cette table recevra les données sur le trafic provenant de chaque interface de tous les commutateurs recensées par le service en charge de récolter les données de trafic périodiquement ; – Infoalarm : cette table recevra les données d’alarmes récoltées par le service de surveillance des alarmes ;
  • 53. CHAPITRE 3. CONCEPTION 42 Le modèle conceptuel de données est le suivant : Figure 3.25 – Schéma Conceptuel de la base de données Conclusion Nous venons, au terme de ce chapitre, de présenter le langage utilisé pour faire la conception de notre application qui est le langage UML. Ensuite, nous avons dégagé à partir des besoins utilisateurs les diffé- rents diagrammes UML, et la base de données qui sera utilisée pour stockage des données, qui par la suite nous permettrons de codé proprement notre application. Le chapitre suivant sera sur l’implémentation de l’application NMS ATM Nortel et l’observation des premiers résultats.