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

REPUBLIQUE TUNISIENNE

Ministère de l’Enseignement Supérieur, de la Recherche scientifique et de laTechnologie

Université Privée Montplaisir Tunis

Agrément N° 01-2001

PROJET DE FIN D’ETUDEPOUR 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 TunisSite web : http ://www.fmci.ens.tn - Email : [email protected]

UMT Quartier Montplaisir Rue Aboubaker El Bokri 1073 Tunis TunisieTel : (216) 71 901 660 / Fax : (216) 71 904 425

Au Nom d’ALLAH, Le Tout Miséricordieux, Le TrèsMisé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 Hasnaouipour m’avoir fait le grand honneur de diriger mon projet dans les meilleures conditions, ainsi que pourleurs encadrements, leurs conseils et leurs disponibilités.

Je témoigner ma reconnaissance à Monsieur Slaheddine Jarboui pour son aide pour l’obtention dece stage à Tunisie Telecom. Je remercie également Mr Imed Toumi, Mr Houssem Jarraya, Mr AbdallahAbaza, Mr Maher Ben Hassine, Mr Saber Ben Gharbia, Mr Soufiane Mathloulhi, et à Mr Saif EddineAbidi 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 ontfait 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 Nortelde Tunisie Telecom. Le premier point concerne le problème du travail en ligne de commandes. Le deuxièmepoint 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 points’attache à la gestion des alarmes et à la gestion de la congestion des liaisons inter-sites, pour ce faire nousavons développé un processus pour le recueil des alarmes générées par les commutateurs et l’avertissementdes 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.

AbstractDuring 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 pointconcerns the archiving of configurations of different switches. To remedy this problem, we set up a backupprocess 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 switchesand warning operators of these incidents, and setting up a service for monitoring inter-site traffic whichavoids 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 2Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Backbone ATM de Tunisie Telecom 5Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Les équipements d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Les équipements du Cœur du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 La gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 But et domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2.1 L’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2.2 La supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.2.3 La maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3 Principes de la gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.5 Le Protocole Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.6 Autres protocoles de gestion de réseau . . . . . . . . . . . . . . . . . . . . . . . . 172.3.7 Gestion du réseau de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . . 17

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iv

TABLE DES MATIÈRES v

3 Conception 18Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1 La spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Les exigences fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.3 Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.4 Identification des utilisateurs du système . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Spécification des exigences d’après les cas d’utilisation . . . . . . . . . . . . . . . . . . . . 213.2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Identification des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.3 Traçabilité avec exigences textuelles . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Spécification détaillée des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1 Description textuelle des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Diagramme de séquence système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5 Diagramme d’états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.6 Base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Implémentation 43Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1 Technologie de développement web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.1 Le service TraficInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.2 Le service AlarmeManage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.3 Le service BackupAuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.4 NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Conclusion Générale 58

A L’ATM 59Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.1 L’adressage dans le réseau ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.2 La couche Physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.3 La qualité de service QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62A.4 La signalisation et le routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

B Frame Relay 64Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64B.1 Circuits virtuels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64B.2 Le contrôle d’admission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Bibliographie 68

Liste des acronymes

AAL ATM Adaptation LayerAal1Ces ATM Adaptation Layer 1 Circuit Emulation ServiceABR Available Bit RateADSL Asymetric Digital Subscriber LineAJAX Asynchronous Javascript And XMLAPI Application Programming InterfaceASN Abstract Syntax NotationASP.NET Active Server Page .NETATD Asynchronous Time DivisionATM Asynchronous Transfert Mode

BC Burst Committed SizeBE Burst Excess SizeBECN Backward Explicit Congestion NotificationB-ISDN Broadband - Integrated Service Digital Network

CBR Constant Bit RateCCS Common Channel SignalingCIR Commited Information RateCLLM Consolided Link Layer ManagementCLR Common Language RuntimeCMIP Common Management information ProtocolCMIS Common Management information ServiceCNET Centre Nationale Etude et de Télécommunication

DCE Data Communication EquipmentDLCI Data Link Connection IdentifierDNA Data Network AddressDS0 Digital Signal 0DSLAM Digital Subscriber Line Access MultiplexerDTE Data Terminal Equipment

E1 E-Carrier 1EIR Excess Information RateETTD Equipement Terminal de Traitement de Données

FECN Forward Explicit Congestion Notification

vi

TABLE DES MATIÈRES vii

FR Frame RelayFRAD Frame Relay Access DeviceFRUNI Frame Relay User Network InterfaceFSI Fournisseur de Services InternetFSM Finite State MachineFTP File Transfert ProtocolFTPS File Transfert Protocol Secure

HTML Hyper Text Markup LanguageHTTPS Hyper Text Transfert Protocol Secure

IDE Integrated Development EnvironmentIETF International Engineering Task ForceIISP Interim Inter Switching ProtocolIP Internetworking Protocol

LAN Local Area NetworkLMI Local Management InterfaceLP Logical ProcessorLS Liaison Spécialisée

MIB Management Information BaseMPLS Multi-Protocol Label SwitchingMSA32 Multi Service Access 32

NMS Network Management SystemNNI Node Network Interface

OC-X Optical Carrier – XOID Object IDentifierOSI Open Systems Interconnexion

PNNI Private Network to Network InterfacePOP Point Of PresencePVC Permanent Virtual Circuit

QoS Quality of Service

RDLCI Remote Data Link Connection IdentifierRDNA Remote Data Network AddressRFC Request For CommentRNIS Réseau Numérique à Intégration de Service

SDH Synchronous Digital HierarchySDSL Symetric Digital Subscriber LineSMI Structure of Managed InformationSMTP Simple Mail Transfert ProtocolSNMP Simple Network Management Protocol

TABLE DES MATIÈRES viii

SOAP Simple Object Access ProtocolSONET Synchronous Optical NetworkSS7 Signaling System 7SSH Secure ShellSSL Secure Sockets LayerSTM-1 Synchronous Transfert Mode 1SVC Switched Virtual Circuit

TCP Transmit Control ProtocolTDM Time Division MultiplexingTLS Transport Layer Security

UBR Unspecified Bite RateUDP User Datagram ProtocolUIT Union International des TélécommunicationsUML Unified Modeling LanguageUNI User Network InterfaceUP Unified Process

VBR-NRT Variable Bit Rate - Non Real TimeVBR-RT Variable Bit Rate - Real TimeVCC Virtual Circuit ConnectionVCI Virtual Circuit IdentifierVES Virtual Execution SystemVP Virtual PathVPI Virtual Path IdentifierVSS Variable Speed Switch

XML eXtensible Markup Language

Table des figures

2.1 Exemple de Liaison Frame Relay sur ATM . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Exemple de Liaison Spécialisée à émulation de circuit sur ATM . . . . . . . . . . . . . . . 62.3 Réseau maillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Réseaux d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Nortel Passport 7480 El Kasbah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Nortel Passport 15000-VSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7 Réseau ATM Nortel de Tunisie Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.8 Relations entre manager, agents et protocole . . . . . . . . . . . . . . . . . . . . . . . . . 132.9 Architecture SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.10 Structure d’indexation des données dans la MIB-2 SNMP . . . . . . . . . . . . . . . . . . 152.11 Exemple de session Telnet sur un commutateur Nortel 7480 . . . . . . . . . . . . . . . . . 162.12 Gestion In-band sur le réseau ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Création des exigences dans Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . 213.2 Synoptique de la démarche de construction du modèle des cas d’utilisation, [Roques :2008}] 223.3 Acteurs du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Organisation des cas d’utilisation et des acteurs en packages (avec l’outil Enterprise Ar-

chitect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Cas d’utilisation création de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6 Cas d’utilisation modification de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.7 Cas d’utilisation supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.8 Cas d’utilisation exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.9 Cas d’utilisation maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.10 Organisation complétée des cas d’utilisation et des acteurs . . . . . . . . . . . . . . . . . . 273.11 Matrice de traçabilité entre cas d’utilisation et exigences . . . . . . . . . . . . . . . . . . . 283.12 Diagramme de séquence système Créer une liaison Frame Relay port et circuit . . . . . . 333.13 Diagramme de séquence système Créer une liaison spécialisée émulée sur ATM . . . . . . 343.14 Diagramme de séquence système Lister les abonnés . . . . . . . . . . . . . . . . . . . . . . 343.15 Diagramme de séquence système Afficher les circuits virtuels d’un lien Physique Frame Relay 353.16 Diagramme de séquence système Gérer les multiplexeurs . . . . . . . . . . . . . . . . . . 353.17 Diagramme de séquence système Backup des configurations . . . . . . . . . . . . . . . . . 363.18 Diagramme de séquence système Gérer les espaces disque . . . . . . . . . . . . . . . . . . 363.19 Diagramme de séquence système Examen de la boucle locale . . . . . . . . . . . . . . . . 373.20 Diagramme de séquence supervision du trafic . . . . . . . . . . . . . . . . . . . . . . . . . 373.21 Diagramme des classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.22 Diagramme d’état Création liaison FR port et circuit . . . . . . . . . . . . . . . . . . . . . 403.23 Diagramme d’état Supervision du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

ix

TABLE DES FIGURES x

3.24 Diagramme d’état : Gérer l’espace disque . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.25 Schéma Conceptuel de la base de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Ensemble Framework .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2 IDE Microsoft Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Architecture du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4 Schéma de fonctionnement du service TraficInfo . . . . . . . . . . . . . . . . . . . . . . . . 464.5 Fonctionnement du service AlarmeManage . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6 Fonctionnement du service BackupAuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.7 Page de configuration de la sauvegarde automatique . . . . . . . . . . . . . . . . . . . . . 484.8 Page de connexion au NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.9 Page d’accueil du NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.10 Listing des cartes d’un commutateur Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . 504.11 Les lignes de la carte 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.12 Les détails d’une ligne E1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.13 Page de création d’une nouvelle liaison Frame Relay . . . . . . . . . . . . . . . . . . . . . 514.14 Page de résumé Création Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.15 Création d’une LS à émulation de circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.16 Résumé de Création d’une LS à émulation de circuit . . . . . . . . . . . . . . . . . . . . . 524.17 Liste des abonnés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.18 Informations détaillées sur une liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.19 Test d’une liaison Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.20 Graphe d’évolution du trafic en fonction du temps . . . . . . . . . . . . . . . . . . . . . . 544.21 Occupation de l’espace disque d’un commutateur . . . . . . . . . . . . . . . . . . . . . . . 554.22 Sélection des fichiers à supprimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.23 Alarme(s) détectée(s) par NMS ATM Nortel . . . . . . . . . . . . . . . . . . . . . . . . . . 564.24 Liste des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.25 Traitement des alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

A.1 Format d’une cellule ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.2 La double identification d’ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.3 Architecture ATM, [Servin :2003] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.4 La signalisation dans ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.1 Représentation basique Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65B.2 Identification des liens logiques par le DLCI . . . . . . . . . . . . . . . . . . . . . . . . . . 66B.3 Contrôle de gestion dans les réseaux haut débit . . . . . . . . . . . . . . . . . . . . . . . . 67B.4 Contrôle de gestion dans les réseaux haut débit . . . . . . . . . . . . . . . . . . . . . . . . 67B.5 Echange de message synchrone sur l’état des liens . . . . . . . . . . . . . . . . . . . . . . 68

Introduction Générale

Les réseaux de télécommunications touchent de plus en plus notre vie quotidienne. On compte surles 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éveloppementd’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 (NationalOperation Center) et ROCs (Regional Operation Centers) DATA de la direction exécutive des Backbonesde Tunisie Telecom.Le premier chapitre sera réservé à la présentation de Tunisie Telecom, du cadre général du projet, ainsiqu’à 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 ainsique 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 desservices 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 notreorganisme d’accueil à savoir ‘Tunisie Telecom’, par la suite nous décrirons la problématique et les objectifsspé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 » estentrée en activité en tant qu’opérateur de télécommunication doté de sa propre autonomie et son propreré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èrede 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’équipementtechnologique 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 NOCDATA, est le centre national des opérations de gestion, de maintenance, et de supervision des réseaux detransmission de données à l’échelle nationale.

Il a pour tâche :– La gestion des équipements de transmission de données (Commutateurs, Multiplexeurs, DSLAMetc.)

– 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 queFrame 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éliorerla qualité du trafic

– Et etc.

1.2 Problématique

Dans la situation actuelle, le traitement des requêtes de nouvelle connexion Frame Relay, de liaisonspé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 lenombre important de tâches, il est très fastidieux de les effectuer en ligne de commandes, il n’offre pasune vue synthétique de l’infrastructure, les erreurs de configurations sont très fréquentes. La sauvegardemanuelle des fichiers de configuration des commutateurs entraine souvent leurs pertes et parfois l’oubliede la sauvegarde de ces fichiers sont suivi de conséquences désastreuses. Tous ces problèmes causent unemauvaise 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 à desproblè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 performantqui leur permettra de remplir plus amplement les différentes missions qui les ont été confié et de remédieraux nombreux problèmes cités ci-dessus.

L’objectif fondamental de ce projet est de permettre aux utilisateurs de créer des liaisons FrameRelay, de liaisons spécialisée émulée sur ATM, de mieux gérer la congestion, de superviser en temps réelles liaisons inter-sites, la gestion automatique de la sauvegarde des fichiers de configurations etc. . . viaune interface web interactive et attractive. Cette application sera particulièrement utile dans l’exécutiondes 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. Nousavons également défini les objectifs de notre projet. Le prochain chapitre sera consacré au Backbone ATMde 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 segreffer les réseaux des fournisseurs de services internet, des réseaux de grandes entreprises, etc. C’est lapartie qui supporte le gros du trafic, en utilisant les technologies de transmission de données les plusrapides et une grande bande passante sur des distantes importantes. Les liaisons qui forment le Backbonesont constituées majoritairement de câble à fibres optiques. A Tunisie Telecom, ce réseau fédérateur estsubdivisé en deux parties : Le Backbone ATM et le Backbone IP/MPLS. La suite de ce chapitre seraconsacré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 gestionest constitué de près de 20 commutateurs ATM Nortel et de 20 commutateurs ATM Alcatel éparpillé surtout le territoire tunisien. Ces commutateurs sont caractérisés par leur bonne performance, ils assurentune couverture maximale du pays, leur fonction principale est de permettre un transport fluide et efficacedu trafic transitant sur le Backbone.

Les clients ne sont pas directement connectés via les commutateurs principaux, mais à travers desmultiplexeurs d’accès qui sont à leurs tours connectés aux commutateurs d’accès qui permettent d’assurerl’interconnections des différents types d’utilisateurs (LS, FR, ADSL). Les clients sont essentiellement lesbanques, les grandes entreprises, les Fournisseurs de services internet FSI, les agences nationaux ouinternationaux, 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 danslequel 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 chargeentre les différents nœuds. Cela permet d’éviter d’avoir des points sensibles, qui en cas de panne, coupentla 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) encas de congestion. En effet la redondance est une caractéristique essentielle au fonctionnement d’un telréseau.

Le terme redondance est utilisé pour désigner deux serveurs ou deux cartes de contrôles (Contientla configuration du commutateur) dédoublé. Si l’un des serveurs tombe en panne le deuxième prendautomatiquement 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 lesserveurs permettent de bien assurer la surveillance du réseau. Pour les cartes de contrôles, la redondancepermet d’éviter l’arrêt d’une portion du réseau si la première carte tombe en défaillance, la deuxièmeprendra automatiquement la relève. C’est un atout majeur pour un réseau en production car il permetau réseau d’assurer une très grande fiabilité.


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 clientsen entrée et en sortie du réseau. Les multiplexeurs d’accès multiservice rassemblent, brassent les flux enprovenance 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’effectuevia le multiplexeur Master.

Le multiplexeur d’accès (figure 2.4) fait passer le trafic à destination du Backbone IP/MPLS (InternetProtocol/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 passepar une liaison E1/T1 (2 Mbps) jusqu’au commutateur d’accès ATM. Il assure également à travers un lien2 Mbps une liaison international, cette liaison est généralement attribuée aux ambassades, aux centresd’appels et d’autres entreprises étrangères. Une autre liaison 2 Mbps peut être attribuée aux fournisseursde 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 etSagem.

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 TunisieTelecom, faisant eux même parties du Backbone. Ils connectent les réseaux locaux (LAN) des utilisateursfinaux au réseau fédérateur de l’opérateur. Ils permettent également la conversion des trames provenant


des LAN du client en des cellules ATM et vice versa. Ils l’établissement de circuit virtuel dans le réseauATM et envoient le trafic sur le Backbone ATM. Ils agrègent les liens de faible débit à partir des réseauxclients 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œurdu réseau (Backbone) et servant à interconnecter des commutateurs d’accès. Bien que ces commutateurspeuvent être très intelligent, ils ne fonctionnent que dans la couche 2 du modèle de référence OSI (OpenSystems Interconnection). Encore appelés brasseurs, ils assurent la commutation de faisceaux virtuels eninterne 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 multiprotocoles, la gestion intelligente du trafic et supporte simultanément la voix, des données, la vidéo etl’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 tellesque la surveillance du Self et le traitement alarmes. Le CP fournit également l’horloge du bus, le stockagede 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 ledeuxiè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éseauxau commutateur. Ils permettent l’exécution en temps réel des processus qui sont essentiels à la prestationdes 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 êtreutilisée pour transporter de nombreuses communications vocales simultanées au moyen du multiplexagetemporel 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, duCanada et du Japon. Un E1 transporte 32 tranches temporelles (Time Slots) et un E3 en transporte512, dont une tranche servant à délimiter les trames. Chaque tranche de temps transporte un DS0 (64Kbps) soit l’équivalent de 2 Mbps pour E1 et 34 Mbps pour E3. Les circuits E1 sont très utilisés pourconnecter des entreprises de moyenne ou grande taille, des commutateurs distants et la plupart du tempsentre commutateurs. Les lignes E3 sont utilisées entre commutateurs, entre les opérateurs et fournisseursde services internet (ex : Globalnet, Planet).

Basé sur un signal optique multiple de 51,84 Mbps, le standard OC (Optical Carrier) a été défini selonle modèle SONET (Synchronous Optical Network). Il répertorie plusieurs types de lignes en fonction deleur débit. Sa syntaxe est OC-x avec le x comme coefficient multiplicateur. OC-3 est l’équivalent de3*51,84 = 155 Mbps. L’équivalent d’OC-3 dans la hiérarchie SDH (Synchronous Digital Hierarchy) eneurope 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 quicomprennent chacun 32 E1. Chaque E1 supporte simultanément plusieurs types de services Frame Relay,


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 hautdébit basés sur standard, y compris le Frame Relay, l’émulation de circuit, la voix et l’IP. Ces interfacesfournissent une grande variété d’accès et d’agrégation de vitesse de DS-0 (64 Kbps) à OC-48 (2 488,32Mbps). Il est composé du Passport 7480 et du Passport 15000. Le Passport 15000 est un commutateurde 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 servicesbasé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).


Figure 2.6 – Nortel Passport 15000-VSS

En outre de leur capacité de gestion intelligente du trafic, ils supportent simultanément les traficsde la voix, les données, la vidéo et l’image, en un mot des commutateurs multiservices. Ils offrent uneredondance complète, évolutive à grande capacité, haute vitesse d’accès et de raccordement au réseau. Deconfiguration matérielle et logiciel modulaire, on peut modifier la configuration des composants matérielset logiciels pour chaque site selon les besoins.

Figure 2.7 – Réseau ATM Nortel de Tunisie Telecom


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’assurerson 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îtressede la supervision est de contrôler la fiabilité et la pérennité du réseau, des services informatiques afinde 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 tendancen’est pas à l’investissement dans de nouvelles technologies, mais à l’optimisation et au rendement del’existant à moindre coût. De plus, l’évolution des méthodes de travail au sein même de l’entreprise veutqu’une part de plus en plus importante de l’activité de celle-ci sollicite les outils informatiques. Dans lecas des sociétés de services en informatique, c’est toute l’activité des ingénieurs et dirigeants qui reposentinté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 supervisionest donc de pouvoir connaître en permanence l’état du réseau, et d’être averti en temps réel des différentsincidents pour réduire au maximum les délais d’intervention et de coupure du service, et d’exploiter aumieux les capacités du réseau.

A présent, de nouveaux besoins se font sentir. Le premier besoin est de rompre la contrainte deproximité 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 gestiondu réseau par le réseau. Le second besoin concerne la dépendance humaine. La complexité des réseauxs’accroissant, la tâche de gestion du réseau exige une telle masse d’informations à traiter qu’elle dépassela 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 leré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 desservices que ce dernier propose. Si nous prenons l’exemple du Backbone ATM de Tunisie Telecom, il doitpermettre 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


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 lesfichiers de configurations des équipements etc. La tâche d’exploitation d’un réseau est délicat d’autantplus qu’on doit prendre le soin de ne jamais dépasser les quantités de ressources que le réseau met à notredisposition.

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 abesoin. Ces informations parviennent de chacun des éléments du réseau. Pour les obtenir, une étape dedécouverte des éléments de réseau est effectuée, puis les requêtes sont envoyées aux éléments un à un pouren tirer les informations de gestion. Ces informations de gestion comprennent toutes sortes d’informationsreliées à un élément de réseau : le type d’équipement, le nombre de paquets qui passent sur chaque portd’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 quipermet de réaliser ces fonctionnalités. Une fois que l’on a les informations de gestion, il est importantde les interpréter correctement. Par exemple : 5000 paquets par seconde sur un port d’un routeur estpeut-être normal ou peut-être le signe d’une surcharge et d’une dégradation de la qualité du serviceoffert. Même si on connaît la charge exacte d’un routeur, cette information ne suffit pas pour prendre desdé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 etcorrecte de l’état d’un réseau et de ses équipements est difficile à réaliser. L’intervention humaine estsouvent 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. Ildoit être possible de demander à un équipement, par exemple, de se réinitialiser, de couper ou d’activerdes 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. Onpeut donc identifier trois composants :

– La partie client, appelée manager, est l’entité qui va superviser les opérations de gestion. Elle sertd’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’interfaceentre l’équipement et le manager. Il peut également servir d’interface entre plusieurs autres agentset le manager. L’agent permet de fournir une vue abstraite de l’équipement et masque ainsi lesdiffé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’interrogerl’agent (dans le cas du monitoring) ou de lui demander de modifier l’état de l’équipement (dans le


cas de la configuration). Le protocole est également utilisé par l’agent afin d’avertir le manager del’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 NetworkManagement Protocol) qui offre une grande panoplie de fonctionnalités et disponible sur les commutateursNortel. Comme son nom l’indique, c’est un protocole très simple à utiliser du fait du nombre très limitésde 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 secondeversion, appelée SNMP v2 a été standardisée en 1992 [RFC1905]. Cette version apporte essentiellementdes changements au niveau de la sécurité et de la confidentialité des opérations de gestion. Suite à desproblè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 poureffet, d’une part de renvoyer SNMP à son état de 1989 et d’autre part, de déclencher les recherches surSNMP v3. Les travaux se poursuivent actuellement et petit à petit les différents éléments de l’architectureSNMP v3 sont proposés à la communauté scientifique [RFC2274]. SNMP v3 (dans les aspects qui sontactuellement définis) est en passe de devenir un standard car il est accepté par le working group SNMPv3 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.


SNMP suit l’architecture client/serveur, le client étant le manager et le serveur l’agent. Contrairementaux architectures client/serveur habituelles où un serveur interagit avec plusieurs clients, SNMP estl’exemple d’un schéma inverse : un client, souvent unique, communique avec plusieurs serveurs. Il y a unagent par équipement à gérer. L’agent conserve une série de variables qui modélisent l’équipement. Lemanager, au travers de l’agent, consulte et/ou modifie les valeurs des variables à l’aide d’opérations demanagement. 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’ensembledes variables gérées est appelé MIB (Management Information Base). Le manager interagit avec l’agentvia un protocole de communication qui spécifie la dynamique de la communication (mécanismes dequestion/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 informationnelde l’équipement. Les variables sont organisées sous une forme arborescente. Les nœuds intermédiairesservent uniquement de points de rattachement pour les branches, ils ne contiennent aucune valeur. Lesfeuilles par contre stockent des valeurs.

La MIB déclaration est décrite à l’aide d’un langage spécifié dans un standard appelé Structure ofManaged 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 lesinformations suivantes :

– Un nom.– Un type : il s’agit soit d’un type simple : INTEGER, OCTET-STRING, NULL, soit d’un type deconstruction : 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.


Figure 2.10 – Structure d’indexation des données dans la MIB-2 SNMP

L’objet snmpInPkts dans MIB II :snmpInPkts OBJECT-TYPESYNTAX CounterACCESS read-onlySTATUS mandatoryDESCRIPTION "The total number of Messages delivered tothe 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 à partirde la racine. La racine est identifiée par le nombre ’1’. Le nombre suivant, c’est-à-dire le second nombredans la dot notation, identifie le numéro du fils de la racine. On procède récursivement jusqu’à la fin del’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 demanagement :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/IPstandard. L’objet snmpInPkts est le premier fils en partant de la gauche du groupe snmp qui lui-mêmea l’identificateur 11. On utilise comme notation abrégée snmp(11). L’object identifier d’une instance estconstruit 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 deconstruction est différent. Dans le cas des variables simples, on postfixe l’identificateur de l’objet par unnuméro d’instance. Les instances sont numérotées à partir de zéro. L’instance correspondant à l’objet


snmpInPkts sera donc identifiée par 1.3.6.1.2.1.11.1.0. Si une instance supplémentaire existe (ce quin’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 instancesappartenant à 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 distanteet Telnet nous renvoie les réponses de ladite machine. Généralement, la machine distante commence latransaction par nous demander un mot de passe d’accès, puis nous donne accès à un shell (terminal) surlequel 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 « dFruni/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. Chaqueconstructeur inclut son propre gestionnaire Telnet personnalisé, et la gestion du réseau n’est donc pasuniforme suivant le type de matériel. Telnet assure intrinsèquement la fiabilité de la transaction de parl’utilisation du protocole TCP, toutefois la communication entre l’administrateur et le matériel n’est pascryptée et la seule sécurité apportée est l’authentification initiale. Le protocole SSH (Secure SHell) comblecette lacune en cryptant la transaction via le protocole SSL. Toutefois l’interface reste propre à chaquematériel et ne permet pas d’effectuer des transactions parallèles ou une gestion uniforme de ceux-ci.


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). Dupoint de vue fonctionnel, il est bien plus riche que SNMP mais plus difficile à mettre en œuvre. Il n’estpas 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 queles informations de gestion du réseau passent par les mêmes chemins que les données que le réseau doittransporter (les données utiles) ce qui est l’opposé de la gestion Out-of-band. Pour différencier les donnéesdu 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. Dansun premier temps nous avons décrit le Backbone ATM de Tunisie Telecom, ensuite nous nous sommespenché sur le Réseau ATM Nortel. Nous avons également décrit le réseau d’accès au Backbone ATM, etnous avons présenté les équipements constitutifs du Backbone ATM Nortel de Tunisie Telecom et enfinsa 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 dedéveloppement logiciels. La mise en œuvre de logiciels réseau n’échappe pas à cette tendance. Commetous les autres projets logiciels, les logiciels réseaux (y compris les applications web) peuvent profiterdes avantages de l’orientée objet. Cette technique permet la construction d’un programme solide, bienstructuré, facile à visualiser et qui est facile à modifier et à maintenir. Le recours à la modélisation estdepuis longtemps une pratique indispensable au développement logiciel, car un modèle est prévu pourarriver à anticiper les résultats du codage. Un modèle est en effet une représentation abstraite d’unsystème à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre lesdiffé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écificationdes 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) estdevenue incontournable sur la plupart des projets informatiques. UML se définit comme un langage demodélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenterdes systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points devue. 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ératifet 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) quiaident à mieux suivre l’avancement global. À la fin de chaque itération, une partie exécutable dusystème final est produite, de façon incrémentale.

– Centré sur l’architecture : tout système complexe doit être décomposé en parties modulaires afinde 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 surtoutlevés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre desitérations.

– Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et des exigencesdes utilisateurs. Les cas d’utilisation du futur système sont identifiés, décrits avec précision etpriorisés. [3]

Dans la suite de ce chapitre, nous détaillerons dans un premier temps les exigences fonctionnelles del’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 casd’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. Elleconsiste 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 souslesquelles 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. Deplus, à ce stade d’analyse, il est impératif de bien comprendre les besoins des clients, car chaque petitelacune 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 desliaisons, de supervisions, et de maintenances du réseau d’accès DATA, en gros on définit les services dusystè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 FrameRelay 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. Atravers chaque DNA, on connaitra le commutateur concerné, la carte, la ligne E1 et le canal sur lequell’abonné a été affecté. Chaque canal est subdivisé en 32 intervalles de temps appelés Time Slots délivrantchacun un débit physique de 64 Kbits/s. Pour un abonné qui a besoin d’un débit de 128 Kbits/s, on luiattribuera alors 2 Time Slot et ainsi de suite. Le FRUNI (Frame Relay User Network Interface) qui estconstitué du LP, E1 et Canal sera automatiquement déduit du DNA et du RDNA. Pour les DLCI (DataLink Connection Identifier) et RDLCI (Remote Data Link Connection Identifier), ça sera à la charge del’application de savoir exactement quelles valeurs utilisées en fonction de celles qui sont déjà allouées, cesvaleurs é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 liaisonFrame Relay existante. Cette création devra précéder la tâche de création Port et circuit. Les donnéesfournies par l’utilisateur sont le DNA, le RDNA et le débit circuit. La procédure est presque identiquedans le cas précédant.

La création de liaisons spécialisées émulée sur ATM : Cette tâche consiste à créer une composantecouche 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 lesDNA et le RDNA, les DLCI et RDLCI et le nouveau débit circuit, l’application vérifie sur le commutateurque 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 nouveauxTimes 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 quepour la modification. Une fois la vérification terminée, le circuit sera alors résilié.


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. . . serontlibé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’adresseIP 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 permettrontde résoudre cela).

Les tâches de maintenance telles que le Test de boucle local jusqu’à l’abonné, La gestion de l’espacedisque 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 lefonctionnement 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 uneconnexion 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 consommatricede 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 exigencesd’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.


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 dansles spécifications d’un système. Il permet de définir le QUI FAIT QUOI ? Pour NMS ATM Nortel, aprèsl’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 pourraentreprendre 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 à unemaquette d’interface homme-machine (IHM). Dans cette partie, nous allons détailler la modélisation descas d’utilisation. La réalisation d’une maquette graphique est une activité courante mettant en jeu desoutils de dessin. Elle montre rapidement l’aspect visuel (le « look ») de l’application. Un cas d’utilisationdé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’utilisationsont 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.


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 ouautre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifierdirectement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteursde 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 pourraentreprendre 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 rectangulaired’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 rectangulairepour les systèmes connectés.


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 quiproduisent un résultat observable intéressant pour un acteur particulier. Dans la phase de spécificationsdes exigences fonctionnelles, le modèle des cas d’utilisation considère le système comme une boite noireet décrit les interactions entre le ou les acteurs et le système sous forme textuel, qui consistent auxcommandes 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éliminairesdu 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.


Pour améliorer notre modèle, nous allons organiser les cas d’utilisation et les regrouper en ensemblesfonctionnels cohérents. Pour ce faire, nous utilisons le concept général d’UML, le package. Le package estun mécanisme général de regroupement d’élément UML, qui peut être utilisé par exemple pour regrouperdes 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 decas d’utilisation. L’organisation générale du modèle dans un outil de modélisation est représentée sur lafigure 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 parassociations (lignes) à leurs acteurs.

Figure 3.5 – Cas d’utilisation création de liaisons


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 relationsaux cas d’utilisation. On peut l’exprimer en créant un acteur généralisé, éventuellement abstrait, quimodé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 tousles deux réalisés les différentes tâches de créations. Ils peuvent (Administrateur et Opérateur) égalementeffectuer les modifications ou des résiliations de liaisons (voir figure 3.6). Les commutateurs A et Bsont nécessaires à la création de la liaison puisque le lien est créé entre les deux commutateurs. Il fautaussi noter que pour créer un nouveau circuit, le port doit être déjà présent d’où la relation d’inclusionformalisé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 pourplus de sécurité, car n’importe qui ne devra pas être capable d’accéder à l’application sinon cela auraitdes 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 circuitsur ordre et les tâches de résiliation de port et de circuit reviennent à l’administrateur parce que cestâ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 nes’effectuent que sur un seul commutateur. Pour modifier le débit d’un circuit, les deux commutateurs surlesquels 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 aupré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’afficherles multiplexeurs reliés à un commutateur, ou de lister les abonnés d’une ligne, etc. . . ne demande pasun niveau de privilège élevé, donc tous les acteurs (Superviseur, Opérateur et Administrateur) peuventréaliser la supervision, d’autant plus que la supervision est une tâche assignée au superviseur. Chaqueutilisateur devra tout de même être authentifié avant de pouvoir réaliser quoi que ce soit sur le système.


Figure 3.7 – Cas d’utilisation supervision

L’ajout d’un nouveau multiplexeur, la sauvegarde des fichiers de configuration sont des tâches quipeuvent être exécuté par un opérateur ou administrateur, car pour réaliser ces cas d’utilisation, l’acteurdevrait avoir un niveau de privilège un peu plus élevé. Un superviseur peut aussi connaitre l’état des lignesE1, E3, l’état d’une liaison Frame Relay et avertir en cas de problème un opérateur ou un administrateurpour qu’il intervienne et résoud le problème. Toutes ces tâches ne mettent qu’un seul commutateur enjeu d’où la présence de l’acteur secondaire commutateur. Le diagramme de cas d’utilisation de ce packageest représenté sur la figure 3.8.

Figure 3.8 – Cas d’utilisation exploitation


Pour les tâches de maintenance, les cas d’utilisation que nous avons pu avoir sont : Le test de bouclejusqu’à l’abonné, la gestion de l’espace disque des commutateurs et la gestion des alarmes générées parles 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’utilisationpour 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 desliaisons, Exploitation et Maintenance et Supervision.

Figure 3.10 – Organisation complétée des cas d’utilisation et des acteurs


3.2.3 Traçabilité avec exigences textuelles

Lors de la spécification des exigences fonctionnelles, nous avons saisi un certain nombre d’exigencesdans Enterprise Architect. Nous allons maintenant établir la relation entre cas d’utilisation que nousvenons d’identifier et les exigences textuelles. Cette étude permet à la fois de valider la complétude descas d’utilisation, mais aussi d’améliorer celle des exigences textuelles. Enterprise Architect permet ainside 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ésdans la partie précédente. Nous complèterons cette description textuelle par une représentation graphiqueUML très utile : le diagramme de séquence. Vu le nombre important de cas d’utilisation, on ne va pasdé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


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 avonsdonc 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 CircuitActeur PrincipalL’utilisateur (Acteur généraliser d’Administrateur et Operateur)Acteurs SecondairesLes deux commutateurs A et BObjectifL’utilisateur veut créer une nouvelle liaison Frame-Relay Port et Circuit entre le commutateur A et lecommutateur B.PréconditionL’utilisateur s’est authentifié sur l’application.Post conditionLa 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.

Alternatives1a- 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émentaireUne fois le processus de création lancé, il ne doit pas être interrompu.

Créer une Liaison Spécialisée émulée sur ATMActeur PrincipalL’utilisateur (Acteur généraliser d’Administrateur et Operateur)Acteurs SecondairesLes deux commutateurs A et BObjectifL’utilisateur veut créer une nouvelle liaison spécialisée à émulation de circuit entre le commutateur A etle commutateur B.PréconditionL’utilisateur s’est authentifié sur l’applicationPost conditionLa liaison a été correctement créée et est opérationnelle.Scénario Nominal

1. L’utilisateur choisit les commutateurs A et B.


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.

Alternatives1a- 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émentaireUne fois le processus de création lancé, il ne doit pas être interrompu.

Lister les abonnésActeur PrincipalL’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur)Acteur SecondaireLe CommutateurObjectifL’utilisateur veut avoir la liste des abonnés d’une liaison E1, par la suite il pourra avoir plus de détailssur une liaison tel que le type de la liaison (Frame Relay/Aal1Ces), les ITs accordés à un abonné et etc.PréconditionL’utilisateur s’est authentifié sur l’application.Post ConditionUne 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-RelayActeur PrincipalL’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur)Acteur SecondaireLe CommutateurObjectifL’utilisateur veut avoir l’état d’une liaison Frame-Relay (LMI) et la liste des circuits virtuels permanents(PVC) et leurs états respectifs.PréconditionL’utilisateur s’est authentifié sur l’application.Post ConditionL’é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.


Gérer les multiplexeursActeur PrincipalL’utilisateur (Acteur généraliser de l’Administrateur et Opérateur)Acteur SecondaireLe commutateurObjectifL’utilisateur veut ajouter un nouveau multiplexeur en affectant une jonction 2 Mbits/s au commutateur.PréconditionL’utilisateur s’est authentifié sur l’applicationPost ConditionLa 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 configurationsActeur PrincipalL’utilisateur (Acteur généraliser de l’Administrateur et Opérateur).Acteur SecondaireLe commutateur.ObjectifL’utilisateur veut sauvegarder le dernier fichier de configuration d’un commutateur.PréconditionL’utilisateur s’est authentifié sur l’application.Post ConditionLe 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 disqueActeur PrincipalL’utilisateur (Acteur généraliser de l’Administrateur et Opérateur).Acteur SecondaireLe commutateur.ObjectifL’objectif de cette tâche est de supprimer les fichiers inutiles pour libérer de l’espace disque sur le com-mutateur.PréconditionL’utilisateur s’est authentifié sur l’application.


Post ConditionUne 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 localeActeur PrincipalL’utilisateur (Acteur généraliser de l’Administrateur et Opérateur).Acteur SecondaireLe commutateur.ObjectifDans 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éconditionL’utilisateur s’est authentifié sur l’application.Post ConditionPlusieurs 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 traficActeur PrincipalL’utilisateur (Acteur généraliser de Superviseur, Administrateur et Opérateur).Acteur SecondaireLe commutateur.ObjectifL’utilisateur souhaite visualiser l’intensité du trafic d’une liaison inter-sites.PréconditionL’utilisateur s’est authentifié sur l’application.Post ConditionUn 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.


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 voulonsspécifier et concevoir. Lors de ces interactions, les acteurs produisent des messages qui affectent le systèmeinformatique et appellent généralement une réponse de celui-ci. Nous allons isoler ces messages et lesreprésenter graphiquement sur des diagrammes de séquence UML.

Pour les messages, les DSS (diagrammes de séquence système) montrent non seulement les acteursexternes 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 desmessages 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 CircuitIl 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 dudiagramme et le système NMS ATM Nortel entre l’utilisateur et les commutateurs qui sont les acteurssecondaires. Le mot-clé « system » est utilisé dans le système boite noire pour le différencier plus nettementdes acteurs. (Figure 3.12)

Figure 3.12 – Diagramme de séquence système Créer une liaison Frame Relay port et circuit


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


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 FrameRelay

Gérer les multiplexeurs

Figure 3.16 – Diagramme de séquence système Gérer les multiplexeurs


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


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


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 derelations entre ces classes [1]. De même qu’une classe décrit un ensemble d’objets, une association décritun ensemble de liens ; les objets sont instances des classes et les liens sont instances des relations. Undiagramme 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 prendune 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 dedécrire le comportement d’un objet. Un exemple d’opération sur la classe Commutateur est qu’on ajouterun 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’estrelié qu’à un et un seul commutateur.


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

Un abonné a la possibilité d’avoir plusieurs liaisons Frame Relay ainsi qu’ATM, et ces liaisons nepeuvent appartenir qu’à un seul Abonné. Chaque liaison Frame Relay et Aal1Ces est composé de circuitvirtuel 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 FrameRelay 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 à 1023par ordre croissant et un pas d’incrémentation de 1. Un exemple de création est que si on crée une liaisonFR, le premier circuit de ce lien aura comme DLCI 16, le circuit suivant qui sera créé sur ce lien auracomme 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, danstous les cas possibles [3]. Cette vue locale d’un objet, qui décrit comment il réagit à des événements enfonction de son état courant et comment il passe dans un nouvel état, est représentée graphiquementsous la forme d’un diagramme d’états. Les diagrammmes d’états sont utilisés pour modéliser l’aspectdynamique d’un système. Le diagramme d’états est une représentation graphique d’une machine à étatsfini 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 certainecondition, il exécute une certaine activité, ou bien il attend un certain événement. Un objet passe parune succession d’états durant son existence. Un état a une durée finie, variable selon la vie de l’objet, enparticulier 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’objetchange 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 diagrammed’é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éationd’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éationest terminée sur le premier commutateur, la transition « lancement de la création » est franchie pourlancer la création sur le second commutateur ; une fois toutes les instructions exécutées, un résumé de lacréation s’affiche dans la quelle apparait l’état de la nouvelle liaison.


Figure 3.22 – Diagramme d’état Création liaison FR port et circuit

Figure 3.23 – Diagramme d’état Supervision du trafic


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 etetc. . . ) est constituée des tables suivantes :

– Commutateurs : Cette table stockera les informations relatives à chaque commutateur qui sera gérerpar 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éesentrant 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 chaquecommutateur ;

– Infotrafic : cette table recevra les données sur le trafic provenant de chaque interface de tous lescommutateurs 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 desalarmes ;


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 notreapplication 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 suitenous permettrons de codé proprement notre application. Le chapitre suivant sera sur l’implémentationde l’application NMS ATM Nortel et l’observation des premiers résultats.

Chapitre 4

Implémentation

Introduction

Après avoir achevé la partie conception de l’application, il s’agit de présenter la partie réalisation etmise en œuvre de notre travail ainsi que les tests d’évaluation. Pour cela, nous présenterons, en premierlieu, la technologie de développement web choisie, l’environnement de travail. Enfin, nous décrirons lestests d’évaluation faits pour examiner le bon fonctionnement de toute l’application.

4.1 Technologie de développement web

La technologie de développement constitue le moteur d’une application Web : c’est elle qui déterminele mécanisme de génération dynamique des pages Web ainsi les systèmes d’exploitation, bases de données,langages et outils de développement utilisables.

ASP.NET est une nouvelle technologie de développement d’applications et de services Web, introduitepar Microsoft en 2001, qui repose sur des pages compilées, des contrôles prédéfinis, un mécanisme de ges-tion événementielle et une infrastructure technique intégrant des fonctionnalités de sécurité, optimisationet gestion des erreurs.

La plate-forme .NET est un ensemble formé d’outils (présents dans le SDK), de modules actifs auruntime (le Common Language Runtime par exemple) et de classes formant une API (Application Pro-gramming Interface) très étendue pour les applications de bureau comme pour les applications Internet.Des langages exploitent cette nouvelle base comme C#, Visual Basic .NET ou Delphi.NET. Du point devue du développeur la plate-forme .NET peut être vue comme le successeur objet des API Win32. Lepoint fort de .NET est d’intégrer des technologies existantes dans un tout cohérent. Par exemple, toutce qui concerne les communications de données reste basé sur SOAP, XML et HTTP. La seule différencetechnique majeure est l’adoption d’un système d’exécution virtuel (VES : Virtual Execution System) etqui se trouve désormais au cœur de toute la structure .NET et sur laquelle tout repose.L’ensemble .NET peut être ainsi divisé en :

– Un framework proprement dit (bibliothèques de classes) ;– Des outils de développement comme Visual Studio .NET– Un ensemble de serveurs comme MS SQL Server ou IIS (Internet Information Server)– Et etc. . .

43

CHAPITRE 4. IMPLÉMENTATION 44

Figure 4.1 – Ensemble Framework .NET

Le choix de la technologie ASP.NET a été très judicieux, dans la mesure où déjà à Tunisie Telecomelle est la plus répandu, mais aussi elle permet de créer des applications web robustes, performantset sécurisées. C’est une technologie de développement qui augmente nettement le rendement de parl’utilisation des composants réutilisables, elle offre une manière originale de découpler le code applicatifde la présentation. La partie présentation reste du pur HTML et l’essentiel du code applicatif est déportédans une classe associée à la page ASP.Net : une classe dite CodeBehind. ASP.NET propose d’aller plusloin grâce au WebForms qui aide à développer graphiquement des pages web dynamiques (et réactiveau évènement de l’utilisateur), tout comme on développerait une application « client lourd » en VisualBasic, Delphi ou Java/Swing. La facilité de prise en main de ces outils est déconcertante et invite às’appuyer sur une architecture propre favorisant maintenance et performance, ce qui accélère les tempsde développement.

Enfin, dans ce nouveau framework ASP.NET, les performances sont nettement améliorées du fait quetoutes les pages (ASP.NET) et les classes (CodeBehind) sont précompilées et non plus exécutées commec’était le cas en ASP. Avec l’ajout des fonctionnalités AJAX (Asynchronous Javascript And XML), ledéveloppement d’applications web ASP.NET riches et interactives (Validation et mise à jour partielled’une page, aide à la saisie, tri, filtrage et réorganisation des données côté client, consommation desservices distant etc. . . ) est devenu très aisé.

Dans ce projet, nous avons opté de coder la partie applicative par le langage VB.Net (Visual Basic .Net)qui est une évolution majeure de Visual Basic, auquel ont été principalement ajouté des fonctionnalitésobjet (constructeurs et destructeurs, surcharge de méthodes, héritage, etc.).

4.2 Environnement de développement

Après le choix de développer avec ASP.NET, l’environnement de développement que nous avons uti-lisé est Microsoft Visual Studio 2010. Visual Studio est un ensemble complet d’outils de développementpermettant de générer des applications Web ASP.NET, des Services Web XML, des applications bu-reautiques et des applications mobiles, des services Windows. Visual Basic, Visual C++, Visual C# etVisual J# utilisent tous le même environnement de développement intégré (IDE, Integrated DevelopmentEnvironment), qui leur permet de partager des outils et facilite la création de solutions faisant appel à


plusieurs langages. Par ailleurs, ces langages permettent de mieux tirer parti des fonctionnalités du Fra-mework .NET, qui fournit un accès à des technologies clés simplifiant le développement d’applicationsWeb ASP et de Services Web XML grâce à Visual Web Developer.

Figure 4.2 – IDE Microsoft Visual Studio

Comme serveur d’application web, nous avons opté pour Internet Information Service IIS de Microsoft.Il est très performant et offre également une couche SSL (Secure Socket Layer) pour une utilisation cryptéedu protocole http. Il est le logiciel de serveur services Web (ou FTP, SMTP, HTTP etc.) de la plateformeWindows NT.

Le serveur de base de données utilisé pour la réalisation de ce projet est Microsoft SQL Server 2008. Ceproduit Microsoft est l’un des serveurs de base de données les plus performants existant sur le marché. Depar sa grande performance et fiabilité, la qualité qui a orienté notre choix vers ce serveur est sa capacitéd’opérer en temps réel. En effet, pour les données de supervision, nous avons besoin d’être informé entemps réel (Graphe d’évolution du trafic, gestion des alarmes etc).

Un service Windows permet d’effectuer une tâche en arrière-plan sans qu’il n’y ait une interface utili-sateur. Pour collecter les données sur le trafic, vérifier l’état de chaque interface de tous les commutateurs,pour sauvegarder les fichiers de configuration des commutateurs de façon régulière et automatique, nousavons développé des services Windows pour chacune de ces tâches cruciale au bon fonctionnement denotre application.

Figure 4.3 – Architecture du NMS ATM Nortel


4.3 Mise en œuvre

Le but n’est pas, ici, de décrire les lignes de code source les unes après les autres. Cela serait fastidieuxet profondément ennuyeux pour le lecteur. Il s’agit plutôt d’expliciter les buts et les raisonnementseffectués pour chaque classe implémentée. Cette dernière partie représente la plus grande du tempsconsacrée à ce projet.

4.3.1 Le service TraficInfo

TraficInfo est le service qui a pour tâche de collecter les informations sur le trafic courant du Backboneavec SNMP v1 et les stocker dans la base de données afin de suivre son évolution en temps réel et de garderun historique bien détaillé sur le trafic entrant et sortant sur chaque interface de chaque commutateur àintervalle régulier.

TraficInfo commence par contacter la base de données pour avoir la liste des commutateurs, puis pourchaque commutateur il extrait à partir de la table Cartes la liste des cartes que contient ce commutateuret, à partir de la table interfaces récupère les interfaces. Ensuite TraficInfo envoi une requête SNMP GETsur l’OID caractérisant le trafic entrant et sortant d’une interface sur commutateur puis enregistre lavaleur retournée par cette requête dans la table InfoTrafic en précisant la date et l’instant exact de lacapture. La figure suivante (Figure 4.4) résume le fonctionnement de ce processus.

Figure 4.4 – Schéma de fonctionnement du service TraficInfo

4.3.2 Le service AlarmeManage

Le rôle du service AlarmeManage est de vérifier l’état de bon fonctionnement de toutes les interfacesde tous les commutateurs Backbone. En effet, ce service récupère la liste des commutateurs à partir dela base de données, pour chaque commutateur il extrait la liste des interfaces présentes sur chaque cartede ce dernier, ensuite envoi des requêtes SNMP pour obtenir l’état des différentes interfaces. S’il y’a desinterfaces qui ont générées des alarmes, alors le service AlarmeManage enregistre ces alarmes dans labase de données en détaillant l’identifiant de l’interface qui a générée l’alarme, la date et l’instant exactauxquelles la capture a été faite. Ces informations sont enregistrées dans la table InfoAlarm. Le schémade fonctionnement est la suivante :


Figure 4.5 – Fonctionnement du service AlarmeManage

Grâce au système de rafraichissement automatique et régulier, toutes les pages du NMS ATM Nortelcontiennent un bloc représentant l’état des interfaces. Ce système fonctionne par un timer qui à chaque àTick, l’application se connecte à la base de données, consulte l’état des différents interfaces dans la tablequi a été remplie par le service InfoAlarm. Si une alarme est présente, alors l’état du type d’interface (E3,STM-1) concerné devient rouge jusqu’à ce que l’alarme soit résolue et archivée.

4.3.3 Le service BackupAuto

Le rôle du service BackupAuto est de sauvegarder les fichiers de configurations des commutateurs. Ceservice utilise le protocole FTP (File Transfert Protocol) pour le téléchargement des fichiers de configu-rations.

Le protocole FTP est un protocole de communication destiné à l’échange de fichier informatique surun réseau TCP/IP. Il permet depuis un ordinateur dit client, de copier des fichiers vers un ordinateurdit serveur. Le transfert des fichiers peut être sécurisé à l’aide du SSL (Secure Socket Layer) ou TLS(Transport Layer Security) appelé FTPS. Le protocole FTP utilise le port 20 pour l’échange des donnéeset le port 21 pour les informations de contrôles (suppression, liste des fichiers etc.). Les commutateursNortel offrent les services FTP.

Le service BackupAuto commence par contacter la base de données pour avoir d’abord la période dela sauvegarde, ensuite la liste des commutateurs. Ensuite, pour chacun des commutateurs, il se connectepar Telnet au commutateur pour avoir le dernier fichier de configuration, puis par la suite utilise FTPpour télécharger ce fichier. A chaque téléchargement, le service crée un répertoire représentant la datedu jour qui contiendrait les fichiers téléchargés ce jour-là, chaque fichier étant nommé par le nom ducommutateur plus son adresse IP.


Figure 4.6 – Fonctionnement du service BackupAuto

La configuration de la période de sauvegarde automatique se fait à partir du NMS ATM Nortel via unepage en spécifiant l’heure de la sauvegarde.

Figure 4.7 – Page de configuration de la sauvegarde automatique

4.3.4 NMS ATM Nortel

Dans cette section, nous allons présenter les parties les plus importantes de l’application web que nousavons réalisée.

La première page qui s’affiche lors du lancement de l’application est la page d’authentification quidemande le nom de l’utilisateur et son mot de passe. La connexion est également sécurisée avec l’utilisationdu HTTPS (HTTP Secure) qui utilise le protocole SSL (Secure Sockets Layer) pour crypter l’échange dedonnées entre le client et le serveur.


Figure 4.8 – Page de connexion au NMS ATM Nortel

Une fois la connexion établie, la page d’accueil du NMS ATM Nortel affiche l’intégralité du réseauNortel de Tunisie Telecom, l’utilisateur pourra ensuite cliquer sur un lien entre les commutateurs pourvoir l’intensité du trafic ou cliquer sur un commutateur pour la liste des cartes, par la suite pour chaquecarte il peut visualiser les différents détails de chaque ligne présente sur cette carte. Tous les liens ontune étiquette qui indique le type de lien utilisé.

Figure 4.9 – Page d’accueil du NMS ATM Nortel

Si par exemple l’utilisateur choisi de cliquer sur un commutateur, la page suivante s’affiche (figure4.10) ; elle contient la liste des cartes du commutateur choisi.


Figure 4.10 – Listing des cartes d’un commutateur Nortel

Ensuite l’utilisateur, sélectionne la carte N° 3, les lignes de cette carte s’affichent. Cette page estreprésentée par la figure 4.11.

Figure 4.11 – Les lignes de la carte 3

Pour afficher les différents états d’une ligne quelconque (E1, E3, STM-1), l’utilisateur peut cliquer surla ligne puis la page des détails sur cette ligne s’affiche.


Figure 4.12 – Les détails d’une ligne E1

Pour la création d’une nouvelle liaison Frame Relay Port et Circuit, l’utilisateur fournit le nom del’abonné, le DNA, le RDNA (le DNA et le RDNA ont été cité et décrit dans le chapitre conception), ledébit port et débit circuit, puis enfin il sélectionne les times slots accordés à cette liaison.

Figure 4.13 – Page de création d’une nouvelle liaison Frame Relay

Une fois la création terminée, une page affiche le résumé de la création en spécifiant le DLCI et leRDLCI affecté à cette liaison.


Figure 4.14 – Page de résumé Création Frame Relay

Pour la création d’une nouvelle liaison spécialisée à émulation de circuit, l’utilisateur choisit le com-mutateur A et B, les différentes cartes et lignes, les canaux, les intervalles de temps et le débit. Puis illance la création.

Figure 4.15 – Création d’une LS à émulation de circuit

De même que pour la création Frame Relay, la page de résumé s’affiche après la création et contientles informations de la nouvelle liaison qui vient juste d’être créée et son état.

Figure 4.16 – Résumé de Création d’une LS à émulation de circuit


Pour un superviseur, lister les abonnés d’une ligne 2Mbits/s est très facile, puisqu’il ne lui faudra quequelques clics de souris : Sélectionner le commutateur, la carte, la ligne et la liste des abonnés s’affiche.

Figure 4.17 – Liste des abonnés

Le plus de la colonne « Détails » permet d’avoir plus détails sur la liaison (Frame Relay, Aal1ces,etc.).

Figure 4.18 – Informations détaillées sur une liaison

La page Display composite permet de connaitre les détails sur l’état d’une liaison Frame Relay (alarme,état de fonctionnement), et il permet également de connaitre les états d’une ligne 2Mbits/s, 34 Mbits/s,d’une liaison spécialisée à émulation de circuit et etc. La figure 4.19 montre un exemple pour une liaisonFrame Relay.


Figure 4.19 – Test d’une liaison Frame Relay

Sur la figure, on peut voir l’état de la liaison physique à travers le LMI (Local Management Interface)qui est UP, ce qui signifie que la liaison fonctionnement correctement. On voit également la liste des PVC(Permanent Virtual Circuit) et leurs états.

Pour la visualisation en temps réel du trafic, l’architecture suivant a été mis en place. Le serviceTraficInfo rempli la base de données, puis grâce à la technologie Silverlight-Ajax-WebService, le graphedu trafic est mise à jour à chaque écoulement d’un délai qui est spécifier (10s, 20s, 30s).

Figure 4.20 – Graphe d’évolution du trafic en fonction du temps

À partir de la liste des commutateurs sur le volet gauche, on peut accéder au graphe du trafic d’unlien spécifique du Backbone comme à partir de l’intégralité du réseau en cliquant sur le lien.

La page pour la gestion de l’espace disque d’un commutateur est la suivante. L’utilisateur sélectionneun commutateur puis l’utilisation de l’espace disque de ce commutateur s’affiche. (Figure 4.21)


Figure 4.21 – Occupation de l’espace disque d’un commutateur

Ensuite si l’utilisateur juge qu’il est nécessaire de libérer de l’espace sur le disque du commutateur enquestion, il clique sur le bouton “explorer” qui lui affiche les fichiers présents sur le disque. Il a le choixentre cocher quelques fichiers pour les supprimer ou spécifier une plage de date. Dans le cas deuxièmecas, les fichiers qui ont été créé dans cette plage seront sélectionnés et supprimés.

Figure 4.22 – Sélection des fichiers à supprimer


Lorsqu’une alarme est détectée par l’application, dans le volet droit représentant l’état des interfaces,le type d’interface concerné devient rouge pour signaler à l’utilisateur qu’il y’a un problème.

Figure 4.23 – Alarme(s) détectée(s) par NMS ATM Nortel

Pour afficher les détails de l’alarme, l’utilisateur clique sur le type d’interface ; ici c’est E3 par la suitela page affiche la liste des alarmes sur les interfaces E3.

Figure 4.24 – Liste des alarmes

À partir de cette liste, on peut voir l’interface qui a générée l’alarme, le commutateur concerné etle type de l’alarme. En cliquant sur l’interface, une autre page s’affiche pour donner plus de détails surl’alarme en question, la date de sa détection, sur quelle carte se trouve l’interface qui a générée l’alarme,et un bouton pour confirmer que l’alarme a bien été traitée. (Figure 4.25)

Figure 4.25 – Traitement des alarmes


Conclusion

Nous venons, au terme de ce chapitre de présenter la technologie de développement ASP.NET que nousavons utilisé, les principaux services Windows utilisés par notre application ainsi que ses fonctionnalités.Plusieurs informations n’ont pas pu être divulguées faute de confidentialité.

Conclusion Générale et Perspectives

Au terme de ce projet, et compte tenu de tout ce qui précède, force est de constater que les problèmesqui ont été soulevés au départ à savoir entre autres le travail en ligne de commande, la sauvegarde auto-matique des fichiers de configuration, la gestion des alarmes, ont pu être résolu. A travers cet outil, TunisieTelecom fera une gestion efficace de son réseau ATM Nortel et se démarquer encore de la concurrence enterme d’offre et de qualité de service.

En effet, durant ce stage, nous avons pu développer au travers d’une étude des besoins et d’uneconception minutieuse, une application à savoir NMS ATMNortel qui permet l’exploitation, la supervisionet la maintenance du réseau ATM Nortel de Tunisie Telecom. Il nous a aussi permis de conforter lesconnaissances déjà assimiler et d’acquérir de nouvelles compétences dans le domaine professionnelle et letravail en équipe.

Ce projet nous a aussi permis l’apprentissage de nouvelles techniques d’analyse et de conception ;d’utiliser et de perfectionner l’exploitation d’une nouvelle plateforme de développement, de nouveauxlogiciels. Il nous a permis de faire le lien entre la formation académique et l’activité professionnelle, d’oùl’acquisition de nouveaux réflexes et d’une certaine expérience du travail sur le terrain, grands avantagesapporté par ce stage.

Ce travail, qui ne consiste pas une fin en soi, pourrait être complété de plusieurs manières. Des modulespeuvent être ajoutés à savoir le dessin dynamique de la topologie du réseau, l’interconnexion avec d’autresapplications déjà existant au sein de Tunisie Telecom, à titre d’exemple le Backbone Workflow.

Le travail accompli durant ce stage nous a permis d’affronter certaines contraintes, difficultés qui onttrait au monde du travail et des pressions qui peuvent en découler. En effet, en entreprise les objectifsdoivent être atteints au cours du temps imparti, l’efficace et la performance doivent être de mise, ainsiqu’un soupçon de zèle. Mais cela n’enlève rien au fait que ces quelques mois d’apprentissage même si ilsn’ont pas été toujours très faciles, nous ont permis d’ouvrir une fenêtre sur notre avenir dans le mondeprofessionnelle. C’est avec optimisme que je me prépare à affronter la nouvelle vie qui s’ouvre devant moi.Puisse ALLAH, dans sa clémence et dans sa grande miséricorde guide mes pas sur le chemin de l’honneuret de la dignité et me préserver des dangers d’ici-bas et dans l’au-delà Amen.

58

Annexe A

L’ATM

Présentation Générale

ATM (Asynchronous Transfert Mode) est un standard de télécommunications proposé pour la réa-lisation du RNIS Large Bande (B-ISDN). Il a été développé par le CNET (Centre Nationale Etude etde Télécommunication) à partir d 1982 sous le nom d’ATD (Asynchronous Time Division). C’est uneamélioration de la commutation de paquets permettant de mieux exploiter les liens à haut débit et des’adapter aux exigences de nouvelles applications.

Plusieurs raisons ont poussé l’ITU (International Telecommunication Union) à choisir l’ATM. Ellessont entre autres [2] :

– Les équipements des réseaux de transmission sont conçus pour transportés de la voix (4 KHZ) ou desdonnées (64 Kbits/s), ces réseaux sont inflexibles face au nombre croissant de demande nouveauxservices ;

– Les réseaux sont traditionnellement conçus pour le service téléphonique et sont aussi utilisés àd’autres fins, comme l’internet. Ces réseaux utilisent la commutation de circuit. Une fois qu’uncircuit est établi entre deux interlocuteurs, la bande passante du circuit est exclusivement utiliséepar ces derniers. La possibilité que les deux interlocuteurs n’utilisent pas toute la bande passanteconstitue un gaspillage des capacités du réseau. En effet, les communications client-serveur ne sontpas constantes et sont de nature explosive (Bursty Communication), séparées par des silences. Cesréseaux sont inefficaces car les temps de silence constituent un gaspillage de bande passante .

– La dépendance vis-à-vis d’un service particulier est un handicap pour ces réseaux. En effet, lesréseaux téléphoniques, conçus pour véhiculer les signaux de parole, ne sont pas convenable pour leservice de données.

ATM a pour objectifs de couvrir les inconvénients cité ci-dessus sans pour autant changer fondamentale-ment l’infrastructure existante.

ATM combine les avantages de commutation de circuit avec ceux de la commutation par paquets.Comme dans le cas de X.25 et Frame Relay, ATM ne définit que l’interface entre l’équipement client et leréseau. ATM possède les caractéristiques de la commutation par paquets dans le sens où, chaque cellulecontient dans son en-tête un champ identifiant la connexion. Comme dans le mode de commutation parpaquets, ATM supporte les communications à débit variable et bénéficie d’une certaine flexibilité dansl’attribution du débit aux connexions.

L’ATM permet de transporter à la fois voix, vidéo et données à des hauts débits (51, 155 et 650 Mbpsetc) et cela sur de grandes distances.

Le choix de transmettre les données par petits lots de taille fixe est une caractéristique essentielled’ATM, c’est le principe qui permet d’augmenter de façon importante les débits. En effet, cette petite

59

ANNEXE A. L’ATM 60

taille permet de réduire énormément les temps de transit. ATM subdivise les données en unités appeléescellules. Chaque cellule a 53 octets : 5 pour l’information d’en-tête et 48 pour les données proprementdites. Le choix de 48 octets pour les données est un compromis entre les européens qui voulaient 32 octetset les américains 64 octets.

Figure A.1 – Format d’une cellule ATM

La cellule contient dans son en-tête, des informations relatives au routage. Ces informations s’appuientsur les notions de canal virtuel et de conduit virtuel.

A.1 L’adressage dans le réseau ATM

La notion de canal virtuel ou VC (Virtual Channel) est un concept associé au transfert unidirectionnelde cellules qui possèdent un identificateur commun unique. À chaque canal virtuel, on attache un numéroappelé identificateur de canal virtuel ou VCI (Virtual Channel Identifier) qui figure dans l’en-tête de lacellule.

Un groupe de canaux virtuels partageant un identificateur commun définit un conduit virtuel ou VP(Virtual Path). Chaque conduit virtuel est représenté par un numéro unique appelé identificateur deconduit virtuel ou VPI (Virtual Path Identifier).

Figure A.2 – La double identification d’ATM

Les cellules traversent les réseaux ATM par des commutateurs ATM, qui analysent l’en-tête et dirigentla cellule vers l’interface appropriée, assurant la connexion vers le commutateur suivant. Ainsi la celluleparvient à destination.

L’ATM supporte des liaisons point à point, ou point à multipoint, il comporte trois couches dont lesfonctions essentielles sont (figure 2.3) :

– assurer l’adaptation des cellules au système de transport physique utilisé (couche physique),– effectuer la commutation et le multiplexage des cellules (couche ATM à proprement parler),– adapter les unités de données (segmentation et réassemblage) des protocoles supérieurs à la coucheATM (couche AAL, ATM Adaptation Layer) et mettre en place des mécanismes spécifiques à chaquetype de données transportées.


Figure A.3 – Architecture ATM, [Servin :2003]

La couche AAL (ATM Adaptation Layer) est dépendante du service de couches hautes. C’est donc unecouche d’adaptation aux services de couches hautes ULP (Upper Layer Protocols) et présente différentsprotocoles d’adaptation pour les différents services des couches ULP.

La couche AAL1 permet un transfert isochrone par émulation de circuits, elle offre un service à débitconstant (CBR, Constant Bit Rate). L’AAL1, conçu essentiellement pour les trafics de type isochronenon compressé, n’offre qu’un service CBR (Constant Bit Rate). Elle n’utilise pas les possibilités dumultiplexage par étiquette et monopolise inutilement des ressources réseau (émulation de circuit). Lacouche AAL2 diffère essentiellement de l’AAL1 par la possibilité du débit variable (VBR, Variable BitRate).

L’AAL2, spécifique au trafic isochrone compressé (service VBR), assure la synchronisation des extré-mités et offre une référence temporelle. L’AAL5 est utilisé dans le cas où la couche ULP concerneraitl’entité TCP/IP.

A.2 La couche Physique

La couche Physique est chargée de la transmission et de la réception du flot de bits sur le support,elle réalise les fonctions de codage, de l’alignement, la synchronisation bit, la signalisation, l’adaptationélectrique ou opto-électrique au support.

Les différents types de connexion conduisent à la définition de deux interfaces. On introduit l’inter-face NNI (Node Network Interface) lorsque la cellule transite entre deux nœuds de commutation.L’interface UNI (User Network Interface) raccorde un utilisateur et un nœud de commutation.

Les commutateurs ATM utilisent certains champs de l’en-tête de cellule pour identifier le segment deréseau suivant par lequel une cellule doit passer jusqu’à sa destination finale. Le commutateur reçoit descellules sur un port et les commute vers le port de sortie approprié, d’après les informations contenuesdans ces champs. Cette opération obéit à une table de commutation qui établit la correspondance entreles ports d’entrée et les ports de sortie, en se basant sur les valeurs des champs. Quand une stationd’extrémité ATM se connecte au réseau ATM, elle donne son accord sur les valeurs suivantes :

– bande passante en point de bande– bande passante continue moyenne– taille du trafic en rafale.

Les commutateurs ATM peuvent utiliser des mécanismes de réglementation du trafic pour imposer ceslimites. S’il constate que le trafic s’éloigne des paramètres convenus, le commutateur peut décider que cetrafic pourra être ignoré en cas de saturation du réseau.


A.3 La qualité de service QoS

ATM a pour vocation de transporter la voix, la vidéo, les données. . . Chacun de ces domaines demandedes contraintes différentes : la vidéo et la voix des délais faibles et une vitesse constante, l’interconnexion deRéseaux Locaux des débits élevés mais des temps élastiques, le transfert de données des temps élastiqueset des débits corrects ponctuellement,. . . De plus, les taux d’erreurs doivent être beaucoup plus bas pourla transmission de données informatiques que pour celle de voix ou de vidéo. ATM prévoit 5 classesde services pour permettre l’intégration des différents types de trafic et répondre aux exigences desapplications en termes de QoS.

1. 1. CBR (Continuous Bit Rate) : Trafic à débit fixe avec des contraintes temporelles. Permet de fairede l’émulation de circuit, parfait pour la vidéo.

2. VBR – RT (Variable Bit Rate – Real Time) : Trafic de débit variable avec contraintes temporelles.Tolère de petites variations de délais, convient à la voix ou à la vidéo compressée.

3. VBR – NRT (Variable Bit Rate – Non Real Time) : Trafic de débit variable sans contrainte tem-porelle. On négocie un débit moyen assuré. Idéal pour interconnecter des Frame Relay ou il fautgarantir le CIR (Commited Information Rate) ou débit moyen garanti.

4. ABR (Available Bit Rate) : Trafic de débit variable sans contrainte temporelle. On garantit option-nellement un minimum de débit mais pas de bande passante permanent. Convient à l’interconnexiondes Réseaux Locaux.

5. UBR (Unspecified Bit Rate) : Aucune garantie de service. Peut correspondre au transfert de données.

A.4 La signalisation et le routage

La signalisation ATM est relativement complexe, ceci est dû principalement à la prise en compte deplusieurs éléments notamment la qualité de service (QoS). De type CCS (Common Channel Signaling)ou signalisation par canal sémaphore, elle diffère selon que l’on se situe à l’interface usager d’un réseaupublic ou privé, à l’interface entre deux réseaux privés ou publics.

Figure A.4 – La signalisation dans ATM

À l’interface usager (UNI, User Network Interface) ou entre réseaux (NNI, Network to Network In-terface) une signalisation de type canal sémaphore (PVC 0/5) utilise le protocole Q.2931. Les réseauxpublics utilisent la signalisation définie pour le RNIS, SS7 (Signaling System 7) ou CCIT N◦ 7. En interne,les réseaux privés utilisent PNNI (Private Network to Network Interface) qui autorise l’établissement deSVC et assure un routage en fonction de la qualité de service. Précédemment IISP (Interim Inter SwitchProtocol) ne permettait qu’une configuration statique du réseau, ce qui le réservait aux petits réseaux.

Le protocole de routage utilisé est le routage PNNI. PNNI est un protocole de routage du typeétat des liens (link status). Pour établir un SVC répondant à la QoS exigée, chaque commutateur doitavoir connaissance de la topologie du réseau et des caractéristiques de trafic disponibles sur les différentscommutateurs du réseau :


– Débit disponible (Available Cell Rate).– Délai de transfert (Maximum Cell Transfer Delay).– Variation du délai de transfert ou gigue (Cell Delay Variation).– Taux de perte de cellules (Cell Loss Ratio).– Débit maximal admissible (Maximum Cell Rate).

Conclusion

Autorisant un partage optimal de la bande passante, l’ATM est aujourd’hui le protocole de cœur deréseau utilisé par la majorité des opérateurs. Outre l’aspect performance, l’ATM permet de garantir auxutilisateurs une certaine qualité de service de bout en bout.

Annexe B

Frame Relay

Présentation Générale

Frame Relay est un protocole de réseau étendu qui intervient dans les couches physique et liaison dedonnées du modèle de référence OSI.

Inventé par Eric Scace, ingénieur chez Sprint International, ce protocole était destiné aux interfacesRNIS (Réseaux Numériques à Intégration de Services), en tant que version simplifiée du protocole X.25.De nos jours, bien d’autres interfaces réseau l’utilisent également. Dans la première mise en œuvre duprotocole Frame Relay dans son réseau public, Sprint utilisa des commutateurs StrataCom. La reprise deStrataCom par Cisco en 1996 marqua leur entrée sur le marché des opérateurs.

Actuellement, les fournisseurs d’accès aux réseaux utilisent généralement le protocole Frame Relaycomme technique d’encapsulation de signaux vocaux et numériques, dans les transmissions entre réseauxlocaux par le biais d’un réseau étendu. Chaque utilisateur final obtient une ligne privée (ou louée) connec-tée à un nœud du réseau Frame Relay. Dans ce réseau, le chemin par lequel s’effectue la transmissionchange fréquemment, et ce de manière transparente pour tous les utilisateurs finaux.

Frame Relay est devenu l’un des protocoles de réseau étendu les plus répandus, principalement grâceà son faible coût par rapport aux lignes dédiées. De plus, la configuration de l’équipement des utilisateursdans un réseau Frame Relay est très simple. Les connexions Frame Relay sont établies en configurantles routeurs de l’équipement d’abonné ou d’autres équipements pour qu’ils communiquent avec le com-mutateur Frame Relay d’un fournisseur de services. Le fournisseur de services configure le commutateurFrame Relay de manière à limiter au maximum les tâches de configuration au niveau de l’utilisateurfinal. Frame Relay est devenu le protocole de réseau étendu le plus utilisé au monde. Son succès dans lesgrandes entreprises, les gouvernements, les FAI (Fournisseur d’Accès Internet) et les petites entreprisesest essentiellement dû à son prix abordable et à sa flexibilité. Frame Relay permet de réduire le coût desréseaux par un niveau de complexité moins élevé, par des exigences en équipement plus faibles et par unemise en œuvre plus simple. En outre, sa bande passante, sa fiabilité et sa résilience sont bien meilleuresque celles des lignes privées ou louées. Dans la mondialisation actuelle qui entraîne une évolution vers destopologies à plusieurs filiales, le protocole Frame Relay permet de réaliser des architectures réseau plussimples avec un coût total de possession minimal.

B.1 Circuits virtuels

La connexion entre un équipement terminal de traitement de données (ETTD) et un équipementde communication de données (DCE) comprend un composant de couche physique et un composant decouche liaison de données.

64

ANNEXE B. FRAME RELAY 65

– Le composant physique définit les caractéristiques mécaniques, électriques, fonctionnelles et métho-dologiques de la connexion entre les équipements en question. L’une des spécifications d’interfacede couche physique les plus répandues est la norme RS-232.

– Le composant de couche liaison définit le protocole qui établit la connexion entre l’ETTD, tel qu’unrouteur, et le DCE, tel qu’un commutateur.

Lorsque des opérateurs se servent de Frame Relay pour interconnecter des réseaux locaux, l’ETTD surchacun de ces réseaux est un routeur. Une connexion série, telle qu’une ligne louée T1/E1, connectele routeur à un commutateur Frame Relay au niveau du point de présence (POP) le plus proche del’opérateur. Le commutateur Frame Relay est un équipement DCE. Les commutateurs font passer lestrames d’un ETTD dans le réseau et les fournissent aux autres ETTD par le biais d’équipements DCE.L’équipement informatique qui n’est pas connecté à un réseau local peut également envoyer des donnéesdans un réseau Frame Relay. (Figure B.1)

Figure B.1 – Représentation basique Frame Relay

Le terme circuit virtuel désigne la connexion entre deux ETTD par un réseau Frame Relay. De telscircuits sont virtuels du fait qu’il n’existe aucune liaison électrique directe entre leurs extrémités. Laconnexion est dite logique et les données circulent d’une extrémité à l’autre sans circuit électrique lesreliant directement. Grâce aux circuits virtuels, Frame Relay partage la bande passante entre plusieursutilisateurs. Un site quelconque peut donc communiquer avec n’importe quel autre site sans utiliserplusieurs lignes physiques dédiées.

Les circuits virtuels permettent une communication bidirectionnelle entre les équipements. Les cir-cuits virtuels sont identifiés par des indicateurs de connexion de liaison de données (DLCI, Data LinkConnection Identifier). Ces indicateurs DLCI sont généralement attribués par le fournisseur de servicesFrame Relay (par exemple, Tunisie Telecom). Les DLCI Frame Relay ont une signification locale. End’autres termes, ces valeurs ne sont pas uniques dans le réseau étendu Frame Relay. Un indicateur DLCIidentifie un circuit virtuel sur un équipement situé à une extrémité. Au-delà de la liaison, ce DLCI n’aaucune signification. Deux équipements reliés par un circuit virtuel peuvent utiliser une valeur DLCIdifférente pour désigner la même connexion.

Le réseau Frame Relay est statistiquement multiplexé. En d’autres termes, il ne transmet qu’unetrame à la fois, mais un grand nombre de connexions logiques peuvent coexister sur une même lignephysique. L’équipement d’accès Frame Relay (FRAD, Frame Relay Access Device) ou le routeur connectéau réseau Frame Relay peut être connecté à plusieurs périphériques finaux par différents circuits virtuels.Les différents circuits virtuels d’une même ligne physique sont distincts du fait qu’ils sont identifiés parleur propre DLCI. Le DLCI n’a qu’une signification locale et peut différer à chaque extrémité d’un circuitvirtuel.


Figure B.2 – Identification des liens logiques par le DLCI

Frame Relay prélève des paquets de données d’un protocole de couche réseau, tel que IP ou IPX, lesencapsule en tant que données d’une trame Frame Relay, puis passe cette trame à la couche physiquepour la transmettre au câble.

B.2 Le contrôle d’admission

La simplification du protocole a conduit à la suppression de tout contrôle de flux dans le réseauet à fragiliser celui-ci face aux problèmes de congestion. Aussi, toute nouvelle connexion ne doit êtreacceptée que si le réseau est apte à la satisfaire sans préjudice pour les connexions déjà établies. Dans lesréseaux de type X.25, le contrôle d’admission est effectué à l’établissement du circuit : dans chaque nœudsont réservées les ressources nécessaires au traitement des données (buffer), si il n’y a plus de ressourcesdisponibles la connexion est refusée. Cependant, la réservation statique des ressources est incompatibleavec l’admission d’un trafic en rafale qui rend le dimensionnement du réseau difficile. En Frame Relay,toute demande de connexion est accompagnée d’un descripteur de trafic définissant en particulier le débitmoyen et le débit de pointe demandé [4]. Un contrat de trafic est passé entre la source et le réseau ; ilcomporte trois paramètres :

– Le CIR (Committed Information Rate) ou débit moyen garanti. Le CIR caractérise le débit moyencontractuel que doit garantir le réseau. La connexion ne sera acceptée que si la somme des CIR surle lien (ou sur le nœud) ne dépasse pas le débit maximal du lien (ou la capacité de traitement dunœud).

– L’EIR (Excess Information Rate) ou surdébit autorisé au-dessus duquel tout bloc de données soumisau réseau est détruit ;

– Le temps d’analyse du trafic (Tc).Le CIR définit le volume moyen admis dans le réseau ou Bc (Committed Burst Size) tel que Bc = CIR• Tc. L’EIR précise le volume maximal autorisé tel que Bc + Be = (CIR + EIR) • Tc où Be (ExcessBurst size) représente le volume excédentaire admis au-dessus du contrat Bc. Si le volume du traficsoumis est inférieur à Bc tout le trafic soumis est transmis par le réseau. Si le volume de trafic soumis estcompris dans l’intervalle ]Bc... Be] les blocs de données sont transmis mais marqués (Cell Tagging). Lorsde l’éventuelle traversée d’un nœud congestionné ces blocs seront éliminés. Les blocs transmis au-dessusde Be seront systématiquement éliminés. (Figure B.3)


Figure B.3 – Contrôle de gestion dans les réseaux haut débit

Les blocs 1 et 2 sont transmis normalement, à partir du bloc 3 le volume moyen garanti pour l’intervallede temps T est dépassé, le bloc 3 et les suivants seront marqués comme dépassant le trafic moyen. Lesblocs marqués (bit DE, Discard Eligibility) seront transmis, ils ne seront éliminés que s’ils traversent unnœud en état de congestion. Les blocs 6 et 7 excèdent le volume maximal autorisé, ils seront éliminés.

L’élimination des blocs en excès n’est pas une solution satisfaisante. Il est préférable d’avertir lesentités communicantes de l’état de congestion afin que, par autodiscipline, les sources ralentissent leurémission. Ce principe est illustré par la figure B.4.

Figure B.4 – Contrôle de gestion dans les réseaux haut débit

Lorsqu’un bloc de données traverse un nœud en état de congestion, celui-ci positionne un bit pouravertir le destinataire d’un état de congestion en avant de la source (FECN, Forward Explicit CongestionNotification) et que des données ont pu être éliminées. Cette indication est transmise aux couches supé-rieures afin que celles-ci mettent en œuvre un mécanisme de contrôle de flux. Le destinataire profiterades données en réponse pour avertir la source que le circuit qui le dessert (circuit aval) est congestionné(BECN, Backward Explicit Congestion Notification).

Ce mécanisme n’est pas très efficace, car, l’équipement d’accès n’a pas toujours la faculté de réduirevolontairement son flux d’émission. C’est notamment le cas d’un routeur interconnectant un réseau local.De plus, il suppose un trafic bidirectionnel ce qui peut introduire une inefficacité complète du système ou,du moins, une certaine inertie. Ce procédé est injuste. En effet, tous les hôtes dont les données transitentpar le nœud congestionné sont invités à réduire leur trafic, même ceux qui ne sont pas responsables de


cet état de fait. Pour y remédier un protocole spécifique a été développé : le CLLM ou Consolited LinkLayer Management.

Le protocole CLLMLe protocole CLLM (origine ANSI T1 606) permet à tout nœud en état de congestion d’en avertir

ses voisins et la source [4]. Le message CLLM (Consolided Link Layer Management) contient la liste desvoies logiques congestionnées et la cause de cette congestion.

Le protocole LMI (Local Management Interface)La LMI est essentiellement un mécanisme de test d’activité qui fournit des informations sur les

connexions Frame Relay entre le routeur (ETTD) et le commutateur Frame Relay (DCE). Environ toutesles 10 secondes, le périphérique final interroge le réseau pour obtenir soit une simple séquence de réponses,soit des informations sur l’état des canaux. Si le réseau ne fournit pas les informations demandées, le pé-riphérique utilisateur peut considérer que la connexion est coupée. Si le réseau fournit une réponse à lademande FULL STATUS, cette réponse comprend des informations d’état sur les DLCI attribués à laligne en question. Le périphérique final peut utiliser ces informations pour déterminer si les connexionslogiques sont capables de relayer les données. Le protocole LMI (Local Management Interface) permet àl’utilisateur (FRAD, Frame Relay Access Device) de connaître à tout instant :

– L’état de ses circuits virtuels permanents (Virtual Circuit Status) par l’échange de messages ques-tions (Status Enquiry, demande de statut) et de messages réponses (Status, état du lien).

– L’état du lien physique (Link Status) par échange de messages numérotés (Keep Alive)– La modification du statut d’un lien (DLCI) sur l’initiative du réseau (messages asynchrones).

Figure B.5 – Echange de message synchrone sur l’état des liens

Conclusion

Indépendamment des progrès technologiques réalisés dans les commutateurs, le gain de performanceobtenu avec le relais de trames résulte de la simplification du protocole et de la suppression de contrôlesredondants. Le gain en vitesse de commutation du relais de trames par rapport à X.25 est de l’ordre de 5à 10. Particulièrement adapté à l’interconnexion des systèmes exigeants en débit et générant des traficssporadiques (réseaux locaux, applications client/serveur), il a été adapté au transport des flux isochronescomme la voix.

Bibliographie

[1] Hassan Gomaa : Designing Concurrent, Distributed, And Real-

Time Applications with UML. Addison-Wesley, 2000.

[2] Salem Hasnaoui : Réseaux Industriels et de Télécommunica-

tions. Centre de Publication Universitaire, 2003.

[3] Pascal Roques : UML2 Modéliser une application web. Ey-

rolles, 4ème edition édition, 2008.

[4] Claude Servin : Réseaux et Télécoms. Dunod, 2003.

69

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

Engineering

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