Gestion Reseaux v2.03

Gestion de rseaux et services
Une introduction
Daniel Ranc
INT-LOR-GRS-v2.03
Gestion de rseaux et services, une introduction
Rsum
La gestion de rseaux est un domaine qui, auparavant, se focalisait
principalement sur des activits techniques de maintenance du rseau.
Aujourdhui, la gestion des rseaux ne peut plus tre envisage sans
son insertion dans lensemble des activits de loprateur. Cest ce que
tente de montrer cet ouvrage dintroduction qui se propose demprunter
un chemin passant par les fondamentaux conceptuels du TMN
(Telecommunications Management Network), ltude de larchitecture
TINA et la contribution de CORBA.
TINA a reprsent lavnement des architectures de services rseaux.
Une vision intgratrice supplmentaire nous est maintenant propose
par larchitecture NGOSS du consortium TeleManagement Forum1. Il
sagit dune analyse base sur les processus opratoires (business
processes) de loprateur proposant une architecture globale incluant la
libralisation conomique du secteur des TIC.
La gestion des rseaux et services met en jeu des systmes
informatiques parmi les plus sophistiqus jamais raliss. Lambition de
ce document est de sensibiliser le lecteur la problmatique des
systmes informatiques complexes ainsi qu leur architecture.
Daniel Ranc
INT 2004
Dont lINT fait partie.
INT-LOR-GRS-v2.03
INT 2004
INT-LOR-GRS-v2.03
Sur ce document
Lauteur
Daniel Ranc sintresse au domaine de la gestion des rseaux et
services depuis les annes 90. Il est enseignant-chercheur lINT
depuis 1998. Auparavant, au sein dAlcatel Research & Development, il
a contribu de nombreux projets ESPRIT et IST.
Ces activits ont continu de plus belle lINT o une quipe
comptente a t constitue, laquelle a livr des rsultats remarquables
notamment dans le domaine des modles dinformation au niveau
gestion des Services.
Contributeurs
Ce document naurait pu exister sans le travail de fond de ltudiant
Anas Kabbaj de lINPT de Rabat, dont le trop bref sjour lINT a
nanmoins permis ce document de prendre racine.
Versions
1.0: version initiale

1.2: remodelage, ajout frame et TINA
2.0: remodelage, ajout TMF
2.01: finitions
2.03: rfrencement INT
Rfrences du document
Interne: INT-LOR-GRS-v2.03
ISBN: en cours
Remerciements
Les figures du chapitre 8 par courtoisie du
INT 2004
INT-LOR-GRS-v2.03
Rfrences
Documents concerns ou cits

[1] ITU-T Recommendation M.3010 (2000): "Principles for a telecommunications
management network".
[2] 3GPP TS 22.101: "Service aspects; Service Principles".
[3] 3GPP TS 32.111-1: " Telecommunication management; Fault Management;
Part 1: 3G fault management requirements".
[4] IETF RFC 959: "File Transfer Protocol (FTP)"; October 1985, J. Postel, J.
Reynolds, ISI.
(Status: Standard).
[5] IETF RFC 783: "Trivial File Transfer Protocol (TFTP)"; rev. 2, June 1981, K.R.
Sollins MIT.
(Status: Unknown).
[6] IETF RFC 1157: "Simple Network Management Protocol (SNMP)": May 1990,
J. Case, SNMP Research, M. Fedor, Performance Systems International, M.
Schoffstall, Performance Systems International, J. Davin, MIT Laboratory for
Computer Science. (Status: Standard).
[7] IETF RFC 2401: "Security Architecture for the Internet Protocol"; November
1998. (Status: Proposed Standard).
[8] The Object Management Group (OMG) "The Common Object Request Broker:
Architecture and Specification", Revision 2.3, June 1999.
http://www.omg.org/technology/documents/vault.htm#CORBA_IIOP
[9] ITU-T Recommendation Q.811 (1997): "Lower Layer Protocol Profiles for the
Q3 Interface and X interfaces".
[10] ITU-T Recommendation Q.812 (1997): "Upper Layer Protocol Profiles for the
Q3 Interface and X interfaces".
[11] ITU-T Recommendation X.650 (1996): "Information Technology - Open
Systems Interconnection Basic Reference Model: Naming and Addressing".
[12] ITU-T Recommendation X.700 (1992): "Management Framework for Open
Systems Interconnection (OSI) for CCITT applications".
[13] ISO 8571-1 (1988): "Information Processing Systems - Open Systems
Interconnection - File Transfer, Access and Management - Part 1: General
Introduction".
Interconnection - File Transfer, Access and Management - Part 2: Virtual Filestore
Definition".
Interconnection - File Transfer, Access and Management - Part 3: File Service
Definition".
Interconnection - File Transfer, Access and Management - Part 4: File Protocol
Specification".
[17] ISO/IEC ISP 10607-1 (1995): "Information technology - International
Standardized Profiles
AFTnn - File Transfer, Access and Management - Part 1: Specification of ACSE,
Presentation and Session Protocols for the use by FTAM".
Standardized Profiles AFTnn - File Transfer, Access and Management - Part 2:
Definition of Document Types, Constraint sets and Syntaxes".
INT 2004
INT-LOR-GRS-v2.03

Standardized Profiles AFTnn - File Transfer, Access and Management - Part 3:
AFT 11 - Simple File Transfer Service (Unstructured)".
[20] ITU-T Recommendation X.710 (1997): "Information Technology Open
Systems
Interconnection - Common Management Information Service".
[21] ITU-T Recommendation X.711 (1997): "Managed objects for diagnostic
information of public switched telephone network connected V-series modem
DCE's".
[22] ITU-T Recommendation X.25 (1996): "Interface between Data Terminal
Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals
operating in the Packet Mode and connected to Public Data Networks by
Dedicated Circuit".
Standardized Profiles AOM1n.OSI Management - Management Communications Part 1: Specification of ACSE, presentation and session protocols for the use by
ROSE and CMISE".
[24] ISO/IEC 9545:1994: "Information technology - Open Systems Interconnection
- Application Layer Structure".
Systems Interconnection - Basic Reference Model: The Basic Model".
[26] ITU-T Recommendation X.208 (1988): "Specification of Abstract Syntax
Notation One (ASN.1)".
[27] ITU-T Recommendation X.209 (1988): "Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)".
Systems
Interconnection - Basic Reference Model: Conventions for the definition of OSI
Services".
Systems
Interconnection - Physical Service Definition".
Systems
Interconnection - Data link Service Definition".
Systems
Interconnection - Network Service Definition".
[32] ITU-T Recommendation X.223 (1993): "Use of X.25 to provide the OSI
Connection-mode network service for ITU-T applications".
Systems
Interconnection - Transport Service Definition".
Systems
Interconnection - Protocol for providing the connection-mode transport service".
Systems
Interconnection - Session Service Definition".
Systems
Interconnection - Connection-oriented session protocol: Protocol specification".
Systems
Interconnection - Presentation Service Definition".
Systems
Interconnection - Connection-oriented presentation protocol: Protocol
specification".
INT 2004
INT-LOR-GRS-v2.03

Systems
Interconnection - Service definition for the association control service element".
Systems
Interconnection - Connection-oriented protocol for the association control service
element: Protocol specification".
[41] ITU-T Recommendation X.219 (1988): "Remote Operations: Model, Notation
and Service Definition".
[42] ITU-T Recommendation X.229 (1988): "Remote Operations: Protocol
Specification".
[43] ISO/IEC 7776 (1995): "Information technology - Telecommunications and
information exchange between systems - High-level data link control procedures Description of the X.25
LAPB-compatible DTE data link procedures".
[44] ISO/IEC 8208 (2000): "Information technology - Data communications - X.25
Packet Layer Protocol for Data Terminal Equipment".
[45] ISO/IEC 8878 (1992): "Information technology - Telecommunications and
information exchange between systems - Use of X.25 to provide the OSI
Connection-mode Network Service".
[46] IETF RFC 1006: "ISO Transport on top of the TCP", Marshall T. Rose, Dwight
E. Cass, Northrop Research and Technology Center, May 1987. Status: Standard.
[47] IETF RFC 793: "Transmission Control Protocol (TCP)", September 1981.
Status: Standard.
[48] IETF RFC 791: "Internet Protocol (IP)", September 1981. Status: Standard.
[49] ITU-T Recommendation X.680 (2002): "Information Technology-Abstract
Syntax Notation One (ASN.1): Specification of Basic Notation".
[50] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[51] 3GPP TS 22.115: "Service aspects; Charging and Billing".
[52] The Object Management Group (OMG) "The Common Object Request
Broker: Architecture and Specification", Revision 2.1, August 1997.
http://www.omg.org/technology/documents/vault.htm#CORBA_IIOP
[53] 3GPP TS 32.400-series: "Telecommunication management; Performance
Management (PM); Concept and requirements".
[54] 3GPP TS 32.600: "Telecommunication management; Configuration
Management (CM); Concept and high-level requirements".
[55] 3GPP TS 32.200: "Telecommunication management; Charging management;
Charging principles".
[100] TMF GB910: "Telecom Operations Map"; Approved Version 2.1 March 2000,
(may be downloaded from http://www.tmforum.org.).
[101] 3GPP TS 32.102: "3G Telecom Management Architecture".
[102] ITU-T Recommendation M.3013 (2000): "Considerations for a
telecommunications management network".
[104] 3GPP TR 21.801: "Specification Drafting Rules".
[105] TMF GB910B: "Telecom Operations Map Application Note-Mobile Services:
Performance Management and Mobile Network Fraud and Roaming Agreement
Management"; Public Evaluation Version 1.1, September 2000. (May be
downloaded free from http://www.tmforum.org.)
[CAJB]: Jean-Marie CHAUVET "Corba ActiveX et Java Beans" - Paris: Eyrolles,
septembre 1997.
[FUE 95] : L. A. de la fuente, J. Pavon, M. Wakano, "The TINA-C Management
Architecture", Octobre 1995
[G.803]: ITU-T Rec. G.803, Architecture des rseaux de transport hirarchie
numrique synchrone, Mars 1993.
[GRA 95]: P. Graubmann TINA-C Deliverable, "Engineering Modeling Concepts
(DPE Architecure)", Dec 95.
[IMTCDE]: Manuel-Juan Simon de la Horra, "Implmentation of a management
TMN agent in a Corba distributed environment".
[ISO 9596]: ISO/IEC 9596: Common Management Information Protocol Definition,
1991.
INT 2004
INT-LOR-GRS-v2.03
[ISO 10165-1]: ISO 10165-1/ITU-T X.720: Management Information Model, 1993.

[ISO 10165-4]: ISO 10165-4/ITU-T X.722: Guidelines for the Definition of Managed
Objects, 1993.
[M.3010]: ITU-T Rec. M.3010, Principes pour un rseau de gestion des
tlcommunications, 1993.
[M.3100]: ITU-T Rec. M.3100, Modle informationnel gnrique de rseau de
gestion des tlcommunications, 1993.
[ODP 96]: ISO/IEC IS 10746-1 - ITU-T Rec. X901, ODP Reference Model Part 1.
Overview and Guide to Use, May 1996.
[OMG]: http://www.omg.org
[PRI 93]: RACE Project 2041 PRISM. Service Management Reference
Configuration, RACE, Sept 1993.
[Q.811]: ITU-T Rec. Q.811, Profils des protocoles de couche infrieure pour
l'interface Q3, 1993.
[Q.812]: ITU-T Rec. Q.812, Profils des protocoles de couche suprieure pour
l'interface Q3, 1993.
[Q.12xx]: ITU-T Rec. Q120x, Q121x, Q122x: The Intelligent Network, 1993.
[RUB 94]: H. Rubin, N. Natarajan, "A Distributed Software Architecture for
Telecommunication Networks", IEEE Network, Jan-Fv 1994.
[RUM 91]: J.Rumbaugh Object Oriented Modeling and Design. Prentice Hall:
Engelwood Cliffs, N.J. 1991.
[Waldbusser 91]: S Waldbusser."Remote Network Monitoring Management
Information Base", RFC 1271, novembre 1991.
[X730]: ITU-T Rec.X.730/ISO 10164-1 Gestion des objets, 1993.
[X731]: ITU-T Rec.X.731/ISO 10164-2 Gestion des attributs d'tats, 1993.
[X732]: ITU-T Rec.X.732/ISO 10164-3 Gestion des attributs de relations, 1993.
[X733]: ITU-T Rec.X.733/ISO 10164-4 Gestion des rapports d'alarme, 1993.
[X734]: ITU-T Rec.X.734/ISO 10164-5 Gestion des rapports d'vnements, 1993.
[X735]: ITU-T Rec.X.735/ISO 10164-6 Gestion des journaux, 1993.
[X736]: ITU-T Rec.X.736/ISO 10164-7 Gestion des rapports d'alarmes de scurit,
1993.
[X737]: ITU-T Rec.X.737/ISO 10164-14 Catgories de test de diagnostic et de
confiance, 1994.
[X738]: ITU-T Rec.X.738/ISO 10164-13 Gestion des synthses, 1994.
[X739]: ITU-T Rec.X.739/ISO 10164-11 supervision de la charge , 1994.
[X740]: ITU-T Rec.X.740/ISO 10164-8 Gestion des traces de vrification de la
scurit, 1993.
[X741]: ITU-T Rec.X.741/ISO 10164-9 Objets et attributs pour le contrle d'accs ,
1993.
[X742]: ITU-T Rec.X.742/ISO 10164-10 Gestion des mesures de cot, 1993.
[X745]: ITU-T Rec.X.745/ISO 10164-12 Gestion des tests, 1993.
INT 2004
INT-LOR-GRS-v2.03
Table des matires

Rsum ................................................................................................................................ a
Sur ce document ................................................................................................................. c
Lauteur...............................................................................................................................c
Contributeurs ......................................................................................................................c
Versions..............................................................................................................................c
Rfrences du document....................................................................................................c
Remerciements...................................................................................................................c
Rfrences........................................................................................................................... d
Documents concerns ou cits .......................................................................................... d
Table des matires .............................................................................................................. h
Figures et tableaux............................................................................................................... l
Abrviations ........................................................................................................................ n
Chapitre 1 Gestion des rseaux ...................................................................................... 1
Prsentation gnrale........................................................................................................ 1
Les disciplines de l'administration d'un systme............................................................. 1
Les architectures de l'administration des rseaux .......................................................... 2
Les fonctionnalits de l'administration des rseaux ........................................................ 4
Les critres pour une organisation logique ..................................................................... 4
Conclusion provisoire......................................................................................................... 6
Chapitre 2 - Comparaison gestion TMN vs. gestion SNMP .............................................. 7
Comparaison des modles informationnels TMN et IETF .................................................. 7
Le modle informationnel du TMN.................................................................................. 7
Modle informationnel de la communaut Internet ........................................................12
Structure de l'information de gestion (SMI)....................................................................12
La base d'information de gestion (MIB) .........................................................................14
La MIB RMON...............................................................................................................15
SNMPv2........................................................................................................................16
Modles architecturaux de gestion TMN - SNMP..............................................................17
Cadre architectural de la gestion TMN ..........................................................................17
Cadre architectural de la gestion SNMP........................................................................19
Comparaison des modles de communication TMN et IETF.............................................20
Le modle de communication du TMN ..........................................................................20
Le protocole CMIP.........................................................................................................22
Le protocole CMOT .......................................................................................................23
Le modle de communication de l'IETF ............................................................................24
Le protocole SNMP .......................................................................................................24
Le protocole SNMPv2 ...................................................................................................25
Chapitre 3 - Le modle fonctionnel de la gestion TMN....................................................27
Les aires fonctionelles ......................................................................................................27
Gestion de la configuration............................................................................................27
Gestion des fautes ........................................................................................................27
INT 2004
INT-LOR-GRS-v2.03
Gestion des performances ............................................................................................27

Gestion de la scurit....................................................................................................28
Gestion de la comptabilit .............................................................................................28
Les Fonctions de gestion systme ....................................................................................28
Conclusion........................................................................................................................32
Chapitre 4 - Larchitecture agent-manager.......................................................................33
Introduction.......................................................................................................................33
Les protocoles ..................................................................................................................33
La dynamicit ................................................................................................................33
Les requtes .................................................................................................................34
Structure de linformation ..................................................................................................35
Cas du TMN ..................................................................................................................35
Cas de SNMP ...............................................................................................................35
Le Frame ..........................................................................................................................35
Chapitre 5 - TMN, le rseau de gestion des tlcommunications...................................39
Introduction.......................................................................................................................39
Dfinition du TMN .............................................................................................................39
Fonctions de gestion offertes par le TMN..........................................................................40
Architecture du TMN .........................................................................................................41
Architecture informationnelle du TMN............................................................................41
Architecture fonctionnelle du TMN.................................................................................44
Architecture physique du TMN ......................................................................................49
Les interfaces................................................................................................................50
Exemple d'architecture physique de gestion d'un rseau priv virtuel large bande........50
Conclusion........................................................................................................................51
Chapitre 6 - TINA, larchitecture de rseau dinformation de tlcommunications .......53
Introduction.......................................................................................................................53
Prsentation des travaux TINA .........................................................................................54
Architecture TINA .............................................................................................................56
Architecture d'ensemble TINA .......................................................................................56
L'architecture de traitement ...........................................................................................58
Modlisation d'information dans TINA ...........................................................................59
Modlisation de traitement dans TINA...........................................................................61
Modlisation d'ingnierie dans TINA .............................................................................62
L'architecture de service ...................................................................................................64
La notion de session .....................................................................................................65
Les composants de service TINA ..................................................................................66
Le composant de service universel ...............................................................................67
L'architecture de gestion ...................................................................................................69
Les aires fonctionnelles de gestion................................................................................69
Les principes de gestion dans TINA-C ..........................................................................70
L'architecture de rseau....................................................................................................71
Prsentation du modle NRIM ......................................................................................71
Architecture de gestion des connexions TINA-C ...........................................................73
Conclusion........................................................................................................................75
INT 2004
INT-LOR-GRS-v2.03
Chapitre 7 - CORBA et la gestion des rseaux.................................................................77

Introduction.......................................................................................................................77
Survol de CORBA .........................................................................................................77
OMA, L'architecture globale de CORBA........................................................................77
Les services objet communs .........................................................................................79
Les interfaces de domaine ............................................................................................81
Le langage de description d'objets IDL .............................................................................82
De l'IDL aux langages de programmation......................................................................82
Le mode statique et le mode dynamique .......................................................................84
La syntaxe IDL ..............................................................................................................84
LORB: le bus d'objets rpartis CORBA ............................................................................85
Les composantes ..........................................................................................................86
L'ORB vu du ct client .................................................................................................87
L'ORB vu du ct serveur .............................................................................................88
Conclusion ....................................................................................................................90
CORBA dun point de vue gestion de rseaux ..................................................................90
Chapitre 8 - Larchitecture NGOSS du TeleManagement Forum.....................................91
Le consortium TMF ...........................................................................................................91
Le NGOSS........................................................................................................................91
Le eTOM...........................................................................................................................93
Le SID (Shared Information Data model) ..........................................................................95
Rle au sein du NGOSS ...............................................................................................96
Applications...................................................................................................................96
Conclusion ....................................................................................................................96
Linterface contractuelle et la TNA ....................................................................................96
Linterface contractuelle ................................................................................................97
La Technological Neutral Architecture...........................................................................97
La validation et la conformit ............................................................................................97
Le programme de conformit ........................................................................................97
Le programme de test ...................................................................................................97
En rsum ........................................................................................................................98
Conclusion..........................................................................................................................99
INT 2004
INT-LOR-GRS-v2.03
INT 2004
INT-LOR-GRS-v2.03
Figures et tableaux
Fig. 1.1: les modles dorganisation ...................................................................................... 3
Fig. 1.2: architecture centralise............................................................................................ 4
Fig. 2.2: larbre de nommage................................................................................................11
Fig. 2.3: la hirarchie denregistrement dans linternet..........................................................13
Fig. 2.4: larbre denregistrement de la MIB 2 .......................................................................15
Fig. 2.5: MIB RMON .............................................................................................................16
Fig. 2.6: Cadre architectural et gestion de composants rseau prconise par l'OSI............19
Fig. 2.7: Architecture pour la gestion de composants rseau prconise par l'IETF .............20
Fig. 2.8: Composition de CMISE ..........................................................................................23
Tableau 2.1: comparaison CMIP/SNMP ...............................................................................26
Fig. 3.1: Relations entre aires fonctionnelles et fonctions de gestion systme......................30
Fig. 4.1: les entits manager et agent...................................................................................33
Fig. 4.2: le frame ..................................................................................................................36
Fig. 5.1: relation entre rseau de gestion et rseau gr......................................................40
Fig. 5.2: configuration dun VPN ...........................................................................................43
Fig. 5.3: Exemple d'architecture logique en couches ............................................................44
Fig. 5.4: les blocs fonctionnels du TMN ................................................................................45
Fig. 5.5: Points de rfrence entre les blocs de fonctions TMN ............................................46
Fig. 5.6: Exemple d'architecture ...........................................................................................48
Tableau 5.1: Equivalences entre nuds TMN et blocs de fonctions.....................................49
Fig. 5.7: Architecture physique de gestion du service de rseau priv virtuel .......................51
Fig. 6.1: axes de TINA..........................................................................................................55
Fig 6.2: Vue d'ensemble de l'architecture TINA ....................................................................57
Fig. 6.3: Subdivision de l'architecture TINA ..........................................................................58
Fig. 6.4: notations graphiques pour les types d'objet et de relation dfinies par OMT...........60
Fig. 6.5: TINA DPE, l'infrastructure abstraite ........................................................................62
Fig. 6.6: Services et fonctions du DPE TINA ........................................................................63
Fig. 6.7: le DPE vu par TINA-C.............................................................................................64
Fig. 6.8: Concept de session dans TINA ..............................................................................66
Fig. 6.9: structure du modle USCM.....................................................................................68
Fig. 6.10: interactions permises entre composants de service TINA.....................................68
Fig. 6.11: Gestion dans TINA ...............................................................................................69
Fig. 6.12: Blocs de fonction, objets de traitement, points de rfrence et interfaces .............70
Fig. 6.13: le modle d'information de ressources de rseau dfini par TINA-C et ses
fragments ......................................................................................................................72
Fig. 6.14: le graphe de connexion ........................................................................................72
Fig. 6.15: Exemple d'architecture de gestion des ressources ...............................................75
Fig. 7.1: OMA, l'architecture globale de CORBA ..................................................................78
Fig. 7.2: Compilateur IDL......................................................................................................83
INT 2004
INT-LOR-GRS-v2.03
Tableau 7.1: Exemples de rgles de projection ....................................................................83

Fig. 7.3: Composantes du bus CORBA ...............................................................................86
Fig. 7.4: Invocation statique/dynamique ct client...............................................................88
Fig. 7.5: Invocation statique/dynamique ct serveur ...........................................................89
Fig. 8.1: vue densemble du NGOSS....................................................................................92
Fig. 8.2: le eTOM..................................................................................................................94
INT 2004
INT-LOR-GRS-v2.03
Abrviations
API
Application Programming Interface
ASN.1
Abstract Syntax Notation One
ATM
Asynchronous Transfer Mode
B2B
Business to Business
B-ISDN
Broadband ISDN
BOOTP
Boot protocol
CLI
Command Line Interface
CMIP
Common Management Information Protocol
CMIP/GDMO
Common Management Information Protocol/Guidelines for the
Definition of Managed Objects
COPS
Common Open Policy Service
COPS-PR
COPS Usage for Policy Provisioning
CORBA IIOP
Common Object Request Broker Architecture Internet Inter-ORB
Protocol
CORBA
Common Object Request Broker Architecture
CORBA/IDL
Common Object Request Broker Architecture/Interface Definition
Language
DCN
Data Communications Network
DECT
Digital Enhanced Cordless Telecommunications
DHCP
Dynamic Host Configuration Protocol
DNS
Directory Name Service
DSS1
Digital Subscriber System 1
EM
Element Manager
EMS
Element Management System
FFS
For Further Study
FTAM
File Transfer Access and Management
FTP
File Transfer Protocol
ftp
FTP
GDMO
Guidelines for the Definition of Managed Objects
GGSN
Gateway GPRS Support Node
Go interface
The interface between the GGSN and the Policy Decision Function
(PDF)
GSM
Global System for Mobile communications
HLR
Home Location Register
HSS
Home Subscriber Server
IDL
Interface Definition Language
IETF
Internet Engineering Task Force
IIOP
Internet Inter-ORB Protocol
IN
Intelligent Network
INAP
Intelligent Network Application Part
INT 2004
INT-LOR-GRS-v2.03
IRP
IS
ISDN
LDAP
LDUP
LLA
MAP
MExE
MIB
MMI
NM
NMS
NRM
OS
OSI
OSS
PDF
PDH
PDP
PIB
PKI
PLMN
PSTN
QoS
RNC
RSVP
SDH
SLA
SNMP
SNMP/SMI
SOM
SS
SS7
TCP/IP
tftp
TM
TMF
TMN
TOM
UML
UPT
USIM
UTRA
VHE
INT 2004
Integration Reference Point

Information Service
Integrated Services Digital Network
Lightweight Directory Access Protocol
LDAP Duplication/Replication/Update Protocols
Logical Layered Architecture
Mobile Application Part
Mobile Execution Environment
Management Information Base
Man-Machine Interface
Network Manager
Network Management System
Network Resource Model
Operations System
Open Systems Interconnection
Operations Support System
Policy Decision Function
Plesiochronous Digital Hierarchy
Policy Decision Point
Policy Information Base
Public Key Infrastructure
Public Land Mobile Network
Public Switched Telephone Network
Quality of Service
Radio Network Controller
Resource ReserVation Protocol
Synchronous Digital Hierarchy
Service Level Agreement
Simple Network Management Protocol (IETF)
SNMP/Structure of Management Information
Service Operations Management
Solution Set
Signalling System No. 7
Transmission Control Protocol/ Internet Protocol
trivial ftp
Telecom Management
TeleManagement Forum
Telecommunications Management Network (ITU-T)
Telecom Operations Map (TMF)
Unified Modelling Language
Universal Personal Telecommunication
Universal Subscriber Identity Module
Universal Terrestrial Radio Access
Virtual Home Environment
INT-LOR-GRS-v2.03
Chapitre 1 Gestion des rseaux
Prsentation gnrale
Administrer, c'est vouloir tirer le meilleur profit de la structure que l'on
gre. Cependant, ce systme est dual, car la conception d'une gestion
dpend troitement de la structure administre. Inversement, le
comportement futur de cette structure dpendra fortement de sa gestion.
Les services et les quipements de tlcommunication sont de plus en
plus complexes et nombreux, cette volution de la technologie met en
vidence la ncessit de disposer darchitectures pouvant grer ces
services et contrler ces ressources dans des environnements
htrognes.
De faon gnrale, une administration de rseaux a pour objectif
d'englober un ensemble de techniques de gestion mises en uvre pour:
Offrir aux utilisateurs une certaine qualit de service;
Permettre l'volution du systme en incluant de nouvelles
fonctionnalits;
Rendre oprationnel un systme.
Les disciplines de l'administration d'un systme

L'administration de rseaux ne peut pas tre isole de son
environnement. En effet il sagit dune partie intgrante d'un systme plus
gnral constitu de trois parties fondamentales qui sont:
Les utilisateurs ou consommateurs de services;
Les serveurs d'applications ou fournisseurs de services;
La machine de transport reliant les utilisateurs aux fournisseurs.
Ces trois groupes dterminent les trois disciplines d'administration d'un
systme:
Ladministration des utilisateurs

Qui fournit l'ensemble des mcanismes pour:
Laccessibilit et la connexion aux applications. En effet, l'utilisateur
doit pouvoir se connecter aux diffrentes applications et, pour cela, il
doit disposer d'un ensemble d'outils qui lui assurent la transparence
des mthodes d'accs et de connexion aux diffrentes applications;
Laccs aux serveurs de noms, afin de permettre la localisation des
ressources et d'assurer l'utilisateur l'existence et l'utilisation de ces
ressources.
La confidentialit et la scurit: le systme doit fournir l'ensemble des
mcanismes qui permettent de garantir la confidentialit des
informations de l'utilisateur, de scuriser son environnement et de
prvenir toute perte ou altration des changes effectus par
l'utilisateur;
INT 2004
INT-LOR-GRS-v2.03
la qualit de service, qui est la perception du rseau ressentie par

l'utilisateur. Son exigence majeure concerne la disponibilit et les
performances du systme ainsi que sa capacit assurer un service
convenable.
Ladministration des serveurs

Qui recouvre l'ensemble des mcanismes mettre en place pour:
la connexion et la distribution des applications, cela afin de permettre
l'interrelation des services;
la gestion et la distribution des donnes, qui, comme pour les
utilisateurs, doivent garantir la fiabilit de transmission des
informations sur le rseau et offrir un certain nombre d'outils
permettant le transfert de ces informations. C'est typiquement le rle
des outils de transfert de fichiers, qui permettent le partage des
capacits de stockage entre plusieurs systmes;
la gestion des applications, correspond essentiellement au contrle et
la protection des accs ces applications par la distribution de droits,
ainsi qu' la fourniture de mcanismes de contrle d'utilisation de
ressources concernant l'application.
Ladministration de la machine de transport

Qui consiste fournir des mcanismes sur:
des oprations de rseau, dont le rle est de permettre l'intervention
sur le fonctionnement du rseau et la modification si ncessaire;
les incidents rseau par la mise en place de mcanismes de dtection
et de correction. Lorsqu'une alerte est dclenche, des actions
doivent tre prises pour rsoudre rapidement l'incident et rduire son
influence sur la qualit de service;
les performances, dont le but est d'valuer le systme par un
ensemble de paramtres comme le temps de rponse ou la charge du
systme. L'intrt de cette valuation est de permettre un jugement
sur le fonctionnement du systme;
les cots, afin de pouvoir les mesurer. En effet, dans un rseau, les
cots d'utilisation sont complexes valuer puisqu'ils s'appliquent
un ensemble de composants distribus;
la configuration, dont le but est de dterminer la meilleure
configuration du rseau amliorant ainsi les performances du
systme, et par la mme, sa qualit de service. Cette dtermination
se fait gnralement l'aide de graphes;
l'inventaire, qui a pour rle de tenir jour en permanence la liste des
lments (logiciels et matriels) qui constituent un systme rseau;
l'volution et les changements, dont l'objectif est de fournir un certain
nombre d'informations permettant de dterminer les nouveaux
besoins prendre en compte et les parties du systme concernes.
Les architectures de l'administration des rseaux

Lors de la conception d'un systme de gestion de rseau, trois
architectures peuvent tre considres (voir figure 1.1).
Le choix de l'une ou l'autre dpend des besoins du gestionnaire de
rseau. Ces architectures sont:
INT 2004
INT-LOR-GRS-v2.03
Architecture centralise
C'est l'organisation la plus classique de l'administration, dans laquelle un
seul manager (gestionnaire) contrle toutes les ressources du rseau et
les quipements distribus dans un rseau de tlcommunication. Cette
architecture prsente l'avantage d'tre facile concevoir, mais en
contrepartie elle s'avre inefficace dans le cas de rseaux tendus. La
figure 1.2 montre ce type d'organisation.
Gestionnaires
Agents
Architecture plate
Architecture centralise
Architecture hirarchique
Fig. 1.1: les modles dorganisation
Architecture plate
Dans cette organisation, plusieurs gestionnaires contrlent diffrents
aspects et portions du rseau de tlcommunication. Cette conception
implique une interaction entre les managers qui sont au mme niveau de
l'organisation.
Architecture hirarchique
Dans ce type d'architecture, une certaine abstraction a lieu. En effet, il
existe plusieurs niveaux dans lesquels les entits sont considres. La
notion de gestionnaire-agent change dans cette organisation puisque
qu'un agent dans le niveau n devient un gestionnaire pour le niveau
infrieur n-1.
La figure 1.2 montre une vue typique d'un environnement de gestion
centralis. On remarque qu'il y a un seul gestionnaire qui surveille tout le
rseau, les agents ont chacun une visions d'un champ donn, et
enregistrent tous les changements d'tat dans les MIBs (bases de
donnes). Les agents distants qui contrlent donc une certaine partie des
ressources et quipements rseau. Les constructeurs munissent leurs
quipements d'agents logiciels qui dpendent de la plate forme et du
protocole utilis. Ces agents permettent de superviser et collecter des
informations de gestion pour les enregistrer dans des bases de donnes
locales. Les protocoles de gestion de rseaux sont varis, mais
uniquement deux dentre eux sont standardiss : SNMP (Simple Network
Management Protocol) et CMIP (Common Management Information
Protocol). Ces protocoles sont gnriques et indpendants des
quipementiers. Ils sont utiliss partout dans le monde, mais leur
INT 2004
INT-LOR-GRS-v2.03
utilisation dpend de l'environnement et de la complexit des services

fournir.
Fig. 1.2: architecture centralise
Les fonctionnalits de l'administration des rseaux

Cinq groupes de fonctions sont dfinis pour satisfaire tous les besoins
fonctionnels; ces groupes seront dtaills dans le paragraphe 2.4.1 du
chapitre 2:
La gestion des fautes

Concerne la fonction de surveillance (monitoring), la localisation et la
dtermination des pannes.
La gestion des configurations et des noms

Concerne la fonction d'installation de composants, la fonction de contrle
et surveillance puis la fonction de gestion des noms.
La gestion des performances

Concerne la fonction de collecte de donnes, la fonction de gestion de
trafic et la fonction d'observation de la qualit de service.
La gestion de la facturation
Concerne la fonction de surveillance de la charge des ressources, la
fonction de calcul des cots des ressources, la fonction de facturation et
la fonction de gestion des limites utilisateur.
La gestion de la scurit
Concerne la fonction de gestion de la confidentialit, la fonction d'audit et
la fonction d'enregistrement et gestion d'abonns.
Les critres pour une organisation logique

Afin de pouvoir dfinir une organisation logique d'un systme de gestion,
il est ncessaire de tenir compte de certains critres:
Le critre informationnel
Les moyens de gestion se basent tous sur un ensemble d'informations
qu'ils doivent traiter. Ces informations proviennent de sources qui peuvent
INT 2004
INT-LOR-GRS-v2.03
tre de deux types: les informations issues directement du systme gr

et les informations reprsentant le systme gr. Le premier type
d'informations provient essentiellement des sources suivantes: les
composants du rseau, les outils de tests et les utilisateurs. Le deuxime
type, informations dcrivant le systme gr sont stockes dans bases de
donnes.
Le critre fonctionnel
Pour raliser pleinement les diffrentes dcisions administratives, il faut
mettre en uvre diffrents domaines de gestion plus spcifiques et dont
les rsultats fourniront la ralisation d'une dcision. Ces domaines
communs reprsentent des fonctionnalits partages utilisables
diffrents niveaux de responsabilit de gestion. Un certain nombre de ces
fonctions est ncessaire pour raliser une organisation. Ce sont celles
recenses par les organismes de normalisation, savoir les
fonctionnalits de configuration, de performances, de fautes, de scurit
et de comptabilit.
Le critre temporel
Les aspects temporels dterminent les contraintes de raction d'un
lment de gestion, ainsi que ses consquences sur le systme gr. Il
existe trois grands types de contraintes temporelles:
Le court terme de l'ordre de la minute la journe, typiquement, ce
sont les contraintes lies aux aspects oprationnels;
Le moyen terme, de l'ordre de la journe plusieurs mois,
typiquement, ce sont les contraintes lies aux aspects
d'environnement du systme;
Le long terme, de l'ordre de l'anne, typiquement, ce sont les
contraintes lies aux aspects volutifs du systme.
Le critre de discipline
La structure actuelle des rseaux implique de plus en plus une intgration
des phnomnes priphriques la communication. Ainsi, on ne peut
plus, aujourd'hui, dans le cadre d'un rseau intgration de services par
exemple, dissocier ou tout au moins isoler, l'administration de rseaux de
l'administration des utilisateurs et des services. Il y a trois disciplines
d'administration qui doivent interagir troitement pour mener bien une
administration globale d'un systme:
Ladministration des utilisateurs: actuellement ne constitue pas une
part importante, mais elle grandira avec l'mergence des rseaux
trs large bande. En effet, ces rseaux fourniront aux utilisateurs un
point d'accs unique vers des services aussi varis que la tlvision,
la tlphonie sur IP
Ladministration des fournisseurs de services: ceux-ci auront de plus
en plus besoin de moyens leur permettant de construire leurs
services, d'en suivre la qualit et d'effectuer leur propre gestion.
L'administration systme: fournit les mcanismes pour surveiller,
contrler et coordonner les ressources dans l'environnement en
question et les protocoles utiliss pour la communication
d'informations sur ces ressources.
INT 2004
INT-LOR-GRS-v2.03
Conclusion provisoire
Une administration est donc une stratgie permettant de prendre
plusieurs dcisions selon des objectifs fixs au pralable par
l'administrateur. Ces dcisions sont implmentes par des actions
entreprendre sur plusieurs plans, savoir l'administration des utilisateurs,
des fournisseurs de services et la gestion systme.
Une bonne politique d'administration consiste dfinir pour un
environnement donn les critres que l'on souhaite atteindre. Elle permet
d'assurer une qualit de service donne, de promouvoir l'volution du
systme vers de nouvelles fonctionnalits et le fonctionnement normal du
systme.
INT 2004
INT-LOR-GRS-v2.03
Chapitre 2 - Comparaison gestion TMN

vs. gestion SNMP
Le but de ce chapitre est de comparer deux approches diffrentes de la
gestion des rseaux: la gestion SNMP (Simple Network Management
Protocol) et la gestion TMN se basant sur le protocole CMIP (Common
Management Information Protocol) et CMIS (Common Management
Information Service). Tout au long de ce chapitre la comparaison sera
faite entre les modles TMN et IETF (Internet Engineering Task Force)
puisque SNMP est n dans la communaut Internet. Les modles
informationnels seront abords dans le paragraphe 2.1, les modles
architecturaux dans le paragraphe 2.2, les modles de communication
dans le paragraphe 2.3 et enfin les modles fonctionnels du TMN et de
lIETF seront prsents dans le paragraphe 2.4.
Le systme d'information du rseau est l'outil majeur de l'administrateur, il
conditionne la plupart des activits et des potentialits de fourniture de
services. La matrise du systme d'information passera par la
comprhension de sa smantique et par la puissance de sa modlisation.
Comparaison des modles

informationnels TMN et IETF
Le modle informationnel du TMN
Le modle informationnel du TMN est orient objet. Les concepts de ce
modle sont dfinis dans la norme relative au MIM (Management
Information Model) [ISO 10165-1]. Ce modle est caractris par la
dfinition des objets avec des proprits spcifiques, ces objets tant les
objets de gestion. Ces derniers sont la reprsentation abstraite des
ressources de communication, ressources physiques ou logiques tels
qu'un PABX, une connexion, etc.
En d'autres termes, les objets grs sont "la vue de gestion des
ressources" grer. Le fonctionnement interne de la ressource et les
relations entre objet gr ne sont pas connus de l'administration. Seules
les caractristiques dfinissant la ressource en tant qu'un objet administr
sont accessibles par l'administration travers son interface de gestion.
Les informations de gestion sont documentes l'aide d'un ensemble de
formulaires (templates), appel GDMO (Guidelines for the Definition of
Managed Objects) [ISO 10165-4].
Modlisation des classes d'objets grs

Un objet gr ou MO (Managed Object) reprsente une ressource de
communication dans un but de gestion. Un objet gr est une instance
d'une classe d'objet de gestion ou MOC (Managed Object Class).
INT 2004
INT-LOR-GRS-v2.03
L'ensemble des objets grs forme la vue de gestion OSI des ressources
en question. La dfinition d'une classe d'objets de gestion consiste en:
La position de la classe dans un arbre d'hritage;
Un ensemble de paquetages obligatoires. Un paquetage obligatoire
contient les caractristiques qui sont primordiales et que l'on doit
retrouver dans chaque instance de la classe d'objet;
Un ensemble de paquetages conditionnels et la condition sous
laquelle chaque paquetage est prsent.
La structure d'un paquetage est caractrise par:
Les attributs dont la classe d'objets dispose;
Les notifications pouvant tre mises par l'objet;
Les oprations de gestion qui affectent les attributs de cet objet ou
l'objet dans son ensemble;
Le comportement que l'objet a en rponse aux sollicitations externes.
GDMO
GDMO est une notation semi-formelle qui permet de spcifier les MOCs.
Les directives GDMO procurent un mcanisme normalis pour dfinir de
manire semi-formelle la syntaxe, la smantique et les aspects
comportementaux des informations de gestion, ce qui permet une
comprhension commune des fonctions de gestion en limitant la place
laisse l'interprtation.
Des formulaires ont t dfinis pour les types suivants: classe,
paquetage, attribut, groupe d'attributs, notification, comportement, action,
paramtre et lien de nommage.
Classe:
L'exemple suivant dclare une classe d'objet de gestion concernant le
type d'objet Entit_protocole:
Entit_protocole MANAGED OBJECT CLASS DERIVED FROM Entit;
<Super-classe dont la dfinition est hrite par la classe entit_protocole>
CHARACTERIZED BY Paquetage_entit_protocole;
<Ce paquetage obligatoire est dcrit ci-dessous>
REGISTERED AS {exemple_Classe_1}
<Enregistrement de la classe dans l'arbre d'enregistrement ISO>
Paquetage:
Un paquetage est une construction modulaire contenue dans un objet de
gestion. Un paquetage possde un ensemble d'attributs, de notifications,
d'oprations et de comportements. Le concept de caractristiques d'un
paquetage obligatoire est commun toutes les instances d'une classe
d'objet donne. A la cration (resp. la suppression) d'un objet, tous les
paquetages obligatoires sont crs (resp. supprims) simultanment. Les
paquetages conditionnels sont prsents si les conditions explicites qui
leur sont associes sont satisfaites. Si tel est le cas, alors le paquetage
conditionnel est cr avec l'objet duquel il dpend. Une fois instanti, le
paquetage conditionnel ne pourra tre supprim que lors de la
suppression de l'objet le contenant.
INT 2004
INT-LOR-GRS-v2.03
Un paquetage est dcrit l'aide d'un formulaire. Si le paquetage peut tre

rutilis par plusieurs classes d'objets de gestion; alors celui-ci doit tre
spcifi sparment, sinon sa dclaration peut tre contenue dans la
classe d'objets qui le possde. Le concept de paquetage est illustr cidessous.
Paquetage_entit_protocole PACKAGE
BEHAVIOUR Comportement_Classe_Entit;
ATTRIBUTE
Taille_Max_PDU
GET
<nom d'attribut et statut (lecture, criture)>
Nb_PDUs_Entre
GET;
Nb_PDUs_Sortie
GET;
Nb_PDUs_Entre/s
GET;
Nb_PDUs_Sortie/s
GET;
Nb_PDUs_Perte
GET;
Nb_PDUs_Erreur
GET;
Nb_PDUs_Perte/s
GET;
Taux_Perte
GET;
Taux_Erreur
GET;
ATTRIBUTE GROUPS
groupe_compteur;
groupe_compteurs;
La syntaxe d'un attribut est un type ASN.1 qui dcrit la faon dont les
instances de valeur d'attribut sont transportes dans le protocole de
gestion. A chaque attribut sont associs des droits d'accs GET,
REPLACE ou GET-REPLACE signifiant que l'attribut est accessible en
lecture, criture, ou lecture-criture. Un attribut peut tre multivalu, c'est
dire possder un ensemble de valeurs. Dans ce cas les deux droits
Taille_Max_PDU ATTRIBUTE <Nom de l'attribut>
WITH ATTRIBUTE SYNTAX
MATCHES FOR EQUALITY, ORDERING <Opration pouvant tre ralises sur
l'attribut>
REGISTERED AS {exemple_attribut_1} <Nom d'enregistrement>
d'accs ADD et REMOVE permettent d'ajouter ou de retirer une valeur
/de la liste de valeurs de l'attribut.
Groupe d'attributs:
Un groupe d'attributs est un moyen de rfrencer un ensemble d'attributs
ayant la mme smantique.
Groupe_compteur ATTRIBUTE GROUP <Nom du groupe d'attribut>

GROUP ELEMENTS
Nb_PDUs_Entre, Nb_PDUs_Sortie, Nb_PDUs_Perte,
Nb_PDUs_Erreur
DESCRIPTION
<Groupe d'attributs contenant tous les attributs relatifs des
compteur de PDUs traites par l'entit protocolaire. Ces
compteurs sont incrments depuis l'initialisation du
protocole>
INT 2004
INT-LOR-GRS-v2.03
10
Notifications:
Les objets de gestion peuvent mettre des notifications chaque
occurrence d'vnements dtects. Elles contiennent des informations
relatives ces vnements survenus de faon soit interne soit externe.
seuil_perte_dpass NOTIFICATION
BEHAVIOUR Comportement_seuil_perte_dpass
WITH INFORMATION SYNTAX <ModuleNotification.InfoPerte>
AND ATTRIBUTE IDS
Taux_Perte/s, Taux_Perte
REGISTERED AS {exemple_Notification_1}
Oprations:
Afin de manipuler les objets, deux types d'oprations ont t dfinies: les
premires applicables aux attributs de l'objet, les deuximes applicables
l'objet lui-mme.
Les oprations sur les attributs sont mises aux objets de gestion, afin de
lire ou de modifier les valeurs d'attribut. Selon leur structure, les attributs
peuvent tre soit des attributs simples, soit des attributs multi-valus, soit
des attributs de groupe. Un attribut simple possde une valeur unique
alors qu'un attribut multi-valu est compos d'un ensemble de valeurs qui
peuvent tre manipules individuellement. Un attribut de groupe se rfre
un groupe d'attributs l'intrieur d'une classe d'objets. Une opration
sur un groupe d'attributs est ralise sur chaque attribut de manire
individuelle dans ce groupe. Diffrentes oprations sont possibles en
fonction du type d'attribut manipuler:
Get attribute value;
REPLACE attribute value;
REPLACE-WITH-DEFAULT value;
ADD member;
REMOVE member.
Les deux dernires oprations ne sont applicables qu' des attributs
multivalus, alors que les deux premires sont les seules pouvoir
s'appliquer des attributs de groupe.
Une opration GET est translate en un service CMIS M-GET. Les
oprations REPLACE, REPLACE-WITH-DEFAULT, ADD, et REMOVE
sont traduites en un service CMIS M-SET.
Les oprations sur les objets incluent la cration d'un objet (CREATE), la
suppression d'un objet (DELETE), l'excution d'une action par un objet
(ACTION).
L'opration de cration demande la cration et l'initialisation d'un objet de
gestion. Cette opration est unique puisqu'elle s'applique un objet qui
n'existe pas encore. Il est de la responsabilit du processus de gestion
systme dans le systme cr, de crer cet objet. L'quivalent CMIS est
M-CREATE.
L'opration de suppression s'applique tous les objets de gestion qui
peuvent tre supprims par une opration de gestion. A l'excution de
INT 2004
INT-LOR-GRS-v2.03
11
cette opration, si l'objet de gestion contient d'autres objets de gestion,

soit cet objet dtruit l'ensemble des objets contenus pour garantir
l'intgrit du nommage, soit il refuse la suppression tant que les objets
contenus n'ont pas t pralablement supprims. Le formulaire lien de
tous les objets contenus dfinit le comportement de l'objet lors d'une
suppression. L'opration DELETE est translate en un service CMIS MDELETE. Le mode des oprations CREATE et DELETE est confirm.
Quant l'opration ACTION, elle est utilise afin de dfinir des oprations
arbitraires. La dfinition de ces actions et l'information ncessaire afin de
les excuter, font partie de la spcification de la classe d'objets
correspondante. Ce mcanisme est prvu afin de raliser des activits de
gestion complexes. Le service CMIS quivalent est M-ACTION.
Comportement:
La description du comportement d'un objet de gestion spcifie les
caractristiques dynamiques d'un objet et de ses attributs, les
circonstances pour lesquelles les notifications doivent tre meises et les
actions. GDMO fournit un formulaire pour la spcification du
comportement d'un objet de gestion, en langage naturel.
Contenance et nommage
Pour faciliter la supervision et le contrle des ressources travers les
MOs qui les reprsentent, il est ncessaire de hirarchiser les MOs. Ces
derniers sont structurs selon une relation de contenance (voir figure 2.1).
Un MO est contenu dans un autre MO tel qu'un sous-rpertoire est
contenu dans un rpertoire. Une structure appele arbre de contenance
est dduite partir de cette relation entre objets. Les MOs sont nomms
sur la base de cet arbre: un objet doit tre nomm de faon non ambigu
pour l'identifier et le rfrencer. Le nommage se fait en fonction de la
position du MO dans l'arbre de contenance, grce une squence de
noms appele nom de distribution relatif ou RDN (Relative
Distinguished Name). L'arbre de contenance permet aussi au
gestionnaire d'exercer un contrle hirarchique sur les ressources
grer.
Rpertoire 1
R-id = "R1"
Sous-rpertoire 1
SR-id = "SR1"
Fichier 1
F-id = "F1"
Sous-rpertoire 2
SR-id = "SR2"
Fichier 2
F-id = "F2"
Fig. 2.2: larbre de nommage
INT 2004
INT-LOR-GRS-v2.03
12
L'enregistrement
Le nom du formulaire est utilis pour dsigner de manire unique un type
d'information au sein du document dans lequel il est dclar. L'identifiant
du type d'information ou OBJECT IDENTIFIER est attribu lors de
l'enregistrement du type d'information. Il est unique au monde, il est
vhicul dans les protocoles de communication et il permet de
reconnatre un type donn parmi tous les types enregistrs. Les
identifiants sont dlivrs par des autorits d'enregistrement, organisations
habilites enregistrer des types d'information comme l'ISO ou l'ITU-T.
Les identifiants correspondent une position dans un arbre
d'enregistrement (Registration Tree).
Modle informationnel de la communaut Internet

Pour la gestion de la communaut Internet, l'IETF (Internet Engineering
Task Force) a dfini trois RFCs :
RFC 1155: dcrit la structure et le nommage de l'information de
gestion, savoir le SMI, avec une extension dfinie dans le RFC
1212,
RFC 1157: dfinit le protocole SNMPv1 utilis pour accder via le
rseau aux objets grs,
RFC 1213: dcrit la base d'information de gestion (MIB II), ce RFC
enrichit le RFC 1066 qui dcrit une premire version de la MIB, MIB1.
Le modle informationnel dfini par la communaut Internet est simple
afin de fournir rapidement une infrastructure oprationnelle de gestion de
rseaux. Cette simplicit entrane videmment des faiblesses
conceptuelles dans le modle.
Structure de l'information de gestion (SMI)

La SMI (Structure of Management Information) dfinit comment chacun
des lments d'information, qui concernent les quipements grs, est
reprsent dans une base d'information d'administration, la MIB
(Management Information Base). Les objets grs sont accessibles grce
la MIB. Les objets contenus par la MIB sont dfinis en utilisant le
langage ASN.1 (Abstract Syntax Notation One). Chaque type d'objet a
son nom, sa syntaxe et son encodage.
Nom d'objet:
Les noms sont utiliss pour identifier les objets grs. Chaque objet
possde un identificateur d'objet qui lui est propre. Ce dernier a une
structure hirarchique, arborescente. C'est une squence de nombres
entiers qui parcourent un arbre (voir figure 2.2). L'IETF utilise l'arbre
d'enregistrement de l'OSI afin de nommer l'information de gestion. Cet
arbre est compos d'une racine laquelle sont lis tous les nuds.
Chaque nud est identifi de manire unique. Le nud-racine de l'arbre
n'est pas indiqu, mais il possde trois fils, savoir l'ITU-T marqu
ccitt(0), le second administr par l'ISO et marqu iso(1) et iso-ccitt(2)
administr par les deux la fois.
INT 2004
INT-LOR-GRS-v2.03
13
iso(1)
ccitt(0)
joint-iso-ccitt(2)
org(3)
dod(6)
internet(1)
directory(1)
mgmt(2)
experimental(3)
mib(1)
system
interface
ip
private(4)
entreprises(1)
SNMP
Fig. 2.3: la hirarchie denregistrement dans linternet
Ainsi l'identificateur d'Internet est: internet OBJECT IDENTIFIER =

{iso(1) org(3) dod(6) 1}. Chacun des objets dans le sous-arbre
internet possde un identificateur dont le prfixe est: 1.3.6.1.
Syntaxe:
La syntaxe est utilise pour dfinir la structure de donne qui correspond
au type d'objet. Un type d'objet correspond grossirement champ type
d'une classe d'objets. Un ensemble limit de constructeurs ASN.1 sont
utiliss afin de dfinir cette structure. Les types primitifs ASN.1 considrs
sont "Integer", "Octet String", "Object Identifier", et "Null".
Les types composs sont "Sequence" et "Sequence Of". De plus de
nouveaux types ont t dfinis: "Network Adress" afin de reprsenter
des adresses de protocole, "IP Adress" pour reprsenter des adresses
Internet 32 bits, "Counter" pour dfinir des compteurs de type entier
appartenant l'intervalle[0, 2 32 -1], "Gauge" pour caractriser un entier
positif ne dpassant pas une taille maximale, "Timeticks" afin de
compter le temps en centimes de seconde, et finalement "Opaque" qui
reprsente une syntaxe quelconque encode sous forme d'un OCTET
STRING.
Encodage:
Lorsque l'instance d'un type d'objet a t identifie, sa valeur peut tre
transmise en appliquant les simples rgles d'encodage d'ASN.1 la
syntaxe de type d'objet. Pour dcrire un objet, le SMI dfinit le formulaire
suivant:
Object: un nom textuel pour nommer l'objet.
Syntax: la syntaxe abstraite pour le type d'objet, prsente en utilisant
ASN.1.
Definition: une description textuelle de la smantique du type d'objet.
Access: read-only, read-write,write-only ou not accessible.
INT 2004
INT-LOR-GRS-v2.03
14
Status: mandatory, optional ou obselete.
La base d'information de gestion (MIB)

SNMP dfinit une collection d'objets "standard" administrer travers la
spcification des MIB-I et MIB-II. Les objets dfinis par SNMP ont une
structure particulirement simple. En effet, la dfinition d'un objet est
limite un type simple ou une table d'objets de types simples.
La MIB-I correspond au premier lot de dfinitions d'objets SNMP. Elle
contient une centaine d'objets, rangs par groupes fonctionnels au
nombre de huit: System dcrit le nud gr, Adress Translation dfinit la
mise en correspondance entre adresses rseaux (par exemple, IP) et
adresses physiques (par exemple, MAC), Interface contient un ensemble
d'informations utiles pour la gestion des ports/interfaces du nud gr, IP
fournit un ensemble de donnes ncessaires pour suivre l'tat de l'entit
IP, ce groupe propose deux tables: IPAddrTable qui contient des
informations d'adressage relatives aux adresses IP du nud courant et
IPRoutingTable qui contient des informations sur les adresses IP
destinataires telle que l'adresse du nud suivant, le groupe TCP offre
des informations sur les connexions TCP, ICMP fournit un ensemble de
compteurs ou statistiques sur les messages ICMP, UDP traite les
datagrammes UDP, EGP contient des informations sur les entits
voisines EGP et sur l'tat d'EGP travers des compteurs. Ces huit
groupes permettent de grer uniquement un rseau TCP/IP. Certains de
ces groupes sont obligatoires (les cinq premiers), d'autres sont
considrs comme obligatoires si l'quipement grer fonctionne avec un
protocole particulier. Par exemple si un routeur utilise EGP, alors le
groupe EGP est obligatoire. Afin de descendre plus finement dans les
fonctionnalits d'un quipement, de nouveaux objets ont t ajouts
progressivement aux groupes existants, dfinissant ainsi la MIB-II.
INT 2004
INT-LOR-GRS-v2.03
15
mib[1.3.6.1.2.1]
system[1.3.6.1.2.1.1]
at[1.3.6.1.2.1.3]
cmot[1.3.6.1.2.1.9]
u
egp[1.3.6.1.2.1.8]
transmission[1.3.6.1.2.1.10]
icp[1.3.6.1.2.1.6]
interfaces[1.3.6.1.2.1.2]
snmp[1.3.6.1.2.1.11]
ipAddrTable[1.3.6.1.2.1.4.20]
ipAddrEntry
ipAdEntAddr
[1.3.6.1.2.1.4.20.1.1]
ipAdEntIfIndex
ipAdEntNetMask
[1.3.6.1.2.1.4.20.1.2] [1.3.6.1.2.1.4.20.1.3]
ipAdEntBcastAddr
ipAdEntReasmMaxSize
[1.3.6.1.2.1.4.20.1.4]
[1.3.6.1.2.1.4.20.1.5]
Fig. 2.4: larbre denregistrement de la MIB 2
De plus de nouveaux groupes ont t ajouts tels que SNMP, qui

possde trente objets de types simples utiliss pour grer les
performances du protocole de gestion. La figure 2.4 illustre l'arbre
d'enregistrement de la MIB-II. Par ailleurs il faut des outils pour rendre les
MIBs conviviales. Comme toute base de donnes, elle requiert des outils
pour la rendre accessible. Gnralement, ces outils sont proposs sur les
plates-formes. Ces dernires peuvent offrir un compilateur de MIB pour
avoir le bon format, un navigateur qui affiche l'arbre de la MIB de manire
graphique et qui permet de rechercher les objets et un gnrateur d'tat
de MIB galement graphique.
La MIB RMON
L'horizon des MIB-I et MIB-II a t largement agrandi par l'introduction de
la MIB RMON [Waldbusser 91]. Cette dernire apporte de nouvelles
fonctionnalits telles que statistiques, historiques, dtection de seuils
d'alarme, gestion des hosts, estimation de flux, filtrage de capture de
paquets, gestion des notifications d'vnements qui donnent un rle
plus important l'agent qui excute des tches plus compltes pour
dcharger le travail du gestionnaire.
La MIB RMON ralise deux tches: tout d'abord elle fournit une vue
d'ensemble pour la gestion d'un rseau travers une surveillance
distance. Les MIBs prcdentes se focalisaient sur la gestion
d'quipements (routeurs, ponts, stations, etc.) avec une emphase
minimale sur la gestion du rseau dans son ensemble. C'est ce dernier
point que traite RMON (voir figure 2.5). En second, elle spcifie les
particularits de la gestion d'un rseau Ethernet. Les concepteurs de la
MIB RMON ont choisi au dpart ce rseau, mais depuis, des MIBs RMON
pour les sous rseaux Token Ring et FDDI ont vu le jour.
INT 2004
INT-LOR-GRS-v2.03
16
Gestionnaire SNMP
SNMP
SNMP
MIB RMON
Hosts
Agent SNMP
Statistics
History
Fig. 2.5: MIB RMON
La MIB RMON dfinit les neuf groupes suivants:

le groupe"Statistics" met jour des statistiques mesures par l'agent
pour chaque interface supervise. Ces statistiques comprennent les
paquets, les octets, les diffusions, ainsi que les collisions sur le segment
local, aussi bien que le nombre de messages rejetes par l'agent;
le groupe "History" comprend des objets utiliss pour enregistrer des
informations des fins d'analyse par le gestionnaire;
le groupe "Alarm" fournit un mcanisme pour dfinir des seuils;
le groupe"Host" contient des statistiques sur chaque host gnrant du
trafic sur le rseau;
le groupe "HostTopN" tend le groupe Host en fournissant des
statistiques tries;
le groupe "Matrix" contient une matrice de trafic au niveau de la couche
MAC du sous-rseau Ethernet. Cette matrice indique le trafic et le nombre
d'erreurs par paire de nuds du rseau, une paire tant reprsente par
un nud metteur et un nud destinataire;
le groupe "Filter" permet de dfinir des filtres de capture de paquets;
le groupe "Packet capture" permet la capture de paquets si adquation
avec le filtre;
le groupe "Event" contrle la gnration et la transmission
d'vnements.
Pour plus de dtails sur ces groupes, se rapporter [Waldbusser 91].
SNMPv2
SNMPv2 a vu le jour en 1993, mais il ne fait pas l'unanimit de la
communaut Internet, qui trouve certains aspects trop complexes
mettre en uvre. Nanmoins, SNMPv2 se veut tre une amlioration de
SNMP. On y trouve un nouveau protocole de scurit, le chiffrement
(optionnel), des communications de gestionnaire gestionnaire, un
transfert d'informations de masse, de nouveaux objets MIB, la capacit
INT 2004
INT-LOR-GRS-v2.03
17
d'ajouter ou de supprimer des lignes de tables et de nouveaux types de

donnes SMI.
Le SMI de SNMPv2, dcrit au sein du RFC 1442 est divis en trois
parties: dfinition des modules, dfinition des objets et dfinition des
traps. Les dfinitions de modules sont utilises afin de dcrire des
modules d'information. Une macro ASN.1, MODULE-IDENTITY est
utilise pour prciser la smantique d'un objet gr. Les dfinitions
d'objets sont utilises afin de dcrire les objets de gestion. Les dfinitions
de notifications (des traps) sont utilises afin de dcrire des missions
non sollicites d'informations de gestion. Une macro ASN.1,
NOTIFICATIONS-TYPE est prvue cet effet.
En rsum, les diffrences entre les deux approches OSI et SNMP sont
profondes. Alors que le modle informationnel propos par l'ISO se fonde
sur l'approche oriente objet, les objets dfinis par l'IETF dans le monde
Internet sont dcrits sous forme de variables simples mises dans un arbre
d'enregistrement. Les avantages et les inconvnients de chacune des
solutions sont que:
Le modle informationnel de l'ISO est plus complexe et difficile
appliquer. Des outils appropris doivent tre utiliss afin de crer des
librairies d'objets de gestion OSI;
Les proprits d'hritage et d'abstraction associes l'orient objet,
peuvent tre utilises afin de crer une structure d'objet bien dfinie;
Les nombreuses librairies d'objets associes aux MIBs cres par
l'IETF montrent clairement qu'elles ne fournissent pas de structuration
suffisante de l'information. En particulier l'absence de mcanisme
d'hritage pour la rutilisation signifie que des informations drives
les unes des autres peuvent tre contenues dans des sous-arbres
diffrents de l'arbre d'enregistrement.
Modles architecturaux de
gestion TMN - SNMP
Une architecture est une structure d'ensemble, c'est dire une dfinition
des rgles de composition du systme et de la coopration des
composants des fins de transparence pour l'utilisateur du service fournit
par cette architecture. Une cohrence parfaite des diffrentes parties du
rseau et une grande modularit sont ncessaires, car chaque partie doit
pouvoir tre modifie ou remplace sans affecter les autres. L'ensemble
matriel et logiciel s'analyse travers une architecture physique du
rseau et une architecture logique du rseau. Les trois grandes fonctions
travers lesquelles un rseau rend un service global, dlimitent des
plans, savoir:
Plan usager pour le transfert des informations des applications
usagers;
Plan de contrle pour la signalisation;
Plan de gestion pour toutes les applications d'administration.
Cadre architectural de la gestion TMN

Les normes de gestion TMN traduisent une approche systme de la
gestion de rseau. Elles dfinissent les lments ncessaires la
INT 2004
INT-LOR-GRS-v2.03
18
spcification de la gestion des ressources de communication d'un

systme.
Du point de vue architectural, la figure 2.6 explicite la couche application
pour le service de gestion. La couche application o se trouve la gestion
systme est la couche la plus haute dans l'architecture OSI. Les
processus de communication qui se trouvent dans cette septime couche
sont d'une telle diversit que la structure de la couche application a t
normalise (ISO 9545) de faon modulaire. Le concept de base de la
couche application est le processus d'application qui regroupe l'ensemble
des fonctions ncessaires la ralisation d'une application donne.
La gestion systme est assure par les processus d'administration de
systme SMAP (Systems Management Application Process) qui
communiquent entre eux grce des entits d'application de gestion
systme SMAE (Systems Management Application Entity).
Ces dernires se composent de domaines de gestion (SMFA, System
Management Functional Area), ce sont des composants du niveau
applicatif qui s'appuient, comme toutes les applications, sur les lments
de service d'application (ASE, Application Service Element) de base. Ce
sont ACSE (Association Control Service Element) qui gre l'association
travers laquelle se droule l'change de donnes applicatives et ROSE
(Remote Operations Service Element) qui est l'lment de service
d'oprations distantes. Pour les applications de gestion on a recours
CMISE (Common Manangement Information Service Element) pour
effectuer les changes entre entits de gestion systme.
La gestion de systme OSI apparat donc comme une application pour
laquelle il faut exprimer le profil fonctionnel et la QoS dsire pour le flux
(lien) de gestion, afin de choisir le rseau de communication le plus
adquat. En effet, CMIP excute les changes rels entre un gestionnaire
(un manager) et un agent de systme gr. Il utilise une MIB pour
connatre les possibilits de l'agent gr et en avoir une image.
INT 2004
INT-LOR-GRS-v2.03
19
MIB
partage
SMAP
SMAP
SMAE SMASE
SMAE SMASE
CMIS
CMIS
ACSE
ROSE
ROSE
MI
B
LO
CA
LE
ACSE
Rseau
Fig. 2.6: Cadre architectural et gestion de composants rseau prconise par l'OSI
Cadre architectural de la gestion SNMP

Par abus de langage, le protocole SNMP (Simple Network Management
Protocol) couvre l'ensemble des standards de gestion prconiss par la
communaut Internet (IETF). En gnral, ces standards sont surtout
utiliss dans un contexte LAN alors que le cadre architectural de l'ISO
s'applique dans des contextes WAN.
La communaut Internet recommande SNMP pour mettre en uvre
rapidement des moyens de gestion. Les standards SNMP, tablis depuis
1990, sont axs autour de deux concepts:
la dfinition d'un protocole d'change SNMP qu'on dtaillera dans le
paragraphe 4.3;
la dfinition des informations d'administration des MIBs qu'on a dj
dveloppes.
Le protocole SNMP dfinit essentiellement les rgles permettant l'envoi
de messages d'administration entre des "gestionnaires" et des "agents".
Un agent est un logiciel oprant l'intrieur d'un quipement grer
(terminal, serveur de terminaux, passerelle, pont, routeur, unit centrale,
etc.) alors qu'un gestionnaire est un logiciel rsidant dans une station de
gestion de rseaux NMS (Network Management Station), et a la
possibilit d'adresser des requtes vers des agents. Le protocole SNMP
fonctionne en mode non connect et ne ncessite pas de couche de
transport fiable, d'o l'utilisation d'UDP (User Datagram Protocol). Ceci
permet de dfinir le cadre architectural (voir figure 2.6) reprsentatif des
standards de faits de la communaut Internet.
INT 2004
INT-LOR-GRS-v2.03
20
Gestionnaire
Agent
Manager
Agent
Appllicatoin
SNMP
SNMP
Rseau
Fig. 2.7: Architecture pour la gestion de composants rseau prconise par l'IETF
Comparaison des modles de

communication TMN et IETF
Le modle de communication permet d'apprhender les changes entre
les composants d'un systme, dans leur dimension qualitative et
quantitative. Plus que dans tout autre domaine, les flux, les changes,
sont la base, le cur des rseaux. C'est l'abstraction de ce lien qui a
conduit la modlisation gnrique "nud, lien, rseau" de notre
contexte rseau global (systme distribu). C'est par l'tude des
changes de messages que les structures, les architectures se
conoivent.
Le modle de communication du TMN

Le modle de communication TMN identifie, comme tous les modles de
communication, les changes entre les composants architecturaux. Les
dialogues entre deux entits fonctionnellement diffrentes dans un mme
systme est de type client/serveur. Ce dialogue entre deux entits
adjacentes se dnomme service en gnral, et plus exactement CMIS
pour la gestion. Quant au dialogue entre deux entits fonctionnellement
quivalentes entre deux systmes supporte les rgles rgissant la mise
en relation, ce dialogue c'est le protocole. Celui associ aux entits CMIS
est la spcification CMIP. L'administration est une application, elle se
situe donc en couche 7 du modle de rfrence. Le flux applicatif
s'appuiera sur les services rendus par les couches infrieures et par les
autres services de la couche 7.
Le service CMIS
CMIS est l'ensemble des fonctions communes de la gestion systme
permettant de raliser le transfert des oprations et des notifications de
gestion. Il est offert par l'entit de service CMISE de la couche
application. L'lment CMISE se compose de quatre entits distinctes:
INT 2004
INT-LOR-GRS-v2.03
21
cur de CMISE, la machine protocolaire CMIPM (Common

Management Information Protocol Machine) qui met en uvre le
protocole et gre les units de donnes du protocole CMIP;
le fournisseur de service CMISE qui est charg de recevoir les
primitives CMISE et de transmettre les units de donnes de service
correspondantes (Service Data Unit, SDU) CMIPM;
l'utilisateur de service ROSE qui gre les requtes faites ROSE.
Elles permettent d'changer les PDUs entre deux protocoles CMIP;
Enfin, un gestionnaire de d'entit qui gre les primitives non normalises
de communication avec la fonction de contrle d'association simple
(SACF).
L'entit CMISE distingue les six services d'oprations (qu'elle peut traiter
sans aucune connaissance du contenu, laquelle est laisse SMASE) et
un service de notification, qui sont:
M_CREATE pour demander la cration d'un objet dans la MIB de

l'agent (Mode confirm);
M_DELETE pour supprimer des objets dans la MIB de l'agent (Mode

confirm);
M_ACTION pour demander l'excution d'une action sur un ou plusieurs

objets (confirm ou non);
M_SET pour modifier les valeurs d'attributs d'objets (confirm ou non);
M_GET pour consulter les valeurs associes aux attributs d'objets

(confirm ou non);
M_CANCEL_GET pour demander de ne pas recevoir les rsultats d'un

GET prcdent (Mode confirm);
M_EVENT_REPORT pour transmettre un rapport d'vnement relatif

un objet (confirm ou non).
A ces sept primitives s'ajoute la possibilit de disposer d'une rponse
multiple, sans cration de nouvelle primitive, et de moyens de slection
d'objets de gestion par un mcanisme de filtrage en profondeur. Ces
extension sont disponibles pour les primitives M_DELETE, M_ACTION,
M_SET et M_GET:
La slection de lobjet gr se fait en deux phases: la rduction de

l'espace de choix (scoping) et le filtrage (filtering). Les noms des
instances d'objets grs sont organiss hirarchiquement dans un
arbre d'information de gestion, le MIT (Management Information Tree).
Le scoping consiste identifier un ensemble d'objets: permet de
dfinir un objet de base, correspondant la racine d'un sous-arbre de
l'arbre d'information de gestion et spcifie le niveau de scoping (objet
de base seul, les descendants de l'nime niveau).
Le filtering consiste appliquer des tests chacun des objets de
l'ensemble slectionns par le scoping pour extraire un sousensemble: teste la prsence ou la valeur d'attributs de l'objet, l'aide
d'une ou de plusieurs assertions groupes par des oprateurs
logiques.
Un paramtre de synchronisation permet un utilisateur du service de
spcifier comment les oprations sur les instances d'objets grs doivent
tre synchronises, quand plusieurs objets ont t slectionns par le
scoping et le filtering. Ce paramtre peut prendre deux valeurs:
INT 2004
INT-LOR-GRS-v2.03
22
atomic: vrification de la possibilit d'excution sur tous les objets, s'il

existe une ou des impossibilits, aucune n'est excute, sinon toutes
sont excutes.
Best effort: excution sur tous les objets o elle est possible, c'est la
valeur par dfaut.
Le protocole CMIP
Pour prsenter le protocole CMIP qui se base sur les tats de
fonctionnement de la machine protocolaire CMIPM (CMIP Machine), il
faut connatre la structure de CMISE (voir figure 2.7). Une instance de ce
dernier est compose d'une machine protocolaire CMIPM, d'un
fournisseur de service CMISE (CMISE-provider), d'un utilisateur de
service ROSE (ROSE-user), d'un gestionnaire et de trois SAPs, SAPcmise-smase, SAP-cmise-rose, SAP-cmise-sacf.
La machine CMIPM met en uvre les lments de procdure du
protocole CMIP et gre les units de protocole CMIP (CMIP-PDUs).
CMISE-provider gre les primitives de service CMISE. Il reoit les
primitives CMISE de requte et de rponse provenant du CMISE-user de
SMASE et en transmet les units de service CMISE (CMISE-SDUs)
CMIPM. Il met des primitives CMISE d'indication et de confirmation
l'intention du CMISE-user de SMASE lorsque CMIPM lui demande de
transfrer des CMISE-SDUs.
ROSE-user gre les primitives de service ROSE. Il reoit des primitives
ROSE d'indication provenant du ROSE-provider de ROSE et en transmet
les units de service ROSE (ROSE-SDUs) CMIPM. Il met des
primitives ROSE de requte l'intention du ROSE-provider de ROSE
lorsque CMIPM lui demande de transfrer des ROSE-SDUs.
Le gestionnaire gre les primitives non normalises d'interaction avec
SACF (Single Association Control Function) charg de coordonner le
travail des ASEs (Application Service Element). SAP-cmise-smase
reprsente le point d'accs aux services de CMISE. C'est l'une des
extrmits de la connexion qui relie SMASE CMISE. Par cette
connexion transitent les primitives CMISE entre ces deux lments. SAPcmise-rose reprsente le point d'accs aux services de ROSE. Par cette
connexion transitent les primitives ROSE entre ces deux lments. SAPcmise-sacf reprsente le point d'accs aux services non normaliss
offerts par CMISE la fonction SACF.
INT 2004
INT-LOR-GRS-v2.03
23
SMASE
CMISE-user
CMIPM
ROSE-user
SAP-cmise-rose
C
M
I
S
E
SAP-cmise-sacf
CMISE-provider
Gestionnaire
SAP-cmise-smase
S
A
C
F
ROSE-provider
R
Fig. 2.8: Composition de CMISE
Etats de la machine CMIP:

Une machine protocolaire est dcrite sous la forme d'un automate. Celuici se prsente comme une boite noire sollicite par des vnements
extrieurs, qui dclenche un traitement interne spcifique pour chaque
vnement reu en fonction de l'tat dans lequel elle se trouvait au dbut
du traitement, il gnre des vnements sortants et change
ventuellement d'tat la suite de chaque traitement dclench. La
description du protocole CMIP par la norme [ISO 9596] permet d'identifier
six tats de fonctionnement de CMIPM:
IDLE: c'est l'tat de repos de CMIPM. Dans cet tat, le protocole est
inactif;
ASSOCIATED: c'est l'tat de fonctionnement normal de CMIPM
lorsque l'association d'application est tablie. Il est prt accepter des
primitives CMISE;
WCFESTA: CMIPM est en attente d'une confirmation d'tablissement
d'association que doit rendre l'entit SMAE distante;
WRPESTA: CMIPM est en attente d'une rponse d'tablissement
d'association que doit rendre son utilisateur, c'est dire SMASE;
WCFTERM: CMIPM est en attente d'une confirmation de terminaison
d'association que doit rendre l'entit SMAE distante;
WRPTERM: CMIPM est en attente d'une rponse de terminaison
d'association que doit rendre son utilisateur SMASE.
Le protocole CMOT
Le protocole CMOT est la migration du systme de gestion de rseaux
TCP/IP vers la normalisation. Le groupe qui travaille sur CMOT (CMIP
over TCP/IP) s'est intgr l'OSI sous le nom de OIM (OSI Internet
Management). Son principal rle est de produire un ensemble de
spcifications qui offrent les services CMIS et le protocole CMIP sur des
rseaux de type TCP/IP. L'architecture envisage pour CMOT consiste
rajouter au-dessus des protocoles TCP et UDP une couche prsentation
simplifie LPP (Lightweight Presentation Protocol), les services ACSE,
ROSE, CMIP, et CMIS. Avec CMOT, la relation gestionnaire agent
fonctionne en mode connect et la MIB est constitue d'un ensemble
INT 2004
INT-LOR-GRS-v2.03
24
d'objets comme pour la gestion OSI. Cependant, bien que la dmarche

semble fort intressante, il n'y a pas l'heure actuelle de vritable
implmentation de ce protocole sur les diverses plates-formes
commerciales.
Le modle de communication de
l'IETF
SNMP (Simple Network Management Protocol) est n dans la
communaut Internet des milieux de la recherche et de la dfense
amricaines. Recommand depuis avril 1988 comme Internet Standard
(RFC 1098), SNMP s'est impos comme standard de "fait" pour les
rseaux TCP/IP. Aujourd'hui, il est implant sur les produits de nombreux
constructeurs comme Cisco, Sun, Digital, IBM, Proteon, Hewlett-Pachard,
Unisys, 3COM, etc.
SNMP repose sur une collecte et un change de donnes entre, d'un
ct, des stations d'administration de rseau et, de l'autre, des lments
de rseau grs ou agents. Ces derniers sont des quipements de
rseau tels que les concentrateurs Ethernet, ponts, routeurs, contrleurs
de terminaux, machines serveurs, dans l'environnement TCP/IP. Chaque
lment gr contient une base d'informations de gestion MIB, maintenue
en temps rel. Le protocole SNMP est utilis pour lire, modifier ces
informations, intervenir sur les quipements distance ou signaler
certains vnements en temps rel. Les informations recueillies par la
station d'administration sont stockes gnralement dans une base de
donnes relationnelle. Ces informations peuvent ensuite tre analyses
par des outils tels que les systmes experts ou des outils de
reprsentation graphique.
Le protocole SNMP
Les oprations de gestion de rseau sont architectures en pseudo
transactions "question-rponse" entre la station d'administration et les
agents SNMP. La station de gestion visualise et contrle les quipement
par l'interrogation des agents SNMP. Pour l'obtention d'information de
gestion. Les agents rpondent simplement aux interrogations en
renvoyant ou en changeant les donnes actuelles contenues dans les
MIBs de leurs quipements. Le protocole SNMP possde cinq types de
messages:
trois requtes :
GetRequest (liste d'objets): permet de lire les objets de la MIB.
Emise par le gestionnaire, cette commande est ensuite analyse par
l'agent qui consulte dans la MIB les objets en argument de la primitive
GetRequest. L'agent rpond au gestionnaire par l'envoi d'une primitive
GetResponse contenant la valeur des objets demands.
GetNextRequest (liste d'objets): permet de faire une lecture
squentielle des informations dans la MIB. Cette commande est
particulirement utilise pour la lecture des tables dans la MIB. Aprs
avoir lu un premier enregistrement de la table avec la requte Get ou
GetNext, les autres enregistrements de la table sont lus de manire
squentielle par une srie de GetNext.
INT 2004
INT-LOR-GRS-v2.03
25
SetRequest (liste d'objets et leurs valeurs): permet de modifier des

objets dans la MIB. A la rception de cette commande l'agent met jour
les variables de la MIB partir des valeurs en argument de SetRequest.
Chacune des variables doit tre prcisment indique, et la valeur doit
tre en accord avec la syntaxe de la variable modifier, sinon l'agent
signale une erreur.
une rponse:
GetResponse (liste d'objets et leurs valeurs): c'est la rponse de
l'agent aux primitives GetRequest, GetNextRequest et SetRequest. Sur
chaque requte du gestionnaire, l'agent rpond en utilisant
GetResponse. Cela peut tre une rponse positive (excutant ou
confirmant l'accomplissement de l'opration demande), ou ngative
dans le cas d'erreur.
un message d'vnements:
Trap: c'est une commande spciale non sollicite. Elle est mise par
l'agent vers le gestionnaire sur un vnement particulier spcifi priori.
Le protocole SNMPv2
Les oprations du protocole SNMPv2 sont au nombre de cinq:
GetRequest, GetNextRequest, GetBulkRequest, SetRequest et
InformRequest. Cette dernire a la particularit d'tre gnre d'un
gestionnaire en direction d'un autre gestionnaire pour permettre une
gestion hirarchique ou distribue. Les oprations GetRequest,
GetNextRequest et SetRequest sont identiques celles de mme nom
dfinies dans SNMP version 1. L'opration GetBulkRequest permet de
rcuprer les valeurs d'une suite de successeurs lexicographiques
d'identificateurs d'objets. Elle a le mme effet qu'une suite de message
GetNextRequest, mais la bande passante utilise est fortement rduite.
Dans SNMP version 1, la scurit est ralise par un seul mcanisme qui
prsente certaines faiblesses. Le SNMPv2 a enrichi l'aspect scurit et
fournit des messages SNMPv2 authentifis et encrypts. L'information de
scurit est prsente hors des messages SNMPv2.
En rsum de ce paragraphe, on constate que SNMP est un standard de
fait pour les systmes bass sur les protocoles TCP/IP, alors que CMIP
est standardis par l'ISO. On remarque aussi que sur beaucoup de
points, SNMP et CMIP semblent tre trs proches, mais en fait, ils sont
fondamentalement diffrents (voir tableau 2.1). En effet, on peut dire:
Quils ont le mme objectif: transmettre des informations de gestion
du rseau;
Quils utilisent une base de donnes (la MIB);
Quils possdent les mmes primitives de base (get, set) et la
signalisation d'vnements (Trap pour SNMP, Event pour CMIP).
INT 2004
INT-LOR-GRS-v2.03
26
CMIP/CMIS
SNMP
Mode connect
Mode non-connect
Interface-Objet
Recherche d'une VALEUR
Modification d'une
VALEUR
Interface-Attribut
Recherche d'une VALEUR
Modification d'une
VALEUR
Synchronisation
- atomic
- Best effort
Synchronisation
- Atomic seulement
Possibilit de scoping et
filtering
Non
Gestion par vnement

NOTIFICATION
Gestion par polling

(fort volume de trafic)
Evnements possibles
Actions particulires
possibles sur les objets
Pas de possibilits
d'actions particulires
Requtes et rponses
peuvent inclure des objets
complexes
Requtes et rponses
incluent des valeurs
d'attributs lmentaires
(compteur)
Tableau 2.1: comparaison CMIP/SNMP
Les fonctionnalits de CMIP sont donc plus puissantes que celles de

SNMP (ne pas oublier que le S de SNMP veut dire Simple) car elles
peuvent s'appuyer sur une MIB o les donnes sont agrges: la MIB est
constitue d'un ensemble d'objets et non des attributs simples et des
tables comme dans le cas des MIBs SNMP. En fait l'avantage de la
simplicit de SNMP est amput par son manque de puissance.
INT 2004
INT-LOR-GRS-v2.03
27
Chapitre 3 - Le modle fonctionnel de la

gestion TMN
La dimension fonctionnelle de la gestion de rseau et de service est la
partie centrale des rponses que doit matriser l'administrateur, car elle
reprsente l'ensemble des traitements mettre en uvre pour satisfaire
les demandes de transfert des utilisateurs quelles que soient l'heure, la
journe ou la priode de l'anne. Le rseau doit donc effectuer un
transfert fiable des informations dans les temps de rponse demands.
C'est ce que l'on a dfini comme tant la qualit de service (QoS) dont la
charge revient au systme de gestion. En d'autres termes, pour qu'un
rseau soit oprationnel, il doit se doter d'un systme de gestion pour
contrler ses oprations, surveiller ses performances, grer ses pannes,
ses modifications et ses configurations. Pour ce faire, une structuration
des traitements est ncessaire, un modle fonctionnel doit tre ajout aux
trois autres modles.
Les aires fonctionelles

Gestion de la configuration
Elle recouvre l'ensemble des fonctions de contrle, d'identification, de
collection et de fourniture d'informations sur les objets administrs. Elle a
pour but d'aider la ralisation d'un fonctionnement continu des services
d'interconnexion. La gestion de la configuration permet en effet de
dmarrer, initialiser et arrter le systme, aussi positionner les paramtres
du systme ouvert, recueillir les informations sur l'tat du systme et agir
sur ces tats, enfin modifier la configuration du systme ouvert et associer
les noms aux objets administrs.
Gestion des fautes

La gestion des fautes recouvre l'ensemble des fonctionnalits qui
permettent la dtection, l'isolation et la correction d'une opration
anormale dans un systme. Les fautes proviennent de pannes de
composants matriels ou logiciels. Elles se manifestent par des erreurs
dans le fonctionnement du systme. Ces erreurs peuvent tre passagres
ou persistantes. Lorsqu'une erreur est dtecte, sa localisation et sa
cause doivent tre diagnostiques par une analyse des informations de
l'tat du systme. Aprs le diagnostic, une opration curative est mene
pour permettre une reprise du fonctionnement normal du systme. La
gestion des fautes est une fonction administrative vitale pour assurer aux
utilisateurs un niveau de services satisfaisant du systme.
Gestion des performances

La gestion des performances consiste effectuer des mesures sur le
systme et faire des calculs afin d'valuer le comportement des objets
INT 2004
INT-LOR-GRS-v2.03
28
grs et l'efficacit des activits de communications. Dans le but de

planifier et analyser le systme, elle offre en plus des fonctionnalits
permettant de collecter des donnes statistiques, de maintenir et
d'examiner des journaux sur l'historique de l'tat du systme.
Gestion de la scurit
La gestion de la scurit se compose des fonctions d'administration de
rseaux ayant rapport avec la scurit dans les rseaux de
tlcommunication. Elle permet de faire de l'authentification, le contrle et
la maintenance des autorisations et des contrles d'accs, la gestion des
cls, la maintenance et l'examen des fichiers de scurit.
Gestion de la comptabilit
Elle a pour but d'offrir l'ensemble des fonctionnalits qui permettent
d'tablir les charges et d'identifier les cots relatifs l'utilisation des
ressources gres. Elle permet d'informer les utilisateurs des cots
encourus ou des ressources consommes. Elle fixe des limites
comptables pour l'utilisation des ressources, et combine les cots lorsque
plusieurs ressources sont utilises pour raliser une communication de
donnes.
Comme on l'a indiqu prcdemment, CMISE est un service gnrique
Les Fonctions de gestion

systme
pour la communication d'information de gestion, mais il ne couvre pas
toutes les fonctionnalits. Un ensemble de fonctions de gestion systme
ou SMF (Systems Management Functions) ont t dfinis par les normes
de gestion systme. Chaque SMF est dfinie par un modle et une
dfinition exprime en termes de services CMISE. Chaque SMF dfinit
l'aide de la notation GDMO des objets de gestion spcifis.
Les applications de gestion savoir: gestion des fautes, de la
configuration, des performances, de la scurit et de la comptabilit;
utilisent toutes les services qu'offrent les SMFs (voir figure 4.8). ces
dernires enrichissent les services de CMISE. Les SMF ont t publies
sous forme de norme l'ISO [X730 X750] et reprises par l'ITU-T [X730
X746].
Fonction de gestion d'objets: [X730], elle dfinit des services
gnriques de manipulation d'objet. Elle dcrit les services de cration et
de suppression d'objets grs, d'invocation sur ces objets, de lecture et
de modification d'attribut d'objets. Elle spcifie aussi les notifications
mettre afin de reporter au systme de gestion la cration et la
suppression d'objets, ou encore le changement de valeurs d'attributs
d'objets dans le systme gr.
Fonction de gestion des tats: [X731], elle dfinit les moyens de
contrler l'tat d'une ressource. L'tat de gestion d'un objet est en fait
affect par trois facteurs:
son interoprabilit (tat oprationnel, operational state): indique si la
ressource est ou n'est pas physiquement installe;
son utilisation (tat d'utilisation, usage state): indique si la ressource
est ou n'est pas utilise un instant donn;
INT 2004
INT-LOR-GRS-v2.03
29
son administration (tat administratif, administrative state): indique la

permission ou l'interdiction d'utiliser la ressource de faon logique.
Pour le besoin de la gestion, l'tat d'une ressource est qualifi par
plusieurs attributs dfinis par leurs valeurs et transitions possibles
(comportements), accessibles au moins en lecture. Un type de notification
est dfini pour informer le gestionnaire de ces transitions.
Fonction de gestion des relations: [X732], elle identifie et modlise
les types de relation qui peuvent exister entre objets reprsentant les
diffrentes parties d'un systme. Trois catgories de relations sont
dfinies:
relation de contenance;
relation unilatrale: la relation n'est exprime que dans un des deux
objets lis;
relation rciproque: la relation est exprime dans les deux objets lis
qui peuvent s'identifier mutuellement.
Plusieurs services ont t dfinis afin de grer les relations entre objets,
et donc d'observer les dpendances ou influences que les objets ont les
uns sur les autres.
INT 2004
INT-LOR-GRS-v2.03
30
Applications de gestion
Aires fonctionnelles de gestion

Gestion de
la
configuration
Fonction de
gestion
Gestion des
performances
Gestion des
fautes
Fonction de gestion
des vnements
Fonction de gestion
des journaux
Fonction de
surveillance
de la charge de
travail
des tats
Fonction de
gestion
Fonction de
compteur
Gestion de la
scurit
Fonction de
rsum
de comptabilit
des objets
Fonction de
gestion
Gestion de la
comptabilit
Fonction de test
de diagnostic et
confiance
Fonction de rapport
des relations
D'alarme de
scurit
Fonction de
gestion
Attributs et objets
pour
de rapports
d'alarmes
le contrle d'accs
Fonction de gestion
des tests
Fonctions de
gestion
systme
Fig. 3.1: Relations entre aires fonctionnelles et fonctions de gestion systme
Fonction de gestion des rapports d'alarmes: [X733], elle normalise

des comptes rendus de notification d'un vnement spcifique. Cinq
types d'alarmes sont spcifis par leur smantique et leurs paramtres:
alarme
de
communication
concernant
le
transport
d'information,(exemple: erreur d'tablissement d'appel);
alarme de qualit de service relative la dgradation de la qualit de
service, (exemple: temps de rponse trop long);
alarme de traitement logiciel associe aux fautes de traitement
logiciel, (exemple: erreur de version de logiciel);
alarme d'quipement concernant un faute d'quipement ( exemple:
problme d'alimentation);
INT 2004
INT-LOR-GRS-v2.03
31
alarme d'environnement relative l'entourage de l'quipement (

exemple: dtection d'intrusion).
Fonction de gestion des rapports d'vnements: [X734], elle doit
permettre aux systmes de gestion de:
slectionner les rapports d'vnements notifier;
spcifier le ou les gestionnaires destinataires;
suspendre et reprendre l'activit d'envoi des rapports;
modifier les modalits d'envoi des rapports.
Cette fonction s'appuie sur un objet particulier, le discriminant de rapport
d'vnement qui permet:
la slection des notifications locales qui doivent faire l'objet de
rapports d'vnement relatifs un objet ou un ensemble d'objets
(rle de filtre);
la dtermination des destinataires des rapports.
Fonction de gestion des journaux: [X735], elle dfinit le service pour
la mmorisation des notifications d'vnement dans des enregistrements
(log record) et journaux (log). Ce service permet de:
slectionner les enregistrements insrer dans un journal;
modifier les critres d'enregistrement;
rechercher et supprimer des enregistrements;
initialiser et supprimer des journaux, etc.
La fonction de contrle de journal s'appuie sur deux classes d'objets
supports:
la classe journal qui modlise les ressources de mmorisation;
la classe enregistrement de journal qui modlise les enregistrements
mmoriss dans un journal.
Fonction de rapport d'alarme de scurit: [X.736], elle offre des
services de dtection et de notification, identiques ceux fournis par la
fonction de gestion d'alarme, mais relatifs aux vnements de scurit.
Cinq types d'alarmes sont spcifis:
violation d'intgrit due par exemple une information perdue;
violation oprationnelle produite, par exemple, la suite d'un refus
ou d'une indisponibilit de service;
violation physique qui peut dcouler d'une dtection d'intrusion;
violation de service suite par exemple un problme
d'authentification;
violation de plage horaire si une activit est effectue hors plage
horaire.
Autres fonctions de gestion:
La fonction d'audit de scurit [X.740] fournit un service de notification de
rapports de scurit. Elle permet l'enregistrement d'vnements de
scurit.
La fonction attributs et objets pour le contrle d'accs [X.741] permet un
systme de gestion de domaine de contrler les accs aux ressources de
gestion.
La fonction compteur de comptabilit [X.742] dfinit un service de collecte
de donnes relatives l'utilisation des ressources OSI et un service de
contrle de cette collecte pendant et aprs utilisation de la ressource.
INT 2004
INT-LOR-GRS-v2.03
32
La fonction de surveillance de la charge de travail [X.739] fournit les outils

permettant de dtecter au plus vite les problmes de manque de
ressources, avant que les effets ne s'en fassent ressentir au niveau des
utilisateurs.
La fonction de gestion des tests [X.745] permet de grer les tests sur les
systmes rels et sur les ressources OSI en gnral. Chaque test
ncessite la cration d'un environnement de test, le contrle et la
surveillance du systme durant le test, et le retour aux conditions
normales.
La fonction de rsum [X.738] concerne la collecte et l'agrgation des
informations (exemples: mesures de dbit de temps de rponse, de
disponibilit, etc.) pendant des intervalles de temps dfinis.
La fonction de test de diagnostic et de confiance [X.737] des catgories
de tests dits de diagnostic et de confiance qui permettent d'tudier
l'aptitude d'une ressource rendre les services pour les quels elle est
prvue.
Conclusion
Le modle informationnel a prpar les donnes, le modle architectural
et celui de la communication ont dlimit l'environnement de travail pour
effectuer les traitements, quant au modle fonctionnel, il a regroup les
applications que l'administrateur a en charge pour rpondre aux besoins
et pour maintenir le rseau dans un tat oprationnel. Ceci pour les deux
systmes de gestion, savoir celui du TMN (CMIP) et celui de l'IETF
(SNMP). SNMP rpond rapidement aux besoins mais manque de
puissance; CMIP est plus puissant smantiquement mais pose le
problme de ne pouvoir tre prsent sur tous les quipements.
INT 2004
INT-LOR-GRS-v2.03
33
Chapitre 4 - Larchitecture agent-manager
Introduction
Les systmes de gestion de rseaux sont tous construits sur deux entits
fondamentales: le manager et lagent. Ce chapitre va tenter de clarifier
leurs proprits et leurs fonctions.
Selon larchitecture OSI, les managers et les agents sont des composants
applicatifs, cest--dire situs en couche 7. Comme on la vu dans le
chapitre 2, ils sappuient sur les services de la couche 7: ROSE/ACSE
pour la session scurise, et sur les services SMASE (Systems
Management Application Service Entities).
Dans le cadre IETF, le manager est une application utilisant UDP comme
protocole de transport (cest dailleurs un reproche frquent, car la fiabilit
est laisse lapprciation de lapplication).
Un manager est un composant assumant un certain nombre de fonctions
de gestion (des Systems Management Functions) adressant des besoins
du systme de gestion global. Pour ce faire, le manager procde
lmission de requtes lagent. Ces requtes sappuient sur un certain
protocole qui est CMIS/P pour le TMN, et SNMP dans le cadre de lIETF.
Lagent dispose de lensemble de linformation ncessaire pour rpondre
aux requtes. Cette information est stocke dans une MIB (Management
Information Base). Lorsque lagent reoit une requte, il consulte sa MIB
et rpond au manager avec la ou les valeurs demandes. Ce schma
fondamental est illustr par la figure 4.1:
requtes
MIB
manager
rponses
Fig. 4.1: les entits manager et agent
Les protocoles
Il est utile dexaminer dun peu plus prs les protocoles mis en uvre par
les managers et agents tant TMN quIETF.
La dynamicit
INT 2004
En TMN, le protocole CMIP assure une communication totalement

asynchrone: la requte est envoye la vole, et le manager nattend
INT-LOR-GRS-v2.03
34
pas la rponse (requte non bloquante). Lagent et le manager grent

des files de requtes numrotes. Lorsque lagent, plus tard, expdie
sa rponse, le manager r-tablit lassociation avec larchive de la
requte qui correspond. Le TMN fournit un concept unifi pour la
communication de lagent: les notifications. Ces dernires transportent
tant les rponses des requtes, que des informations gnres
spontanment comme des alarmes. Les notifications confrent aux
systmes TMN une grande dynamicit.
Pour lIETF, la requte SNMP est synchrone cest--dire bloquante: le
manager reste en attente de la rponse. Ceci est parfois risqu dans
la mesure o le protocole sous-jacent est UDP. Si le paquet UDP se
perd, le manager risque de se trouver bloqu. Par ailleurs SNMP ne
prvoit pas de mcanisme de notification. Les alarmes envoyes par
lagent se servent dun paquet SNMP particulier, le Trap.
Les requtes
Cas de CMIP
En TMN, cinq types de requtes existent: get, set, create, delete,
action.
Get permet de lire une valeur dattribut;
Set est lopration dcriture;
Create est lopration dinstantiation dune MOC (Managed Object

Class) pour obtenir un nouvel objet (Managed Object ou MO) peuplant
la MIB;
Delete efface une instance de MO;
Action est un message de dclenchement dune mthode de MO.

La forme gnrale de la requte est:
<request>(fdn, oid, type, scope, filter)
Le fdn est le Full Distinguished Name de lobjet atteindre (voir la
section 3.3) dans la MIB.
LOID de lobjet atteindre est lObject Identifier tel que dfinit par lITU-T
pour cet objet. En effet les modles dinformation standard tant dposs
publiquement lITU-T, cette dernire confre un identifiant unique tout
objet le dsignant de faon universelle.
Le type de la requte peut tre best effort ou transactional . Dans
ce dernier cas lagent assure des proprits ACID (cf. cours de bases de
donnes).
Le scope est la profondeur de la requte, partir de lobjet dsign par le
fdn. Un scope de 1 restreint la requte lobjet lui-mme. Un scope
any amplifie la requte tout le sous-arbre constitu par lobjet
dsign.
Le filter permet de spcifier des conditions sur les objets. Ainsi, on
peut vouloir lire uniquement les attributs dobjets ayant leur attribut
AdministrativeState positionn available .
Cas de SNMP
SNMP reprend les principes prcdents en les simplifiant. Il ny a que les
requtes get et set. La forme gnrale de linvocation est:
<request>(oid, value)
INT 2004
INT-LOR-GRS-v2.03
35
On note labsence de mcanismes de cration/dltion: la MIB SNMP est

totalement statique.
Par ailleurs lagent possde une mthode denvoi dalarmes par le paquet
spcial Trap .
Structure de linformation
La structure de la MIB diffre grandement selon larchitecture considre,
TMN ou SNMP.
Cas du TMN
Les MOs du TMN sont structurs selon le standard X.400, cest--dire
selon une arborescence. La MIB TMN est ainsi capable daccueillir un trs
grand nombre de MOs (de lordre de 10E6 pour des quipements SDH ou
WDM) sans difficult.
Le FDN (full distinguished name) dun MO est le chemin daccs de lobjet
partir de la racine de la MIB. Le FDN est constitu dune liste de
prdicats attribut-valeur permettant une grande flexibilit de
nommage, similaire ce que propose LDAP qui repose sur des standards
identiques.
Cas de SNMP
Pour SNMP, linformation est statique et structure de faon linaire ou
tabulaire. Le nommage de lobjet est effectu par lOID. Les MIBs sont de
structure totalement statique.
Le Frame
Linteraction entre le manager et lagent mrite une analyse
supplmentaire. En effet, il est utile de considrer non seulement la
double entit manager-agent, mais galement ce qui est sous-jacent
lagent, savoir la ressource gre.
En effet, les spcifications du TMN ou de lIETF mettent en uvre des
mcanismes de gestion abstraits dans le but dtre indpendant du
vendeur de matriel. Le problme est que cette dmarche induit une
distance smantique arbitraire entre le cycle de vie des objets de gestion,
et le cycle de vie du matriel gr. Un exemple: la mise en uvre dune
cross-connection dans une matrice SDH se fait en une seule opration
CMIP alors quil sagit probablement de nombreuses et dlicates
interactions au niveau des composants lectroniques (CPU, registres de
commande) du matriel SDH.
La figure 4.2 prsente le frame, cest--dire la triade associant le
manager, lagent et la ressource.
Cette reprsentation illustre le propos: en fait cest limplmentation des
MOs, cest--dire le logiciel qui ralise les fonctions lies aux attributs et
aux actions du MO, qui prend en charge la distance smantique entre
linteraction protocolaire CMIP ou SNMP, et le cycle de vie des
ressources gres i.e. les cartes lectroniques du matriel de
lquipement.
INT 2004
INT-LOR-GRS-v2.03
36
manager
Interaction CMIP/SNMP
agent
MIB
implmentation
Ressources
gres
Fig. 4.2: le frame
Une difficult supplmentaire, dans ce contexte, est que souvent le

matriel est sujet de multiples variations (amliorations, volutions) qui
rendent ncessaire lcriture de nombreuses versions du logiciel de
lagent. On comprend ici pourquoi un agent, en particulier TMN (mais
SNMP galement, dans une moindre mesure) est une entit onreuse et
complexe tant dans son cot de dveloppement, que dans sa
maintenance.
Pour conclure cette section, considrons maintenant les caractristiques
de linformation de gestion en termes de rpartition et de cycle de vie.
Par dfaut, la rpartition de linformation telle que prsente dans ce
chapitre est telle que toute linformation est maintenue dans lagent, le
manager tant virtuellement vide dinformation2. Mais cette rpartition estelle optimale ? Elle induit ncessairement le dclenchement systmatique
dune requte chaque besoin du manager, et donc une forte
consommation de bande passante du rseau de gestion (DCN).
Une alternative consisterait mettre en uvre une mmoire tampon ou
cache, dans le manager. Mais le cycle de vie de linformation est
considrer dans ce contexte. Classifions les MOs selon ce cycle de vie:
Les objets permanents sont les MOs invariables dans le temps (cest-dire dune dure de vie suprieure la dure de la session du
systme de gestion). Couramment il sagit de la configuration
systme, de la version du logiciel, du nom du vendeur etc.
Les objets phmres sont des MOs nayant de signification qu
linstant o ils sont lus. Il sagit par exemple des valeurs de compteurs
de performance (nombre de collisions, de paquets perdus etc).
2
Linformation a minima vitale dont le manager a besoin est bien sr ladresse de

lagent.
INT 2004
INT-LOR-GRS-v2.03
37
Une troisime catgorie est celle des objets ni permanents, ni

phmres. Ces objets ont une variabilit intermdiaire, sans que lon
puisse la caractriser de faon plus prcise.
Une gestion habile dun cache consisterait allouer les objets
permanents au cache dans tous les cas, et ne jamais utiliser le cache
pour les objets phmres. Les objets intermdiaires quant eux, doivent
faire lobjet dun compromis. Le savoir-faire de lingnieur mettra en
uvre une stratgie prudente en ne les plaant jamais dans le cache,
quitte consommer davantage de bande passante en requtes. Une
stratgie hardie consistera prendre un certain risque lire ces objets
partir du cache, quitte ce que leur valeur soit parfois fausse.
Cest dans la recherche de tels compromis que lon obtient, au bout du
compte, un systme efficace malgr sa complexit.
INT 2004
INT-LOR-GRS-v2.03
38
INT 2004
INT-LOR-GRS-v2.03
39
Chapitre 5 - TMN, le rseau de gestion

des tlcommunications
Introduction
La nature des informations vhiculer travers les rseaux ne cesse pas
de se diversifier. Des applications comme la tlphonie publique munie
des services de rseau intelligent, la radiotlphonie mobile, la
transmission de donnes faible et haut dbit, des images fixes ou
animes, de la voix amnent les exploitants grer une varit
toujours plus grande de rseaux. Mais dans chaque cas, il sagit
dexploiter et dentretenir des quipements de commutation et de
transmission, ainsi que damliorer les fonctions grant les nombreux
services volus que les usagers et les fournisseurs de services
rclament sans cesse.
Dfinition du TMN
Le TMN (Telecommunication Management Network), le rseau de gestion
des tlcommunications, a pour but de rpondre aux exigences
dexploitation, dadministration et de maintenance des rseaux de
tlcommunications de tout type de technologie. Il prsente lavantage de
se situer dans un contexte multi fournisseurs. En effet, le TMN tient
compte de la diversit des quipements de tlcommunication et de celle
des centres informatiques qui les grent. Il permet galement
lexploitant du rseau de dvelopper de nouvelles applications de gestion
tout en sadaptant lorganisation de son rseau.
Ce chapitre prsente le TMN et ses aires fonctionnelles ainsi que ses
architectures informationelle, fonctionnelle et physique.
Une application de gestion de rseau est gnralement compose de
plusieurs agents rpartis sur l'ensemble du rseau surveiller. Pour
coordonner leurs actions, ces agents communiquent travers un rseau
de transmission de donnes appel le Data Communication Network
(DCN). Dans le cas du TMN, le rseau de gestion des
tlcommunications (Telecommunication Management Network), il est
fourni une structure de rseau pour interconnecter des systmes
d'exploitation et des quipements normaliss. Les relations et la situation
du TMN vis--vis du rseau sous son contrle sont illustres par la figure
5.1:
INT 2004
INT-LOR-GRS-v2.03
40
Rseau de transmission de
donnes (DCN)
Rseau de tlcommunications
Fig. 5.1: relation entre rseau de gestion et rseau gr
Cette figure montre trois parties essentielles:

Les lments de rseau de tlcommunication se composent
essentiellement des commutateurs, qui sont des quipements forte
composante logicielle, et des quipements de transmission.
Des postes de travail qui communiquent avec les systmes de gestion
et les lments de rseau.
Le rseau de transmission de donnes reliant les lment de rseau
aux systmes de gestion (Data Communication Network ou DCN).
Le TMN apparat sur la figure 5.1 distinct du rseau qu'il contrle, ce qui
n'est vrai que sur le plan logique. En effet, les deux rseaux physiques ne
sont pas totalement spars. Ainsi, un rseau ATM se sert des canaux
OAM pour la gestion, tandis que la SDH met profit les octets de gestion
rservs cet effet dans les en-ttes des trames. A linverse, des
quipements divers peuvent tre amens tre grs par une voie IP
distincte du rseau de transmission, et cest le cas des infrastructures
fixes des rseaux GSM.
Fonctions de gestion offertes par

le TMN
Afin de fournir aux usagers des services avec un certain niveau de qualit
et de cot, le TMN recouvre l'ensemble des activits de surveillance,
d'analyse, de contrle et de planification du fonctionnement des
ressources d'un rseau de tlcommunication. Dans cette optique, le
TMN s'appuie sur cinq aires fonctionnelles (voir chapitre 2) appeles
aussi SMFA (Systems Management Functional Area) ou classiquement
les fonctions FCAPS:
INT 2004
INT-LOR-GRS-v2.03
41
la gestion des fautes (F);

la gestion de la configuration (C);
la gestion de la comptabilit (A = accounting).
la gestion des performances (P);
la gestion de la scurit (S).
Architecture du TMN
L'ITU-T dcoupe l'architecture gnrale du TMN selon trois vues
[M.3010]. Elles peuvent tre considres sparment lors de la
conception et de la planification d'un TMN, ce sont:
l'architecture informationnelle du TMN,
l'architecture fonctionnelle du TMN,
l'architecture physique du TMN.
L'architecture informationnelle permet de reprsenter les ressources
disponibles sur le rseau de tlcommunications supervis. Pour ce, elle
utilise des donnes pour les besoins de surveillance, de contrle et de
gestion. L'architecture fonctionnelle dcrit la mise en uvre d'un TMN
partir des diffrentes catgories de blocs de fonctions et des diffrentes
classes d'interconnexion entre ces blocs. Quant l'architecture physique,
elle dcrit la ralisation des fonctions du TMN en termes de composants
physiques et d'interfaces pour la communication.
Architecture informationnelle du TMN

Elle a pour rle de modliser les ressources du rseau. Elle utilise
l'approche oriente objet pour mettre en uvre le modle d'information du
rseau. L'architecture informationnelle dfinit aussi des couches de
gestion qui correspondent des niveaux o des dcisions doivent tre
prises et o rsident les informations de gestion travers un modle
informationnel. Ces couches sont purement logiques car il n'y a pas de
mise en correspondance au niveau d'une implantation physique du TMN.
Des composants qui rsident logiquement dans deux couches diffrentes
peuvent se trouver intgrs dans le mme composant physique.
Architecture logique en couches

Les couches dfinies dans la recommandation M.3010 sont:
couche lment de rseau,
couche gestion d'lment de rseau,
couche gestion de rseau,
couche gestion de service,
couche commerciale.
La couche lment de rseau ou NEL (Network Element Layer) ralise
les fonctions de gestion de base fournies par les quipements du rseau.
Parmi ces fonctions on trouve la collecte d'informations de performance,
la collecte d'alarmes et l'auto-diagnostic.
La couche gestion d'lment de rseau ou EML (Element Management
Layer) assure la gestion individuelle de chaque lment du rseau. Elle
fournit une abstraction des fonctions offertes par la couche NEL afin de
garantir l'indpendance vis vis des constructeurs.
INT 2004
INT-LOR-GRS-v2.03
42
La couche gestion de rseau ou NML (Network Management Layer) gre

l'ensemble des lments du rseau tels qu'ils lui sont prsents par la
couche EML. Cette gestion peut tre faite individuellement ou en tant
qu'ensemble. Les fonctions de la couche NML ont pour but de supporter
des applications de gestion qui requirent une vue de bout en bout du
rseau de tlcommunications. En recevant les informations de la couche
EML, la couche NML cre une vue globale de l'ensemble du rseau
indpendante de toute technologie du rseau.
La couche gestion de service ou SML (Service Management Layer) se
charge de la gestion des services offerts aux clients tout en utilisant le
service de facturation et en assurant un certain niveau de qualit de
service. Elle peut tre dcompose en deux sous-couches: celle de la
"gestion des services de base" qui sont fournis par le rseau et celle de la
"gestion des services valeur ajoute" qui sont offerts par des
fournisseurs de services autres que l'oprateur du rseau.
La couche gestion commerciale ou BML (Business Management Layer)
assume la responsabilit qui se rapporte la totalit de l'entreprise. Elle
tablit les accords entre oprateurs et supporte la planification
stratgique.
Exemple: architecture logique en couche du service VPN dans un

rseau ATM
Cet exemple dcrit l'architecture logique rpartie en couches pour la
fourniture d'un service de rseau priv virtuel large bande ou BVPN
(Broadband Virtual Private Network). Plus prcisment, dployer un
rseau priv virtuel sur un rseau ATM.
Un rseau priv virtuel est un rseau priv logique et non pas physique. Il
se compose de ressources virtuelles qui reprsentent une abstraction des
ressources physiques. Un VPN peut tre vu simplement comme un
rseau constitu de liens logiques entre les diffrents sites distants d'une
mme organisation en utilisant le RTC (Rseau Tlphonique Commut)
et lADSL, cf. figure 5.2. En plus du fait d'offrir aux entreprises des
communications longue distance performantes, les clients du VPN
peuvent grer leur rseau virtuel en changeant dynamiquement sa
configuration, ils peuvent rajouter ou librer des liens logiques entre leurs
rseaux privs locaux se trouvant sur leurs sites.
INT 2004
INT-LOR-GRS-v2.03
43
RTC
Rseau
de
lentreprise
CAP
CPN: Rseau priv local (Customer Premises Network)

VPN: Rseau priv virtuel (Virtual Private Network)
CAP: Point d'accs usager (Customer Access Point)
CPN
CPN
CPN
Fig. 5.2: configuration dun VPN
Dans la rpartition en couches on trouve les commutateurs du rseau

ATM (Asynchronous Transfer Mode) grer dans la couche NEL
(lment de rseau) comme dcrit dans la figure 5.3. Ils fournissent un
service d'tablissement, de maintien et de libration de la connexion par
la gestion.
La couche EML contient les gestionnaires d'lments de rseaux qui
fournissent une abstraction de la connectivit l'intrieur des
commutateurs ATM. Ils offrent galement un service de gestion de cette
connectivit.
La couche NML offre grce au systme de gestion de l'oprateur impliqu
dans la fourniture du BVPN une vue abstraite de la connectivit de bout
en bout l'intrieur du RTC et le service de gestion associ (service de
gestion des connexions).
La couche SML offre le service de configuration du VPN au client. Pour ce
faire, la couche SML s'appuie sur les services de la couche NML, et cette
dernire utilise le service de gestion des connexions offert par la couche
EML, tout ceci en cascade.
INT 2004
INT-LOR-GRS-v2.03
44
Fonctions commerciales: planification, marketing, etc.
Gestionnaire du service de rseau priv virtuel
Gestionnaire de rseau de l'oprateur
Gestion d'lment de rseau
Processus Agent
Elment de rseau
ATM
Fonc
Fonction de support
tion
d'l
ment
Fig. 5.3: Exemple d'architecture logique en couches
Dans chaque couche de gestion existe un modle d'information qui fournit

une abstraction des ressources. A ce propos, l'ITU-T a propos dans la
recommandation M.3100 un modle informationnel gnrique de rseau
de tlcommunication appel GNIM (Generic Network Information Model).
Il offre grce sa gnricit l'avantage d'tre indpendant d'une
technologie de rseau particulire; il peut donc tre utilis dans
diffrentes technologies comme l'ATM, FrameRelay, SDH, PDH, RNIS,
etc. Le modle peut tre vu comme un ensemble de classes rutilisables
pour la gestion d'un rseau de tlcommunication. Le modle a pour but
de couvrir toutes les couches logiques du TMN, mais dans son tat actuel
il est applicable principalement la couche EML. Le GNIM s'appuie sur le
modle informationnel de gestion dfini par le TMN (voir chapitre 4) et sur
le modle de rfrence de la recommandation G.803 pour le SDH dfini
par l'ITU-T et dont il reprend les concepts d'organisation en couches et de
subdivision.
Architecture fonctionnelle du TMN

Pour grer un rseau de tlcommunication, les applications de gestion
doivent rsider sur des composants (quipements) rparties
gographiquement. Il faut donc dfinir des procdures pour la
communication entre ces applications rparties. Ceci est dautant plus vrai
que l'environnement des tlcommunications est par nature vari. Il y a
notamment des relations inter-oprateurs et des environnement multifournisseurs. Il est donc obligatoire de dfinir des procdures normalises
pour ces applications. Ceci est notamment l'objectif de la dfinition de
INT 2004
INT-LOR-GRS-v2.03
45
l'architecture fonctionnelle du TMN. A cet effet, elle se compose en un

ensemble de blocs de fonctions et points de rfrence entre ces blocs.
Blocs de fonctions et points de rfrence

Un bloc de fonctions est un groupement de fonctions conues pour des
tches bien spcifiques relatives au transport et au traitement des
informations de gestion. Il en a six dans l'architecture fonctionnelle du
TMN:
fonction de systme d'exploitation ou OSF (Operation System
Function),
fonction de mdiation ou MF (Mediation function),
fonction poste de travail ou WSF (Work Station Function),
fonction d'lment de rseau ou NEF (Network Element Function).
fonction d'adaptateur Q ou QAF (Q Adaptor Function),
fonction rseau de communication ou DCF (Data Communication
Function) (voir figure 5.4).
TMN
WSF
OSF
MF
QAF
NEF
Fig. 5.4: les blocs fonctionnels du TMN
Le bloc OSF reprsente l'application de gestion. Il gre les ressources

de tlcommunication en traitant les informations de gestion.
Le bloc NEF reprsente pour chaque lment de rseau l'ensemble
des fonctions disponibles sur cet lment et qui assurent sa gestion. Le
NEF communique donc avec le TMN pour le grer. La MIB et toute
application de gestion associes au NEF sont considres comme faisant
partie du TMN, le reste des lments de ce bloc fonctionnel ne le sont
pas.
Le bloc WSF offre les moyens d'interprter et de prsenter l'information
du TMN au gestionnaire humain. Il tablit donc le dialogue entre
l'administrateur rseau et les blocs OSF. L'administrateur et l'interface
utilisateur ne font pas partie du TMN.
Le bloc MF facilite la communication en jouant un rle de mdiation
comme son nom l'indique. En effet, il agit sur l'information passant entre
une fonction OSF et une fonction NEF ou une fonction QAF. Pour ce, il
comprend:
une fonction de conversion d'information qui traduit un modle de
donnes en un autre et modifie ainsi le contenu des messages
d'information de gestion.
une fonction de conversion de protocole qui traduit un protocole en
un autre.
INT 2004
INT-LOR-GRS-v2.03
46
et ventuellement des fonctions complmentaires comme: le stockage

d'information, le filtrage, la condensation d'information, etc.
Le bloc QAF permet de relier des entits non-TMN au TMN. Pour cela, il
assure une traduction entre un point de rfrence du TMN et un point de
rfrence non-TMN. Plus prcisment, il connecte au sein d'un TMN des
entits n'ayant pas des interfaces conformes aux interfaces normalises
par le TMN aux rles des blocs OSF et NEF. Ces entits jouent
gnralement le rle de systme d'exploitation.
Le bloc DSF permet d'changer des informations de gestion entre les
diffrents blocs fonctionnels. Ceci par la fourniture des moyens de
communication de donnes qu'utilisent ces blocs. Il effectue des
transferts d'informations entre les blocs de fonctions. Il correspond aux
services offerts par les couches basses du modle OSI. La fonction DCF
peut par exemple tre ralise par un rseau X.25, c'est pour cela qu'elle
n'apparat pas sur la figure 4.4.
Entre les blocs fonctionnels existent des points de rfrence y assurant
l'interaction fonctionnelle et/ou le passage d'informations. Ce sont des
points conceptuels qui interconnectent les blocs fonctionnels. Ce sont en
quelque sorte des interfaces entre applications puisqu'ils dcrivent les
frontires de services entre les diffrents blocs. Il existe trois types de
points de rfrence TMN: q, f et x.
Les points de rfrence q connectent soit directement soit via le bloc de
fonction DSF (fonction de communication de donnes) les blocs de
fonctions NEF et OSF, NEF et MF, MF et MF, QAF et MF, MF et OSF, et
OSF et OSF. Dans le type q on distingue deux sous-types, qx et q3 (voir
figure 5.5).
Les points de rfrence qx se situent entre les blocs NEF, QAF ou MF et
MF alors que les points de rfrence q3 se trouvent entre les blocs NEF,
QAF ou MF et OSF.
Les points de rfrence f prennent place entre les OSFs les WSFs et
WSF et MF. Ils tablissent gnralement l'interface X-windows travers
laquelle l'administrateur interagit avec les fonctions du TMN.
WSF
WSF
TMN
MF
QAF
OSF
NEF
TMN
MF
OSF
QAF
NEF
Fig. 5.5: Points de rfrence entre les blocs de fonctions TMN
INT 2004
INT-LOR-GRS-v2.03
47
Les points de rfrence x servent relier deux OSFs de deux TMNs

diffrents, en d'autres termes interconnecter deux oprateurs diffrents.
Ils peuvent galement relier un OSF d'un TMN une fonctionnalit
quivalente de type OSF d'un autre rseau. Vue la position critique de
ces points, ils sont obligs de prsenter des attributs de scurit.
Les points g et m sont des points de rfrence externes au TMN. Les
points de rfrence g se situent entre l'oprateur humain et le bloc WSF.
Par contre, les points de rfrence m relient les QAFs des entits nonTMN ou non conformes aux recommandations TMN.
L'ensemble des dfinitions de blocs de fonction et de points de rfrence
constitue un modle de rfrence du TMN. Les fonctionnalits logiques
de tout TMN peuvent tre dcrites travers un schma de configuration
de rfrence (voir figure 5.5) avec des arrangements de blocs de
fonctions et de points de rfrence.
NB: Il faut noter que ce sont les interfaces qui sont normalises et non les
blocs fonctionnels du TMN.
Exemple du cas de la gestion du service VPN dans un rseau ATM

Dans cet exemple on verra l'architecture fonctionnelle de la gestion de la
configuration d'un service rseau priv virtuel large bande (BVPN).
A la couche NEL (voir figure 5.6), les blocs NEF reprsentent l'ensemble
des fonctions offertes par les commutateurs ATM afin d'assurer leur
propre gestion.
La couche EML comporte des blocs OSF et des blocs MF. Les OSFs
grent et prennent en charge l'abstraction de la fonction de connectivit
fournie par la couche NEL. Les blocs de fonction MF jouent leur rle de
mdiation en prenant leur emplacement logique dans la couche EML.
INT 2004
INT-LOR-GRS-v2.03
48
Domaine fournisseur de
service VPN
BML
SML
WSF
OSF
D
o
m
NML
D
o
m
OSF
OSF
OSF
OSF
OSF
OSF
MF
MF
MF
MF
NEF
NEF
NEF
NEF
EML
Fig. 5.6: Exemple d'architecture
La couche NML se compose d'un bloc OSF qui prend en charge un

domaine d'oprateur de rseau. Le bloc OSF donne une vision unifie et
gre les capacits du rseau afin de supporter le service VPN offert au
client. L'interface entre les blocs fonctionnels OSF de la couche NML et
les blocs fonctionnels de la couche EML se fait en un point de rfrence
q3.
A la couche SML, le bloc OSF fournit le service de gestion de
configuration de VPN ses clients. Le dialogue entre le client et l'OSF se
fait travers le bloc WSF. L'OSF de la couche SML est subdivis en deux
parties dont l'une fait partie de la couche NML. Cette partie gre des
connexions de sous-rseau, alors que l'autre dans la couche SML gre
des liens logiques entre les diffrents sites distribus du client. L'interface
entre le bloc fonctionnel de la couche SML et ceux de la couche NML se
fait en un point de rfrence x, car dans la configuration choisie, le service
est offert par un fournisseur de services valeur ajout ou VASP (Value
Added Service Provider).
Dans la couche BML, l'OSF interagit avec l'OSF de la couche SML via un
point de rfrence q3. Il se charge par exemple des tches de fixation
d'objectifs.
Echanges et protocoles de gestion

La spcification ITU-T des points de rfrence q et x se base sur les
normes de gestion OSI relatives au modle gestionnaire-agent [X701], les
services CMISE [X710] et le protocole CMIP [X711], pour plus de dtails,
se rfrer au chapitre 4 o tous ces lments sont prsents.
INT 2004
INT-LOR-GRS-v2.03
49
Architecture physique du TMN

L'architecture physique correspond la ralisation physique de
l'architecture fonctionnelle. Chaque bloc fonctionnel devient un ou
plusieurs blocs physiques remplissant certaines fonctions. Le TMN est
alors vu comme un ensemble de blocs physiques connects, chacun
excutant un ensemble de fonctions du TMN. Lorsque les blocs de
fonctions connects sont raliss dans des quipements diffrents, un
point de rfrence devient une interface. Dans la nomenclature TMN, les
noms des points de rfrence apparaissent en lettres minuscules alors
que les interfaces ont leur nom en lettres capitales. Le TMN propose une
interface pour chaque point de rfrence.
Les blocs physiques

Chaque bloc de fonction est ralis par un ou plusieurs blocs physiques
comme suit:
Le systme d'exploitation ou de gestion ou OS (Operation System) ralise
les fonctions de l'OSF.
Le rseau de communication de donnes ou DCN (Data
Communication Network) ralise les fonctions du bloc fonctionnel
DCF. Le DCN est un rseau de communication l'intrieur d'un TMN
qui fournit le support de communication pour les informations de
gestion. Il reprsente une forme de mise en uvre des couches 1 3
du modle de rfrence OSI. Ce rseau ne fournit aucune
fonctionnalit des couches 4 7.
L'lment rseau ou NE (Network Element) ralise les fonctions NEF.
Il est l'unique quipement rsidant dans le rseau de
tlcommunication gr. Son rle principal est de prendre en charge
le trafic et non la gestion. Mais il est l'lment sur lequel sont effectus
la supervision, le contrle et la gestion.
Le poste de travail ou WS (Work Station) est le systme qui excute
les fonctions WSF. Il s'agit d'un terminal connect l'OS ou la
fonction de mdiation travers le DCN.
L'adaptateur Q ou QA (Q Adaptor) est un dispositif utilis pour
connecter au TMN un quipement ne prsentant pas l'interface de
type Q. l'adaptateur Q ne ralise que des fonctions d'adaptation
d'interface Q.
L'quipement de mdiation ou MD excute les fonctions MF. Ce
dispositif peut ventuellement fournir les fonctions OSF, QAF et WSF.
L'quipement MD peut tre mis en uvre sous forme de hirarchie de
dispositifs en cascade.
Le tableau 5.1 rsume la correspondance entre nuds du TMN et blocs
de fonctions:
Nuds TMN
Blocs de fonction
Systme d'exploitation (OS)
OSF
Dispositif de mdiation (MD)
MF
Adaptateur Q (QA)
QAF
Elment de rseau (NE)
NEF
Poste de travail (WS)
WSF
Tableau 5.1: Equivalences entre nuds TMN et blocs de fonctions
INT 2004
INT-LOR-GRS-v2.03
50
Les interfaces
Les interconnexions des nuds OEs, OSs, WS, QAs, et MDs travers le
rseau de transmission de donnes (DCN) sont ralises par des
interfaces normalises. Ces interfaces garantissent l'interoprabilit entre
systmes interconnects afin d'accomplir une fonction de gestion de TMN
donne. Il est donc ncessaire demployer des protocoles de
communication compatibles avec des dfinitions de messages gnriques
indpendantes des types d'quipements. L'interface Qx sert pour la
connexion entre NEs et MDs, alors que l'interface Q3 est utilise pour
connecter les NEs aux OSs.
Les protocoles utiliss aux interfaces Q sont dcris dans la
recommandation G.733 de l'ITU-T. Cette dernire recommande deux
suites de protocoles pour relier des quipements de transmission un
TMN: les suites de protocoles piles rduites A1 et A2 essentiellement
utilises comme suite de protocoles Qx et les suites de protocoles piles
compltes de 7 couches pouvant tre utilises pour Qx et Q3.
Dans le cas des protocoles de type A, les couches 4, 5 et 6 du modle de
rfrence OSI sont utilises de faon transparente. Ces protocoles sont
adapts pour des quipements de complexit moyenne. Dans le cas des
protocoles piles compltes, les couches 1, 2 et 3, sont dfinies dans la
recommandation Q.811 [Q.811] alors que les couches 4, 5, 6 et 7 sont
dfinies dans la recommandation Q.812 [Q.812]. Un rseau de transport
X.25 peut tre mis en place pour fournir les couches basses 1, 2 et 3. Les
potentialits du canal D du RNIS peuvent tre mises profit. Enfin, les
facilits de transport offertes par le canal smaphore CCITT n7 peuvent
tre considrs. A la couche 7, il est fait rfrence CMISE/CMIP pour
les services de type transaction, et FTAM (File Transfer, Access and
Management) pour les services de type de transfert de fichier.
L'interface X est applique au point de rfrence x. Elle est utilise pour
l'interconnexion entre deux TMNs ou entre un TMN et un rseau
possdant une interface de type TMN. L'interface X est base sur
CMISE/CMIP avec des lments de scurit.
L'interface F permet le raccordement de divers terminaux au TMN. Le
tableau 5.2 donne les quivalences entre interfaces et points de
rfrence:
Interfaces TMN
Points de rfrence TMN
Q3
q3
Qx
qx
x
Tableau 5.2: Equivalences entre interfaces et points de rfrence
Exemple d'architecture physique de gestion d'un rseau priv virtuel large

bande
INT 2004
INT-LOR-GRS-v2.03
51
CPN-Service
VPN-Service
CPN-Service
OS
OS
OS
PN-Service
PN-Service
OS
OS
OS: Opration System

PN: Public Network
CPN: Customer Permises Network
VPN: Virtual Private Network
CPN
PN
PN
CPN
OS
OS
OS
OS
CPN
Public
Network
Public
Network
CPN
Fig. 5.7: Architecture physique de gestion du service de rseau priv virtuel
Cet exemple prsente l'architecture physique de gestion d'un rseau priv

virtuel large bande ou BVPN. Cette architecture comporte diffrents OS,
savoir l'OS du rseau priv local d'un site de l'entreprise ou CPN
(Customer Permises Network OS) qui gre les ressources du CPN, l'OS
rseau public (PN OS) qui gre les ressources du rseau public, l'OS PNService qui est responsable de la gestion des services offerts sur le
rseau public, l'OS CPN-Service dont le rle est d'administrer les services
fournis sur le CPN et enfin le VPN-Service OS pour la gestion du rseau
priv virtuel.
En terme d'interfaces, l'interface X permet la coopration entre le client du
service de rseau priv virtuel, le fournisseur de service et l'oprateur de
rseau. Quant l'interface Q3, elle permet l'interoprabilit entre les OSs
d'un mme domaine de gestion.
Conclusion
La gestion de rseau et de service de tlcommunication reste un dfi
majeur des environnements qui sont aujourd'hui multi-fournisseurs et
intgrant plusieurs technologies. Le rseau de gestion des
tlcommunications TMN qui a t prsent dans ce chapitre tente de
rpondre cette problmatique travers la dfinition d'interfaces
uniformes standardises dans les recommandations de l'ITU-T. Le
processus de dploiement du TMN a t lent de par la complexit de
l'architecture, l'inertie des systmes lgataires et le manque de volont
industrielle. Ce dernier s'explique par l'intrt des fournisseurs lier les
quipements et l'offre de gestion. Cependant, le futur devrait prsager de
INT 2004
INT-LOR-GRS-v2.03
52
l'avnement du TMN car les grands acteurs des tlcommunications

prennent conscience de l'importance de l'interoprabilit entre systmes
de gestion dans un contexte de drgulation.
Le TMN qui est bas actuellement sur l'architecture de gestion systme
OSI devrait dans le futur proche s'appuyer sur les concepts et principes
du traitement rparti ouvert. L'introduction de ce dernier dans le TMN
devrait accrotre la flexibilit et l'ouverture des composants existants en
facilitant leur intgration avec les composants tiers. Cette avance du
TMN constitue une avance primordiale pour son intgration dans
l'architecture TINA qui promeut aussi la convergence entre les
architectures IN et TMN pour la cration et la gestion de service, ainsi que
pour la gestion des rseaux supports des services.
INT 2004
INT-LOR-GRS-v2.03
53
Chapitre 6 - TINA, larchitecture de rseau

dinformation de tlcommunications
Introduction
A l'heure actuelle l'offre en termes de services de tlcommunication
avancs comme les services multi mdia et rseaux privs virtuels large
bande est encore insuffisante. Les cots et les dlais pour introduire,
maintenir et tendre un service sont encore importants. Les technologies
utilises pour leur mise en uvre sont parfois inefficaces. Or, la demande
ne cesse de crotre. Cette gnration de services requiert entre autre une
introduction plus flexible et une gestion plus intgre. Pour satisfaire cette
demande de services par les usagers, les fournisseurs de rseaux et les
fournisseurs de services ont besoin d'une infrastructure dans laquelle les
services, la gestion de ces derniers ainsi que celle des rseaux supports,
puissent tre introduits aussi facilement et rapidement que possible. Le
logiciel jouera donc un rle majeur dans cette nouvelle infrastructure. Par
consquent, les cots de tlcommunication seront en majeure partie dus
ce logiciel qu'il sera ncessaire de dvelopper pour faire fonctionner et
grer le rseau et les applications qu'il supporte.
Pour rpondre la problmatique pose, il sera fait appel au traitement
rparti ouvert et l'approche oriente objet. En effet, un service de
tlcommunication est par dfinition une application distribue
s'excutant sur diffrents nuds d'un rseau de tlcommunication, d'o
la ncessit du traitement rparti pour rduire la complexit de ce service.
Par ailleurs, l'approche oriente objet est quant elle la technologie de
base utilise pour la cration et la gestion de services car elle satisfait aux
critres de rutilisabilit, extensibilit et maintenance requis par les
logiciels de tlcommunication. Les efforts de normalisation en TMN
(Telecommunication Management Network), IN (Intelligent Network), SDH
(Synchronous Digital Hierarchy) et ATM (Asynchronous Transfer Mode)
reprsentent aussi des solutions qui rpondent diffrents aspects du
problme. De plus les deux architectures IN [Q.12xx] et TMN [M.3010] se
recouvrent. Par exemple, une application TMN telle que la facturation et
une application IN telle que le rseau priv virtuel, sont en relation car la
taxation du VPN doit tre mise en uvre de manire consistante par la
taxation vue d'un point de vue TMN. Cela montre que tant que les deux
architectures IN et TMN ne sont pas intgres, l'interconnexion entre
applications TMN et IN restera complexe mettre en uvre. Il est donc
ncessaire de disposer d'une architecture intgrant IN et TMN.
La normalisation actuelle ne traite pas des concepts de rutilisation,
extensibilit et maintenance. C'est pour cette raison que le consortium
TINA (Telecommunication Intelligent Network Architecture) a t cr. Il a
pour but de dfinir et de valider par l'exemple, une architecture pour
l'introduction de services de tlcommunication qui supporte la mise en
uvre de ces services, leur gestion, et la gestion des rseaux supports
de ces services.
INT 2004
INT-LOR-GRS-v2.03
54
Ce chapitre prsente l'architecture de TINA. On traitera dans le

paragraphe 6.1 les diffrents travaux sur lesquels s'appuie TINA-C pour la
dfinition de son architecture. Dans le paragraphe 6.2, on prsentera une
vue d'ensemble de l'architecture TINA avec sa subdivision en quatre
sous-architectures. Puis, on dcrira ces dernires dans les paragraphes
suivants. Le paragraphe 6.3 concernera la description de l'architecture de
traitement drive du modle de rfrence ODP. La prsentation de
l'architecture de service fera l'objet du paragraphe 6.4; l'architecture de
gestion et ses concepts sous-jacents seront quant eux dcrits au
paragraphe 6.5; l'architecture de rseau et ses modles d'information sont
dtaills au paragraphe 6.6.
Prsentation des travaux TINA

Le projet TINA rutilise des travaux existants autant que possible. La
rutilisation s'opre sur quatre axes comme l'indique la figure 4.1. Les
axes considrs sont le traitement rparti, les architectures de rseau
d'information, la cration de service et la gestion des ressources. Le
terme ressource est considr dans sa dimension gnrique; en effet,
une ressource peut reprsenter une ressource de rseau, de systme, de
service ou d'application.
La norme ODP (Open Distributed Processing) de l'ISO [ODP 96] est
rutilise dans l'axe traitement rparti, elle fournit un cadre pour la mise
en uvre de systmes distribus. Afin d'introduire des services de
tlcommunication bass sur les concepts et les principes dfinis par
TINA-C, TINA tient compte du standard CORBA qu'on traitera au chapitre
7 (Common Object Request Broker) dfini par l'OMG.
INT 2004
INT-LOR-GRS-v2.03
55
Architecture de rseau d'information
Gestion de ressources
ROSA
TMN
CASSIOPEIA
PRISM
INA
OSI
TINA
Traitement rparti ouvert
ANSA
AIN
C
r
CORBA
ODP
IN
Fig. 6.1: axes de TINA
L'axe de cration de service s'appuie sur les recommandations relatives

la normalisation de l'IN par l'ITU-T, et dans une certaine mesure sur celles
de l'AIN (Advanced Intelligent Network) produites par BellCore.
L'axe gestion des ressources s'appuie sur la normalisation OSI qui utilise
l'approche objet pour la gestion de rseau (s'appuyant sur le modle de
rfrence OSI), et fournit des notations textuelles semi-formelles savoir
GDMO (Guidelines for the Definition of Managed Objects) et GRM
(General Relationship Model) pour spcifier l'information de gestion
(objets et relations entre objets). De plus, TINA rutilise les travaux de
l'ITU-T concernant l'architecture TMN, notamment son architecture
informationnelle et fonctionnelle et les tend pour prendre en compte les
dimensions service et systme qui ne sont pour l'instant pas traites par
l'ITU-T. Pour l'aspect gestion de service, TINA s'inspire des rsultats du
projet europen PRISM (Pan-european Reference-configuration for IBC
Services) qui dfinit une configuration de rfrence de gestion de service
SMRC (Service Management Reference Configuration) ainsi qu'une
mthode pour la mise en uvre de services de gestion. Deux applications
sont tudies dans PRISM [PRI 93] pour valider les concepts proposs: le
rseau priv virtuel ou VPN (Virtual Private Network) et la
tlcommunication personnelle universelle ou UPT (Universal Personal
Telecommunication). Le service UPT offre la possibilit ses usagers
d'accder aux services de tlcommunication quelle que soit leur
localisation et quel que soit leur terminal, aussi bien pour tablir des
appels que pour les recevoir.
L'axe architecture de rseau d'information s'appuie sur l'architecture INA
(Information Networking Architecture) [RUB 94] propose par BellCore,
elle est dfinie comme un systme de tlcommunication permettant
INT 2004
INT-LOR-GRS-v2.03
56
l'accs et la gestion d'information tout instant et tout lieu, et sous toute

forme. On constatera que l'architecture TINA ressemble plus une
spcification de l'architecture TMN qu' une intgration entre TMN et IN.
Architecture TINA
Un service ralis dans TINA, comme tout autre service de
tlcommunication ou d'information, consiste en un ensemble de
composants de services interagissant entre eux. Chaque composant de
service peut tre lui-mme dcompos en un ensemble d'objets de
traitement. La communication ou l'interaction entre ces objets est
supporte dans TINA par des mcanismes de distribution offerts par un
environnement de traitement rparti.
Architecture d'ensemble TINA

Afin d'obtenir une bonne structuration, modularit et rutilisabilit dans
l'architecture TINA, trois catgories de composants sont dfinies, savoir,
composants de service, composants de ressources et d'lments (voir
figure 6.2).
La premire catgorie comporte des composants permettant la cration
de services de tlcommunication et services de gestion. TINA-C a entre
autre prdfini certains composants appartenant cette catgorie et
devant prendre place dans tout dploiement de service de
tlcommunication. A titre d'exemple, le gestionnaire de session de
communication dont le rle est d'allouer les ressources de communication
associes une session de service. Les composants de ressources
fournissent une reprsentation abstraite des ressources physiques
disponibles. Parmi les composants de ressources sont prsents les
composants de ressources de transmission et des ressources de
commutation. La troisime catgorie fait rfrence aux ressources
physiques telles que les ordinateurs, les commutateurs, les quipements
spciaux (multimdia).
INT 2004
INT-LOR-GRS-v2.03
Utilisateur
Oprateur
57
Fournisseur de service
Composants de service
Services de tlcommunication
Services de
SML
gestion
Composants de ressources
Ressources de transmission
Equipement de
transmission
Elment
EML
Ressources de
commutation
Commutateur
NEL
Fig 6.2: Vue d'ensemble de l'architecture TINA
L'architecture TINA est subdivise en quatre architectures appliquant

directement la mthodologie ODP (Open Distributed Processing) (voir
figure 6.3), savoir:
l'architecture de traitement (computing architecture),
l'architecture de service (service architecture),
l'architecture de gestion (management architecture),
l'architecture de rseau (network architecture),
L'architecture de traitement s'appuie fortement sur ODP afin d'offrir les
bases pour la rutilisation et l'interoprabilit du logiciel de
tlcommunication. Des concepts de modlisation ainsi qu'une
terminologie de base sont fournis pour les points de vue information,
traitement et ingnierie dfinis dans la norme ODP. Les concepts de
modlisation sont appliquer pour la conception et le dploiement des
services de tlcommunication et services de gestion.
INT 2004
INT-LOR-GRS-v2.03
58
Computing
Architecture
Service
Architecture
Management
Architecture
Network
Architecture
Fig. 6.3: Subdivision de l'architecture TINA
L'architecture de service (service architecture) offre des concepts et des

principes pour raliser, dployer et exploiter des services de
tlcommunication. Comme on vient de voir, un service dans le systme
TINA se compose de plusieurs objets interagissant entre eux et dploys
sur un environnement de traitement rparti. L'architecture de service
dfinit les objets requis pour raliser un service, leur composition et leurs
interactions. De plus un composant de service universel (USCM) a t
propos pour promouvoir la rutilisation dans la mise en uvre de
services. Trois concepts importants sont retenir dans cette architecture:
le concept de session qui concerne les activits de services,
le concept d'accs relatif aux associations de l'usager et du terminal
avec les services et le rseau,
le concept de gestion pour la gestion de services.
L'architecture de gestion (management architecture) permet de mettre en
uvre des applications de gestion de service, de systme distribu et de
ressource au sens rseau grce aux principes et aux concepts
gnriques qu'elle dfinit. Dans ces derniers, on retrouve les aires
fonctionnelles de la gestion, savoir: gestion de la configuration, fautes,
scurit et comptabilit. TINA-C dfinit deux nouvelles aires initialement
considres comme des fonctionnalits de la gestion de la configuration,
il s'agit de la gestion de la souscription dans l'architecture de service
TINA-C, et de la gestion des connexions dans l'architecture de rseau
TINA-C. Un autre concept important est celui d'objet de traitement qui sert
modliser des gestionnaires et des agents.
L'architecture de rseau (network architecture) dfinit un ensemble de
concepts et de principes pour la spcification, la conception, l'implantation
et la gestion de rseaux de transport. Elle dfinit galement un modle
informationnel gnrique de ressources de rseau NRIM (Network
Resource Information Model), des graphes de connexion fournissant une
vue oriente service de la connectivit, et la gestion des connexions qui
tablit, contrle et gre les connexions dans le rseau.
L'architecture de traitement
L'architecture de traitement dfinit les concepts et les principes de
modlisation permettant de mettre en uvre des services de
tlcommunication ou de gestion dans TINA, et donc fournit les bases
pour les trois autres architectures. Elle offre galement un environnement
de traitement rparti (DPE, Distributed Processing Environment) qui
INT 2004
INT-LOR-GRS-v2.03
59
permet aux objets d'interagir entre eux de manire transparente. La

dfinition de cet environnement se base sur les concepts d'ODP
(traitement rparti ouvert ou Open distributed processing). Ce dernier est
une norme pour la construction de tout systme distribu, et n'est pas
spcifique du monde des tlcommunications.
L'architecture de traitement TINA-C cherche raffiner et adapter la norme
ODP pour qu'elle soit applicable aux services de tlcommunication qui
sont par dfinition des applications distribues. A ce propos, la norme
ODP comporte cinq points de vue qui fournissent des lments de base
pour spcifier des systmes ODP. Ce sont:
point de vue entreprise,
point de vue information,
point de vue traitement,
point de vue ingnierie,
point de vue technologie.
L'architecture TINA-C se concentre en particulier sur les points de vue
information, traitement et ingnierie. Les prochains paragraphes
prsentent les concepts de modlisation de ces trois points de vue.
Modlisation d'information dans TINA

Elle a pour but de dcrire la structure modlisant l'information dans le
systme TINA. Elle spcifie d'une part les entits et de l'autre part les
relations entre ces entits. La modlisation d'information dans TINA prend
en compte les contraintes et les rgles qui gouvernent le comportement
des entits et des relations, y compris les rgles de cration et de
suppression.
Chaque entit est modlise sous forme d'un objet d'information. Le
concept de type d'objet est dans TINA-C considr comme tant un
prdicat caractrisant une collection d'objets. Les objets sont dcrits par
des gabarits spcifiant leurs caractristiques communes. Ceci avec un
certain niveau de dtails suffisants pour raliser leur instanciation. Un
gabarit caractrise donc l'ensemble des objets qu'il instancie. Les actions
de chaque objet sont dcrites dans son gabarit par leurs noms et des
paramtres en entre et en sortie. Ces actions spcifient des
changements d'tats possibles. L'tat d'un objet caractrise l'information
qu'il dtient un instant donn. A ces actions sont aussi associes des
pr-conditions et des post-conditions.
Les relations entre objets matrialisent les dpendances entre objets et
facilitent ainsi la comprhension du modle. Chaque relation est dfinie
par un paramtre arit qui reprsente le nombre d'objets participant une
relation. La majorit des relations ont gnralement une arit gale 2, et
sont appeles relations binaires. Toute action peut avoir un tat et des
attributs qui changent de valeurs par le biais des actions. Comme pour les
objets, un type de relation est un prdicat caractrisant une collection de
relations. Une position dans une relation est appele un rle. Un type de
relation associe chaque rle un type d'objet. Par exemple, tudes est un
type de relation binaire avec les deux rles tudiant et cole. Le rle
tudiant est associ au type personne alors que le rle cole est associ
au type tablissement_scolaire. Ainsi toute personne qui tudie dans un
tablissement_scolaire est une instance de ce type de relation, (Ahmed,
INPT). Il est possible de dfinir des contraintes sur les types de relation,
par exemple la suppression d'un objet doit impliquer la suppression
INT 2004
INT-LOR-GRS-v2.03
60
d'autres objets dans la relation. Par ailleurs la cardinalit de rle est

dfinie comme un ensemble d'entiers positifs qui contraint le nombre de
relations de ce type qui ont le mme objet dans l'autre rle.
Les types d'objets et de relation peuvent aussi tre reprsents
graphiquement en utilisant la notation OMT (Object Modeling Technique)
[RUM 91]. Les types d'objets sont reprsents par des rectangles o leurs
noms sont en gras dans la premire partie du rectangle (voir figure 6.4).
Les attributs figurent dans la deuxime partie du rectangle, chaque nom
d'attribut peut tre suivi par des dtails optionnels comme le type et la
valeur par dfaut. Il n'est pas ncessaire de spcifier des attributs dans
une classe. Dans le dernier tiers du rectangle sont places les oprations.
Comme pour les attributs chaque nom d'opration peut tre suivi par des
dtails optionnels, savoir la liste d'arguments et le type du rsultat. La
spcification d'oprations est aussi optionnelle. Elle dpendend
galement du niveau de dtail souhait. Le sous-typage est reprsent
par un triangle.
Les types de relation sont reprsents par des arcs entre les types
d'objet. Le nom de la relation apparat en italique; il est optionnel. Les
types de relation d'arit n sont reprsents par un losange connectant
leurs arcs aux types d'objet impliqus. La cardinalit s'exprime par un
nombre ou un ensemble d'intervalles. Un petit rond noir correspond
"many" signifiant zro ou plus.
Il est galement possible de reprsenter textuellement les types d'objet et
de relation. Pour ce, TINA-C se base sur les notations proposes par la
gestion OSI. Il s'agit du GDMO (voir chapitre 4) qui permet de spcifier
semi-formellement les types d'objet et GRM [X.725] dfini afin de spcifier
des types de relation. Ces notations textuelles sont adaptes par TINA-C
afin de les rendre conformes aux concepts de modlisation d'information.
Elles sont appeles Quasi-GDMO et Quasi-GRM.
Type d'objet 2
Type d'objet 1
attribut_11
Type de relation 1
attribut_12
opration_11
rle 1
attribut_21
rle 2
attribut_22
opration_21
notification_11
opration_22
Type d'objet 3
Type d'objet 4
Fig. 6.4: notations graphiques pour les types d'objet et de relation dfinies par OMT
INT 2004
INT-LOR-GRS-v2.03
61
Modlisation de traitement dans TINA

Du point de vue traitement, une application distribue consiste en un
ensemble d'objets de traitement. Chaque objet de traitement encapsule
des donnes de traitement et fournit un ensemble de fonctions (services)
accessibles par d'autres objets. Ces services sont offerts au travers
d'interfaces de traitement.
TINA-C a dfini le langage ODL (Object Definition Language) [KIN 95]
pour la spcification semi-formelle des objets de traitement et de leurs
interfaces. L'ODL est une extension de l'OMG-IDL (voir chapitre 7 et
annexe 1), il est en fait un sur-ensemble d'OMG-IDL. Ce qui permet aux
services de tlcommunication ou de gestion spcifis avec TINA-ODL
d'tre construits au-dessus de plates-formes rparties ORB (Object
Request Broker, voir chapitre 7) commerciales conformes aux
spcifications de l'OMG.
La spcification d'objet est introduite par le mot cl OBJECT suivi du nom
attribu un objet.
OBJECT NetworkConnectionManager
BEHAVIOR "Cet objet cre des connexions de rseau"
REQUIRES ElementConnectionManagerIF;
INITIAL NetworkConnectionManagerConfigurationIF;
CONSTRAINT {Attributs de service: dbit de connexion, temps d'tablissement}
SUPPORTS NetworkConnectionManagerIF
Une spcification de comportement (BEHAVIOR) dfinit en langage
naturel le rle d'un objet qui offre des services via des interfaces; la
clause REQUIRES indique les interfaces requises qui sont offertes par
d'autres objets et utilises par cet objet. La clause INITIAL dsigne
l'interface d'initialisation de l'objet. la clause CONSTRAINT dcrit les
contraintes applicables l'objet comme les contraintes de qualit de
service, d'usage et de gestion. Enfin la clause SUPPORTS dclare les
interfaces offertes ou supportes par l'objet. La spcification d'objet
suivante dcrit un gestionnaire de connexion de rseau.
Quant la spcification d'interface, elle est introduite par le mot cl
INTERFACE suivi du nom d'une interface; dans certains cas une interface
peut hriter d'une ou plusieurs interfaces dont les noms sont indiqus.
Une spcification de comportement BEHAVIOR dcrit le service offert et
prcise l'usage du service stipulant des contraintes de squencement sur
les oprations dfinies sur cette interface. Ces contraintes doivent tre
vrifies lors de l'invocation d'oprations. Une spcification d'attribut de
service dclare les types et les identifiants d'attribut de qualit de service.
Une clause signature d'interface permet de spcifier une signature
d'interface ou de flot. La spcification d'interface suivante dcrit l'interface
NetworkConnectionManagerConfigurationIF
INT 2004
INT-LOR-GRS-v2.03
62
qui hrite de l'interface ServiceManagementIF.

INTERFACE NetworkConnectionManagerConfigurationIF:
ServiceManagementIF {
BEHAVIOR "Cette interface permet
de configurer
l'objet de traitement
NetworkConnectionManager. L'opration readState retourne la valeur de
l'tat de cet objet. L'opration WriteState permet de changer la valeur de
l'tat de l'objet "
USAGE
"l'opration Init doit tre invoque avant toute autre opration dfinie. Des
invocations concurrentes de l'opration ReadState sont permises mais
toutes les demandes d'oprations WriteState sont bloques tant qu'une
opration WriteState est en cours de traitement"
Void Init;
Modlisation d'ingnierie dans TINA

La modlisation d'ingnierie TINA-C dcrit l'organisation d'une
infrastructure abstraite appele TINA DPE (TINA Distributed Processing
Environment, voir figure 6.5) qui permet d'excuter les objets de
traitement TINA-C [GRA 95]. Les applications TINA consistent en un
ensemble d'objets de traitements s'appuyant sur cet environnement de
traitement rparti TINA, qui permet leur dploiement, leur excution et
leurs interactions.
Dans le point de vue ingnierie, un objet de traitement devient un objet de
traitement d'ingnierie eCO (Engineering Computational Object). Il existe
une diffrence d'abstraction entre ces deux objets. En effet, l'objet de
traitement a la vue uniquement des interactions avec d'autres objets de
traitement, alors qu'un eCO peut interagir avec d'autres objets d'ingnierie
diffrents des eCOs. Ceci revient au fait que les eCOs interagissent avec
des eCOs qui tablissent leurs communications avec d'autres eCOs ou
qui offrent des transparences la distribution.
L'infrastructure TINA DPE offre des services aux objets des applications
qu'elle excute. Ces services offrent une interface de traitement par
laquelle ils sont accssibles partir des objets de traitement TINA. Les
services offerts sont de deux types: des fonctions pour supporter les
mcanismes d'interactions entre objets ou des fonctions suffisament
gnriques pour tre appliques un grand nombre de domaines.
OT: Objet de Traitement
Application TINA
OT
OT
Interface
opration
OT
Infrastructure
TINA DPE
Fig. 6.5: TINA DPE, l'infrastructure abstraite
INT 2004
INT-LOR-GRS-v2.03
63
Ces services sont encapsuls dans le DPE (voir figure 6.6). Les services
existants actuellement sont au nombre de six:
service de courtage: publie et recherche les interfaces qu'utiliseront des
objets pour offrir des services d'autres objets.
service de transaction: tablit une communication transactionnelle entre
les objets possdant les proprits ACID (Atomicit - Concurrence Intgrit - Durabilit).
service conteneur: permet de stocker des spcifications de types d'objet
et d'interface. Le service de conteneur d'implmentation permet de
stocker l'implmentation de l'objet sous la fome d'un code excutable et
d'informations lies son implmentation.
service de notification: offre la possibilit aux objets d'mettre ou de
recevoir des notifications sans tenir compte des objets avec lesquels ils
communiquent.
Application TINA
OT
OT
OT
Interface de service TINA
Fonction de
courtage
Fonction de
surveillance des
performances
Fonction de
scurit
Fonction cycle
de vie
Fonction de
conteneur
Fonction de
notification
Fonction de
dploiement
Fonction de
scurit
Fonction de
configuration
Fig. 6.6: Services et fonctions du DPE TINA
service de scurit: permet aux applications TINA de faire

l'authentification, l'autorisation, le contrle d'accs, etc.
service de surveillance des performances: fournit les mesures et les
rapports de performance de l'activit des ressources de rseau.
TINA-C a aussi propos trois autres services relatifs la gestion du cycle
de vie des objets:
service de cycle de vie: permet la cration, la suppression, l'activation,
la dsactivation et la migration d'eCOs.
service installation: permet le dploiement des eCOs.
INT 2004
INT-LOR-GRS-v2.03
64
service de configuration: donne des informations sur la configuration

des eCOs.
Applications TINA
A
p
DPE
Implmentation DPE
KTN (rseau
logique)
Rseau physique
quipements
Fig. 6.7: le DPE vu par TINA-C
La figure 6.7 montre les diffrents niveaux du DPE TINA. Le niveau des
applications TINA communique avec un niveau DPE sappuyant sur un
rseau abstrait mettant en uvre un rseau de gestion, le KTN ou Kernel
Transport Network. Les nuds du rseau KTN communiquent avec des
nuds du rseau physique.
Il est noter que le KTN est un quivalent du DCN (Data Communication
Network) du TMN, mais avec la diffrence notable quil se situe un
niveau de rseau logique et non physique.
Un des aspects puissants du DPE est justement le dcouplage entre un
niveau de rseau logique sur lequel est tablit le rseau de gestion KTN,
et un niveau de rseau physique mettant en uvre les quipement euxmmes. Ce dcouplage permet au DPE dtre totalement affranchi des
technologies de rseaux, des topologies etc.
On peut considrer le DPE comme une sorte de super-CORBA (cf.
chapitre suivant). La richesse des concepts proposs ici est galement
comparer une architecture mergente: les GRIDs. En effet, un nud
DPE semble finalement assez proche de ce que propose un nud GRID
en termes de vision objet, dautonomie, dintelligence locale active
cooprante. La vision DPE dnote ici une grande avance sur son temps.
L'architecture de service
L'architecture de service consiste en un ensemble de concepts, de
principes et de rgles qui permettent de concevoir et construire des
systmes au sens large du terme. L'architecture de service de TINA-C
INT 2004
INT-LOR-GRS-v2.03
65
dfinit donc les concepts et les principes de base ncessaires la mise

en uvre de services TINA. Ces derniers sont regroups en trois
catgories:
services de tlcommunications: tablissent la connexion et
transportent l'information entre les diffrents terminaux connects sur
le rseau de tlcommunication.
services de gestion: assurent la gestion de la configuration, des
fautes, des performances, de la comptabilit et de la scurit des
ressources TINA.
services d'information: permettent le stockage et la visualisation des
ressources d'information tels que le son, la vido, le texte, etc.
La notion de session
Afin de pouvoir dployer les services multimdia, TINA-C a introduit la
notion de session gnralisant ainsi le concept d'appel. ce dernier tant
uniquement ddi la ngociation et l'allocation des ressources de
communication ne supporte pas les fonctionnalits spcifiques au service.
Par contre, la session de service peut utiliser diffrents modles et
procdures d'appel pendant sa dure de vie en fonction des besoins des
applications.
Une session est dfinie par la relation temporaire entre un ensemble de
ressources ayant une tche accomplir pendant une priode bien dfinie.
Ces ressources peuvent tre des utilisateurs par exemple. Il existe quatre
types de session (voir figure 6.8):
session de service (Service Session): elle concerne la simple
activation d'un service. Elle prsente des informations de gestion et de
contrle du service comme le nombre d'utilisateurs, profils de service,
etc. Mais aussi des informations caractrisant une utilisation du
service comme le rle des utilisateurs impliqus, capacit de
communication alloue, etc. Elle se dcompose en deux sessions:
session de service usager (User Service Session): permet
l'usager de personnaliser sa vue de la session de service. Elle
facilite l'utilisation du service en cachant sa complexit l'usager.
Ce dernier est sr que ses prfrences et son environnement
seront supports par le service. Une session usager est cre
lorsqu'un utilisateur se joint une session de service; elle est
supprime lorsque celui-ci quitte la session.
session de service fournisseur (Provider Service Session): fournit
l'ensemble des clients du fournisseur un environnement
permettant l'excution d'un service. Elle dfinit l'ensemble des
activits d'un service et fournit le contrle requis sur ce service.
INT 2004
INT-LOR-GRS-v2.03
66
Session
d'accs
Session
d'accs
Session de
service
usager
Session de
service
fournisseur
Session
de
service
usager
Session de service
Session de communication
Fig. 6.8: Concept de session dans TINA
session d'accs (Access Session): gre l'implication de l'utilisateur

dans plusieurs services simultanment. En effet, un utilisateur peut se
connecter un systme et lancer des sessions de services et en
mme temps se joindre plusieurs sessions de service simultanes.
La session d'accs gre galement la connexion de l'utilisateur au
systme.
session de communication (Communication Session): reprsente les
connexions qu'utilise le service dans le rseau de transport: chemin
de communication, point de terminaison, qualit de service, etc.
Ainsi TINA spare compltement les aspects relatifs aux services
(session d'accs, session de service, session de service fournisseur et
usager) et les aspects relatifs aux capacits de communication (session
de communication).
Les composants de service TINA

TINA propose plusieurs composants de services rutilisables pour la
cration d'un grand nombre de services. Ces composants relatifs aux
sessions introduites prcdemment sont de trois types :
composants relatifs la session d'accs,
composants relatifs la session de service.
composants relatifs la session de communication
La premire catgorie comporte les composants suivants:
l'agent usager ou UA (User Agent): reprsente l'utilisateur dans le
systme TINA. Il permet son usager d'initialiser une nouvelle
session de service ou de se joindre des sessions existantes. Il est
indispensable pour l'accs aux services par l'utilisateur, il est
indpendant des services.
L'agent fournisseur ou PA (Provider Agent): galement indpendant
des services permet son utilisateur d'accder son UA. En terme de
INT 2004
INT-LOR-GRS-v2.03
67
session d'accs, il transporte des donnes d'un utilisateur vers son

UA pour crer de nouvelles sessions de service, pour se joindre une
session existante, etc.
L'agent initial ou IA (Initial Agent): reprsente le point d'accs initial
un fournisseur de service. Il est aussi indpendant des services.
La deuxime catgorie se compose des composants de service suivants:
l'application usager ou UAP (User Application): reprsente des
applications dans le domaine usager. Il offre l'interface utilisateur
d'une application en jouant le rle de point terminal dans une session
de service.
le Service Factory ou SF est un composant de service spcifique un
type de service donn, dont le rle est de crer les composants de la
session de service pour ce type de service. Pour des besoins de
gestion, il peut fournir la liste des sessions de service actives et peut
librer certaines d'entre elles la demande.
Le gestionnaire de session de service ou SSM (Service Session
Manager): supervise et contrle les ressources utilises dans la
session de service. Il supporte l'ajout / le retrait / l'invitation /
d'utilisateurs /de la session en interagissant avec les UAs
correspondants. Enfin, il offre des fonctionnalits de gestion pour la
session comme la facturation. Un composant SSM est cr par un SF
lorsqu'un service est invoqu travers une session d'accs.
le gestionnaire de session utilisateur ou USM (User Session
Manager): supervise et contrle la session usager, il reprsente
l'utilisateur avec ses caractristiques particulires. Un composant
USM est cr par un SF lorsqu'un usager se joint une session de
service, elle est supprime lorsque l'utilisateur quitte la session de
service.
La troisime catgorie de composant se compose du gestionnaire de
session de communication ou CSM (Communication Session Manager): il
offre un service de connectivit au SSM. Il est indpendant des services.
Il transforme une demande applicative (tablir/maintenir/librer une
association) en connexions de rseau de bout en bout. Il reprsente donc
le point de contrle pour l'allocation des ressources de communication.
En rsum, les composants relatifs la session d'accs offrent un cadre
pour la fourniture d'accs scuriss et personnaliss aux services. Les
composants relatifs la session de service fournissent un cadre pour la
dfinition de services accessibles et grables. Les SSMs et les USMs
sont instancis par des SFs partir de demandes des UAs. Quant au
composant UAP, il permet les interactions entre l'utilisateur et la session
de service, tandis que le composant relatif la session de communication
alloue les ressources de communication.
Le composant de service universel
INT 2004
INT-LOR-GRS-v2.03
68
TINA dfinit un modle de composant de service universel appel USCM

(Universal Service Component Model) qui permet de dcrire chaque
composant de service de tlcommunication. En effet, pour dcrire un
service de tlcommunication il faut sparer les aspects relatifs l'accs
au service, sa logique, sa gestion et l'utilisation des ressources ou
Interfaces de type
Serveur
Interfaces de type
M: Management Sector.
U: Usage Sector.
S: Substance Sector.
C: Core Sector.
Serveur
Core C
S
Interfaces de type
Client
Fig. 6.9: structure du modle USCM
autres services. Ce modle se compose de quatre parties (voir figure 6.9):

Core: correspond la logique du service, c'est dire ses
fonctionnalits spcifiques qu'attendent les utilisateurs,
Usage: correspond aux interfaces utilisateur du service pour y
accder et l'utiliser,
Substance: correspond aux dpendances du service envers des
ressources externes ou d'autres services.
Management: aspects lis la gestion du service.
Les interactions permises entre les composants de service TINA sont au
nombre de quatre (voir figure 6.10):
S
M
Fig. 6.10: interactions permises entre composants de service TINA
INT 2004
Interaction S-U: a lieu lorsqu'un composant ncessite un service

extrieur;
Interaction S-M: se produit quand un composant de gestion
(gestionnaire) veut superviser un composant de service. Le secteur
Substance du gestionnaire invoque le secteur Management du
INT-LOR-GRS-v2.03
69
composant service l'aide d'oprations comme Get, Set, reroute,

rinitialise, etc;
Interaction M-U: a lieu lorsqu'un composant de service est en faute, il
met une notification depuis son secteur Management o la faute est
dtecte vers du secteur Usage d'un gestionnaire qui analysera et
corrigera la faute;
Interaction U-U: se produit quand un composant de service ne peut
offrir le service demand par son client, il dlgue alors la demande
un autre composant en mesure de le fournir.
L'architecture de gestion
La gestion dans TINA se rpartit en trois types: gestion de service,
gestion de ressource, et gestion du DPE (Distributed Processing
Environnment) (voir figure 6.11):
Gestion dans
TINA
Gestion de
Service
Gestion des
Ressources
de rseau
Gestion du
DPE (Resources
de traitement)
Fig. 6.11: Gestion dans TINA
La gestion de service concerne tous les services dfinis dans

l'architecture TINA. La gestion des ressources s'applique toutes les
ressources de rseau utilises pour la fourniture de ces services. Quant
la gestion du DPE, elle gre l'infrastructure de l'environnement de
traitement rparti. Ce dernier fournit les transparences de distribution aux
applications de tlcommunications et de gestion de TINA-C. La gestion
du DPE est encore en cours de spcification par TINA-C.
La gestion de service prend place dans l'architecture de service car un
service de tlcommunication doit intgrer des fonctionnalits de gestion
pour qu'il soit compltement dfini et prt tre dploy. La gestion des
ressources est intgre dans les architectures de gestion et de rseau. La
gestion du DPE est mise en uvre dans l'architecture de traitement.
Les aires fonctionnelles de gestion

TINA-C reprend les cinq aires fonctionnelles du TMN (gestion de la
configuration, des fautes, des performances, de la comptabilit et de la
scurit). TINA-C dcompose la gestion de la configuration en:
gestion des connexions: se charge de l'tablissement, du contrle et
de la libration des connexions;
INT 2004
INT-LOR-GRS-v2.03
70
gestion de configuration des ressources: permet l'installation, la

fourniture, le contrle et la gestion des ressources de rseau.
Les principes de gestion dans TINA-C

L'architecture de gestion TINA-C se base sur les concepts d'architecture
que TINA-C a dfini mais aussi sur les recommandations de gestion ITUT et ISO. L'architecture logique rpartie en couches dfinie dans la
recommandation ITU-T M.3010 est applicable dans l'architecture de
gestion TINA-C. Les couches considres sont les couches gestion
d'lment de rseau, gestion de rseau et gestion de service. TINA-C
regroupe les deux couches basses en une couche appele couche
gestion de ressource. Les objets de gestion OSI ou ITU-T sont spcifis
dans TINA-C sous forme d'objets d'information selon les concepts de
modlisation d'information. Les blocs de fonctions peuvent tre
reprsents par un ou plusieurs objets de traitement. Par exemple, un
bloc OSF qui ralise une application de facturation ou de configuration
peut tre mis en uvre par plusieurs objets de traitement. Du fait que les
objets de traitement sont spcifis en utilisant l'approche oriente objet,
ils sont donc plus facilement rutilisables que les blocs de fonctions TMN
(voir figure 6.12)
WSF
OSF
CO1
CO2
MF
CO: objet de traitement
OSF
NEF
CO4
Dans cette relation:

- CO4 = Objet agent
- CO3 = Objet gestionnaire
QAF
NEF
CO3
Fig. 6.12: Blocs de fonction, objets de traitement, points de rfrence et interfaces
Les points de rfrence TMN peuvent quant eux aussi tre supports
par un ensemble d'interfaces opration. Ces dernires sont spcifies
grce au langage ODL; elles sont types et dcrivent un service bien
dfini la diffrence des points de rfrence qui fournissent une
description gnrale d'une fonctionnalit. Des interactions en cascade
entre les objets de traitement existent, dans le sens o un objet de
traitement peut jouer en mme temps le rle de gestionnaire dans une
interaction et le rle dagent dans l'autre.
INT 2004
INT-LOR-GRS-v2.03
71
L'architecture de rseau
L'architecture de rseau TINA-C dfinit le modle informationnel
gnrique de ressource de rseau NRIM (Network Resource Information
Model) ainsi qu'une architecture de gestion des connexions permettant
l'tablissement, le contrle et la gestion des connexions dans un rseau.
Prsentation du modle NRIM

Le modle informationnel NRIM dcrit les classes d'objets qui modlisent
les ressources de rseau tout en restant indpendant de toute
technologie de commutation. Ces classes sont rutilisables afin de
faciliter la mise en uvre d'applications de gestion de service et de
rseau [FUE 95]. Le modle NRIM a t influenc par deux
recommandations de l'ITU-T, savoir M.3010 qui dcrit un modle
informationnel gnrique de rseau et G.803 qui dfinit une architecture
de rseau de transport base sur la hirarchie digitale synchrone, SDH
(Synchronous Digital Hierachy). L'apport de NRIM par rapport aux deux
recommandations consiste en la prise en compte par NRIM du niveau
gestion de ressources (gestion de rseau) que M.3010 ne spcifie pas. Le
modle d'information TINA-C est applicable aux diffrents modles
existants qui dcrivent le niveau lment de rseau, savoir l'ATM,
SONET, SDH, etc. Ceci revient la gnricit du modle NRIM. Ce
dernier spare les aires fonctionnelles du modle informationnel de la
gestion OSI et propose des classes d'objets pour les aires gestion des
fautes et gestion de la configuration.
NRIM est dfini par un ensemble de fragments tout comme le modle
M.3010 de l'ITU-T (voir figure 6.13). Chaque fragment traite un aspect
bien spcifique.
INT 2004
INT-LOR-GRS-v2.03
72
NRIM
Modle d'Information
ATM
Fragment graphe de connexion
TA-1114
Fragment rseau
Fragment connectivit
Modle d'Information
SONET
TR-1042
Fragment point de terminaison

Fragment configuration de ressource
Modle d'Information
SDH
Fragment gestion des fautes
G.774
Fragments supplmentaires dfinir
Modle d'Information
gnrique de rseau
Modle fonctionnel de
rseau de transport
G.803
Fig. 6.13: le modle d'information de ressources de rseau dfini par TINA-C et ses fragments
Fragment graphe de connexion: CG (Connection Graph) permet

d'exprimer la connectivit requise par les services de tlcommunication
durant leur excution indpendamment de toute technologie. Le modle
comporte trois objets (voir figure 6.14):
le port (Port) modlise le point d'accs un lien;
le lien (Line) reprsente un flot d'information entre des ports dans le
graphe de connexion.
le vertex (Vertex) modlise l'ensemble des ressources impliques
dans le transport des flux d'information. il peut reprsenter par
exemple des quipements tels que la camra, la moniteur, le
microphone, etc.
Vertex
Port
Line
Port
Port
Vertex
Port
Line
Fig. 6.14: le graphe de connexion
Fragment rseau: modlise la structure et la subdivision d'un rseau en

couches. Ce dernier contient des chemins, des connexions, des liens
topologiques et des sous-rseaux. Un chemin transporte des informations
entre points de terminaison du rseau en couches. Une connexion dcrit
la connectivit entre deux sous-rseaux. Un ensemble de connexions
peut tre group pour former un lien topologique.
Fragment connectivit: la connexion et la connexion de sous-rseaux
sont deux concepts qui permettent de modliser la connectivit
INT 2004
INT-LOR-GRS-v2.03
73
l'intrieur d'un rseau en couches. Le premier concept dcrit la

connectivit entre deux sous-rseaux (connexion de liens), elle est prconfigure. Le deuxime concept qui celui de la connexion de sousrseaux ou SNC (Subnetwork connection) dcrit la connectivit
l'intrieur d'un sous-rseau.
Fragment point de terminaison: les points de terminaison sont des
points d'accs un rseau en couches ou un sous-rseau. Un point de
terminaison de connexion de rseau NWCTP (Network Connection
Termination Point) termine une connexion ou une connexion de sousrseau. Un point de terminaison de chemin NWTTP (Network Trail
Termaination Point) termine un chemin. Il reprsente le point d'accs un
rseau en couches. Le point de terminaison de lien LTP (Link Termination
Point) modlise une terminaison d'un lien topologique.
Fragment configuration de ressource: trois types de ressources sont
prsents dans l'architecture TINA, savoir les ressources de rseau, les
ressources du DPE et les ressources de service. Une classe d'objet
appele configurable est une super classe de toute classe d'objet
configurer. Les attributs de cette classe sont tat administratif et tat
oprationnel. Des actions et notifications de base relatives la
configuration sont aussi dfinies pour la classe d'objet configurable tels
que lock, unlock et notification de changement d'tat.
Fragment gestion des fautes: ce fragment dfinit des objets supports
pour la gestion des fautes. La gnricit de ces objets leur permet d'tre
non seulement applicables aux ressources de rseau mais aussi aux
ressources du DPE ou celles de service. L'aire fonctionnelle de la gestion
des fautes TINA-C recouvre les activits de surveillance d'alarme, de
localisation de fautes, de correction de fautes et de tests/diagnostics.
Architecture de gestion des connexions TINA-C

La gestion des connections dans TINA a pour but d'tablir les connections
que demandent les services de tlcommunication. Le terme session a un
sens diffrent selon le niveau auquel on se place. Au niveau le plus haut
de l'architecture, il reprsente une liaison entre interfaces flot d'objets de
traitement. Cette liaison ou association est dcompose de manire
rcursive pour devenir une connexion de transport de bout en bout, puis
une connexion de sous-rseau et enfin une connexion entre ports d'un
commutateur. L'architecture des connections doit tre vue comme une
application distribue qui s'excute sur le DPE. La fonctionnalit de
gestion des connections est dfinie par un ensemble d'objets de
traitement selon les concepts de modlisation de traitement; ces objets
sont:
le gestionnaire de session de communication CSM (Communication
Session Manager);
le coordinateur de rseau en couche LNC (Layer Network
Coordinator);
les gestionnaires de connection CPs (Connection Performers).
Un service de tlcommunication est du point de vue traitement rparti un
ensemble d'objet de traitement s'excutant sur un DPE. Ces derniers
interagissent au travers d'interfaces flot. Les interfaces opration sont
lies dynamiquement et implicitement par les services du DPE. Alors que
les interfaces flot sont lies uniquement de faon explicite. L'objet CSM,
dfini au niveau le plus haut de l'architecture de gestion des connexions
offre les services ncessaires pour lier des interfaces flot. Le client de
INT 2004
INT-LOR-GRS-v2.03
74
l'objet CSM, gnralement un service de tlcommunication, indique les

rfrences des interfaces interconnecter, ainsi que les caractristiques
de la connection logique telle que la qualit de service. Cette spcification
de connection est indpendante de la technologie, de la topologie du
rseau support et de la distribution.
L'objet CSM doit prendre en compte le fait que la connection entre
interfaces d'objet de traitement doit tre mise en uvre dans un rseau
de tlcommunication. Elle peut devenir par exemple une connection
ATM de bout en bout. Cette dernire connecte les points de terminaison
des terminaux sur lesquels sont excutes les objets de traitement dont les
interfaces flot sont lier. L'interconnection de points de terminaison dans
un rseau de tlcommunication est ralise par l'objet CC. Le client de
l'objet CC, savoir l'objet CSM ou tout client souhaitant une connection
de niveau transport, spcifie les adresses de points de terminaison
interconnecter, ainsi que les caractristiques de la connection.
Cette spcification de connection est indpendante de la technologie et
de la structure du rseau sous-jaent.
Pour offrir son service, l'objet CC doit slectionner l'objet LNC afin que
celui-ci tablisse un chemin dans un rseau en couches. Un rseau en
couches est dcompos en domaines, chacun sous la responsabilit d'un
oprateur de rseau par exemple. Chaque domaine a son propre objet
LNC. L'objet CC demande la mise en uvre d'un seul chemin un seul
objet LNC; ce dernier prend en charge la fdration entre les domaines
ncessaires. Pour le client d'un objet LNC, ce dernier est le seul point
d'accs dans tout rseau en couches. Il est noter que des objets LNC
appartenant des rseaux en couches diffrents n'interagissent pas entre
eux. Un objet CPE LNC est prsent dans le domaine de l'utilisateur. il met
en uvre la fdration entre domaine public (rseau d'oprateur) et
domaine priv (rseau priv local).
Un objet NML CP met la disposition de l'objet LNC des services lui
permettant d'tablir un chemin dans le rseau en couche. Le NML CP
contrle un sous-rseau dans un rseau en couches, il y fournit
l'interconnection de points de terminaison. Il permet donc l'tablissement,
le contrle et la libration de connections de sous-rseau point--point
unidirectionnelles
et
bidirectionnelles
ou
point--multipoint
unidirectionnelles. Pour raliser la connection physique de sous-rseau,
l'objet NML CP utilise les services des objets EML
L'objet EML CP accde aux agents des quipements du rseau. Il permet
donc d'tablir, de contrler et de librer les connections dans l'quipement
dont il est responsable.
La figure 6.15 est un exemple possible d'architecture de gestion des
connections rsumant les enchanements dcrits prcdemment. Il
adopte l'architecture logique rpartie en couches dfinie par le TMN. Les
services de tlcommunication se situent dans la couche SML. La couche
NML contient les objets CSM, CC, LNC, et NML CP. Les objets EML CP
sont prsents la couche EML. La couche NEL est naturellement forme
des lments physiques de tlcommunication.
INT 2004
INT-LOR-GRS-v2.03
75
SML
Composants de service
CSM: Communication Session Manager

CC: Connection Coordinator
LNC: Layer Network Coordinator
CSM
CP: Connection Performer

NE: Network Element
CPE: Customer Premises Equipment
CC
Domaine de l'utilisateur
EML
NEL
LNC
LNC
CPE LNC
NML CP
NML CP
CPE CP
EML CP
EML CP
EML CP
NE
NE
NE
NE
Fig. 6.15: Exemple d'architecture de gestion des ressources
Conclusion
Le consortium TINA a spcifi une architecture logicielle adquate. Cette
dernire intgre le traitement rparti et l'approche oriente objet aux
systmes de tlcommunication. TINA facilite ainsi la rutilisation des
spcifications, la rpartition flexible du logiciel et l'homognit dans la
mise en uvre des services. Plusieurs oprateurs faisant partie du
consortium TINA-C envisagent de migrer long terme de l'IN (Intelligent
Network) vers TINA. Certains d'entre eux ont dj mis en uvre des
prototypes TINA pour prouver les concepts, principes et rgles dfinies.
Un rsultat majeur de TINA est davoir influenc lITU-T suffisamment
pour accepter CORBA comme alternative CMIS/P pour le protocole.
TINA, malgr un manque certain de ralisations industrielles, reste un
rservoir ides dimportance majeure. Il est probable que TINA a pch
par son avance sur son temps, en restant incompris de la majorit de la
communaut TMN traditionnelle. Mais cette situation nest peut-tre pas
dfinitive.
On verra au chapitre 8 que le NGOSS du TeleManagement Forum
rutilise avec intelligence un grand nombre de concepts de TINA.
INT 2004
INT-LOR-GRS-v2.03
76
INT 2004
INT-LOR-GRS-v2.03
77
Chapitre 7 - CORBA et la gestion des

rseaux
Introduction
La rvolution que connat actuellement la programmation distribue
revient aux spcifications des standards pour les systmes distribus et
l'utilisation des langages orients objet. CORBA est notamment une
spcification normative qui rsulte d'un consensus entre les membres de
l'OMG, un consortium qui regroupe aujourd'hui plus de 850 acteurs de
l'industrie informatique. Dans ce chapitre on prsentera la norme CORBA,
son architecture, ses composants et ses objectifs.
Survol de CORBA
CORBA est lacronyme de Common Object Request Broker Architecture,
qui est la solution de l'OMG (Object Management Group) pour
l'interoprabilit des machines et des logiciels. Le nombre et la diversit
de ces derniers ne cessant pas de crotre met en vidence l'ide d'une
standardisation des outils de communication. CORBA vient justement
pour permettre aux applications de communiquer entre elles sans se
proccuper de la machine o elles se trouvent non plus de ceux qui les
ont conues. La premire version CORBA 1.1 a vu le jour en 1991, elle a
dfini l'IDL (Interface Definition Language) et l'API qui permet l'interaction
d'objets client/serveur travers un bus de communication appel ORB
(Object Request Broker). La deuxime version CORBA 2.0 apparue en
1994, dfinit une vraie interoprabilit puisqu'elle spcifie comment des
ORBs de diffrents constructeurs peuvent communiquer [OMG].
OMA, L'architecture globale de CORBA

LOMG dfinit aussi une vision globale de la construction dapplications
rparties: lObject Management Architecture Guide (OMAG). Cette
architecture globale, appele aussi lOMA, vise classifier les diffrents
objets qui interviennent dans une application en fonction de leurs rles.
En effet la norme CORBA traite les lments constitutifs des systmes
d'objets distribus, savoir: un langage de description d'objets (IDL), une
infrastructure de distribution des objets appele Bus d'Objets Rpartis
(ORB), une description de services communs ncessaires aux objets
applicatifs (Services Objet Communs ou "CorbaServices"), une
description de services communs aux applications (Utilitaires Communs
ou "CorbaFacilities"), une collection de descriptions de services par
branche industrielle (Interfaces de Domaine ou "Domain Interfaces") et
une spcification normative d'interoprabilit entre ORB (Corba2) [OMG]
(voir figure 7.1).
INT 2004
INT-LOR-GRS-v2.03
78
Interfaces
de domaine
Objets
applicatifs
Utilitaires
communs
spcifiques et
IHM Administration
Tlcoms
DataWare
Sant Finance
non standardiss
House
WorkFlow
Bus dobjets rpartis (ORB)
Nommage Persistance
Interrogations
Externalisation
Evnements
Relations
Vendeur
Collections
Transactions Cycle de vie

ChangementsTemps
Proprits
Concurrence
Licences
Scurit
Services objet communs
Fig. 7.1: OMA, l'architecture globale de CORBA
INT 2004
Le bus dobjets rpartis est la cl de vote de larchitecture globale

de lOMG. Il assure le transport des requtes entre tous les objets
CORBA. Il offre un environnement dexcution aux objets masquant
lhtrognit lie aux langages de programmation, aux systmes
dexploitation, aux processeurs et aux rseaux. Ce bus est plus
amplement dtaill dans la suite.
Les services objet communs (CorbaServices) fournissent sous
forme dobjets CORBA, spcifis grce au langage OMG-IDL, les
fonctions systmes ncessaires la plupart des applications
rparties. Actuellement, lOMG a dfini des services pour les
annuaires (Nommage et Vendeur), le cycle de vie des objets, les
relations entre objets, les vnements, les transactions, la scurit, la
persistance, etc. Au fur et mesure des besoins, lOMG ajoute de
nouveaux services communs. Ces services seront dtaills dans le
paragraphe suivant.
Les utilitaires communs (CorbaFacilities) sont des canevas dobjets
qui rpondent plus particulirement aux besoins des utilisateurs. Ils
standardisent linterface utilisateur, la gestion de linformation,
ladministration, etc.
Les interfaces de domaine (Domain Interfaces) dfinissent des
objets de mtiers spcifiques des secteurs dactivits comme la
finance (monnaie lectronique), la sant (dossier mdical) et les
tlcoms (transport multimdia). Leur objectif est de pouvoir assurer
linteroprabilit smantique entre les systmes dinformations
dentreprises dun mme mtier: les Business Object Frameworks
(BOFs).
INT-LOR-GRS-v2.03
79
Les objets applicatifs (Application Objects) sont ceux qui sont

spcifiques une application rpartie et ne sont donc pas
standardiss. Toutefois, ds que le rle de ces objets apparat dans
plus dune application, ils peuvent alors rentrer dans une des
catgories prcdentes et donc tre standardiss par lOMG [OMG].
Les services objet communs

Les services objets communs couvrent les services de nommage, de
persistance, d'annuaire, de cycle de vie des objets, etc. Ces services tous
dcrits l'aide de l'IDL, sont ncessaires dans les systmes distribus. Ils
permettent d'isoler clients et serveurs des dtails d'implmentation dus
leur localisation ou leur tat d'activation. Leur objectif est donc de
standardiser les interfaces des fonctions systme indispensables la
construction et l'excution de la plupart des applications rparties.
La recherche d'objets
Cette
catgorie
de
services
offre
les
mcanismes
pour
rechercher/retrouver dynamiquement sur le bus les objets ncessaires
aux applications. Ce sont les quivalents des annuaires tlphoniques:
Le service Nommage (Naming Service) est lquivalent des pages
blanches: les objets sont dsigns par des noms symboliques. Cet
annuaire est matrialis par un graphe de rpertoires de dsignation.
Le service Courtage (Trader Service) est lquivalent des pages
jaunes: les objets peuvent tre recherchs en fonction de leurs
caractristiques.
La vie des objets

Cette catgorie regroupe les services prenant en charge les diffrentes
tapes de la vie des objets CORBA.
Le service Cycle de Vie (Life Cycle Service) dcrit des interfaces pour
la cration, la copie, le dplacement et la destruction des objets sur le
bus. Il dfinit pour cela la notion de fabriques dobjets Object
Factory.
Le service Proprits (Property Service) permet aux utilisateurs
dassocier dynamiquement des valeurs nommes des objets. Ces
proprits ne modifient pas linterface IDL, mais reprsentent des
besoins spcifiques du client comme par exemple des annotations.
Le service Relations (Relationship Service) sert grer des
associations dynamiques (appartenance, inclusion, rfrence, auteur,
emploi,...) reliant des objets sur le bus. Il permet aussi de manipuler
des graphes dobjets.
Le service Externalisation (Externalization Service) apporte un
mcanisme standard pour fixer ou extraire des objets du bus. La
migration, le passage par valeur, et la sauvegarde des objets doivent
reposer sur ce service.
Le service Persistance (Persistent Object Service) offre des
interfaces communes un mcanisme permettant de stocker des
objets sur un support persistant. Quel que soit le support utilis, ce
service sutilise de la mme manire via un Persistent Object
Manager. Un objet persistant doit hriter de linterface Persistent
Object et dun mcanisme dexternalisation.
INT 2004
INT-LOR-GRS-v2.03
80
Le service Interrogations (Query Service) permet dinterroger les

attributs des objets. Il repose sur les langages standards
dinterrogation comme SQL3 ou OQL. Linterface Query permet de
manipuler les requtes comme des objets CORBA. Les objets
rsultats sont mis dans une collection. Le service peut fdrer des
espaces dobjets htrognes.
Le service Collections (Collection Service) permet de manipuler
dune manire uniforme des objets sous la forme de collections et
ditrateurs. Les structures de donnes classiques (listes, piles, tas,..)
sont construites par sous-classement. Ce service est aussi conu
pour tre utilis avec le service dinterrogations pour stocker les
rsultats de requtes.
Le service Changements (Versionning Service) permet de grer et de
suivre lvolution des diffrentes versions des objets. Ce service
maintient des informations sur les volutions des interfaces et des
implantations. Cependant, il nest pas encore spcifi officiellement.
La sret de fonctionnement
Cette catgorie de services fournit les fonctions systme assurant la
sret de fonctionnement ncessaire des applications rparties.
Le service Scurit (Security Service) permet didentifier et
dauthentifier les clients, de chiffrer et de certifier les communications
et de contrler les autorisations daccs. Ce service utilise les notions
de serveurs dauthentification, de clients/rles/droits (et dlgation de
droits), dIIOP scuris.
Le service Transactions (Object Transaction Service) assure
lexcution de traitements transactionnels impliquant des objets
distribus et des bases de donnes en fournissant les proprits
ACID (Atomicit - Concurrence - Intgrit - Durabilit).
Le service Concurrence (Concurrency Service) fournit les
mcanismes pour contrler et ordonnancer les invocations
concurrentes sur les objets. Le mcanisme propos est le verrou. Ce
service est conu pour tre utilis conjointement avec le service
Transactions.
Les communications asynchrones

Par dfaut, la coopration des objets CORBA est ralise selon un mode
de communication client/serveur synchrone. Toutefois, il existe un
ensemble de services assurant des communications asynchrones.
Le service Evnements (Event Service) permet aux objets de
produire des vnements asynchrones destination dobjets
consommateurs travers des canaux dvnements. Les canaux
fournissent deux modes de fonctionnement. Dans le mode push ,
le producteur a linitiative de la production, le consommateur est notifi
des vnements. Dans le mode pull , le consommateur demande
explicitement les vnements, le producteur est alors sollicit.
Le service Notification (Notification Service) est une extension du
service prcdent. Les consommateurs sont uniquement notifis des
vnements les plus intressants. Pour cela, ils posent des filtres sur
le canal rduisant ainsi le trafic rseau engendr par la propagation
des vnements inintressants.
Le service Messagerie (CORBA Messaging) dfinit un nouveau
modle de communication asynchrone permettant de grer des
INT 2004
INT-LOR-GRS-v2.03
81
requtes persistantes lorsque lobjet appelant et lobjet appel ne sont

pas prsents simultanment sur le bus.
Autres fonctions
Le service Temps (Time Service) fournit des interfaces permettant

dobtenir une horloge globale sur le bus (Universal Time Object), de
mesurer le temps et de synchroniser les objets.
Le service Licences (Licensing Service) permet de mesurer et de
contrler lutilisation des objets, et cela en vue de facturer les clients
et de rmunrer les fournisseurs.
Les interfaces de domaine

L'OMG vise travers ces spcifications d'offrir une description standard
des objets et des services communs une industrie donne ou un
secteur d'activit. Ces efforts sont effectus au sein de groupes de travail
nomms selon chaque secteur, parmi ces groupes:
Business Objects DTF standardise les mthodogies et les
technologies pour la conception dapplications mtier au dessus de
CORBA.
Workflow Workgroup travaille sur les outils CORBA ncessaires au
fonctionnement des applications de gestion de flux de travail
indispensables aux activits coopratives au sein des entreprises.
C4I DSIG fait la promotion de CORBA au sein des organismes et
administrations lis la dfense en jouant un rle pdagogique.
End User SIG travaille en relation avec les utilisateurs finaux fin de
dterminer leurs besoins, de connatre leurs expriences pour mieux
orienter les futurs technologies CORBA.
CORBAmed dfinit les standards OMG pour le domaine de la
mdecine. Ces standards permettront linteroprabilit entre les
acteurs de la sant en dfinissant par exemple la notion dobjets
patient.
Life Sciences Research DTF est un nouveau groupe ddi
lutilisation de CORBA par les instituts de recherche dans les sciences
de la vie: les universits et les laboratoires pharmaceutiques.
Electronic Commerce sintresse la dfinition de technologies
CORBA pour les applications de commerce lectronique.
Financial Services DTF produit les spcifications OMG lies au
domaine de la finance/banque comme, par exemple, la dfinition
dobjets monnaie et dobjets convertisseur de monnaie.
Telecom DTF fait la liaison entre le monde CORBA et le monde des
tlcommunications.
Internet Platform SIG travaille sur les rapprochements des
technologies CORBA avec les technologies dInternet. Il tudie
principalement les relations avec le World Wide Web.
Manufacturing DFT tente de combler le foss entre les technologies
OMG et les besoins des industries.
Realtime SIG rflchit sur la prise en compte des aspects temps rel
au sein du bus CORBA.
Distributed Simulation SIG adresse les problmes lis la
simulation distribue et son excution au dessus dun bus CORBA.
INT 2004
INT-LOR-GRS-v2.03
82
Test SIG doit dfinir les mthodologies, les outils, les protocoles pour
automatiser les tests dapplications rparties CORBA.
Object Model Working Group travaille sur lunification des modles
orients objet en vue de crer un standard plus gnraliste que celui
propos actuellement par CORBA.
UML Revision Task Force travaille sur le futur du langage UML. Ce
langage, standardis par lOMG, est une notation graphique pour
dfinir des modles orients objet [OMG].
Le langage de description
d'objets IDL
Les services CORBA sont dcrits par l'IDL (Interface Definition
Language). C'est un langage de spcification indpendant de tout
langage de programmation utilis pour implmenter les comportements
des objets. La communication entre les programmes client et serveur se
fait via l'ORB, qui reprsente en fait l'infrastructure de communication. La
robustesse de la norme CORBA revient notamment cette sparation
entre le client et le serveur, qui est la fois en terme de langage de
programmation mis en uvre, de protocoles rseau et de mcanismes de
transport de donnes. Cet isolement permet aussi de concrtiser les
bnfices attendus de l'adoption des systmes d'objet distribus.
L'IDL est donc un outil utilis pour dfinir les interfaces d'objets d'une
faon universelle. C'est un langage de description et non
d'implmentation. Il ne comprend pas donc de constructeurs car il
n'implmente rien, il ne fait que dcrire. Il ajoute un certain nombre de
mots cl pour spcifier les systmes distribus. L'IDL est utilis pour
rendre les applications compltement indpendantes des langages.
L'IDL est le rsultat d'un travail de l'OMA (Object Management
Architecture) qui consistait donner naissance un langage indpendant.
Le langage OMG-IDL (Interface Definition Language) permet dexprimer,
sous la forme de contrats IDL, la coopration entre les serveurs et les
clients de services, en sparant linterface de limplmentation des objets
et en masquant les divers problmes lis linteroprabilit,
lhtrognit et la localisation de ceux-ci. Un contrat IDL spcifie les
types manipuls par un ensemble dapplications rparties, cest--dire les
types dobjets (ou interfaces IDL) et les types de donnes changs entre
les objets. Le contrat IDL isole ainsi les clients et serveurs de
linfrastructure logicielle et matrielle les mettant en relation travers le
bus CORBA.
De l'IDL aux langages de programmation

Une fois le langage d'implmentation choisi, un mapping (ou projection)
entre le source IDL et le langage dsir doit tre fait grce un
compilateur IDL (voir figure 7.2). Le compilateur IDL produit du code
source pour le client et pour le serveur dans le langage de programmation
cible [CAJB]. Ces compilateurs gnrent automatiquement la souche et la
squelette dans la langage de programmation choisi. La souche implante
la liaison entre l'application cliente et l'ORB, tandis que la squelette
implante la liaison entre l'ORB et le serveur pour l'objet considr. Il reste
INT 2004
INT-LOR-GRS-v2.03
83
en suite au programmeur que d'crire, du ct serveur les methodes de

l'objet, et du ct client la logique d'envoie des messages.
Contrat ou
Source IDL
Bus
CORBA
Souche
(Stub) client
Squelette
(Skeleton)
serveur
C, C++, Java, Smalltalk
C
,
C++,
Smalltalk
Java,
Fig. 7.2: Compilateur IDL
La traduction de l'IDL vers un langage d'implantation s'appelle la

projection. Les contrats IDL sont projets en souches IDL (ou interface
dinvocations statiques SII) dans lenvironnement de programmation du
client et en squelettes IDL (ou interface de squelettes statiques SSI) dans
lenvironnement de programmation du fournisseur. Le client invoque
localement les souches pour accder aux objets. Les souches IDL
construisent des requtes, qui vont tre transportes par le bus, puis
dlivres par celui-ci aux squelettes IDL qui les dlgueront aux objets.
Ainsi le langage OMG-IDL est la cl de vote du bus dobjets rpartis
CORBA.
Afin de garantir la portabilit des applications d'un bus vers un autre, les
rgles de projection sont normalises. Elles traduisent prcisment
chaque construction IDL en une ou plusieures constructions du langage
cible. Elles dfinissent galement les rgles d'utilisation correctes de ces
traductions. Les rgles existantes actuellement concernent les langages
suivants: C, C++, SmallTalk, Ada, Java et Cobol orient objet. Le tableau
7.1 donne des exemples de ces rgles de projection:
Construction OMG-DL
module M { };
Interface
{};
String
Projection en C++
Projection en Java
Au choix du produit CORBA:

namespace M { }
ou class M { } ou
prfixe M_
Package M
J:I Class J:public virtual Interface J

I {};
extends I {}
char *
java.lang.String
Tableau 7.1: Exemples de rgles de projection
Ainsi, chaque produit CORBA fournit un pr-compilateur IDL pour chacun

des langages supports, mais aussi de bus CORBA cible. Le code des
applications est alors portable dun bus un autre car les
INT 2004
INT-LOR-GRS-v2.03
84
souches/squelettes gnrs sutilisent toujours de la mme manire quel

que soit le produit CORBA. Par contre, le code des souches et des
squelettes IDL nest pas forcment portable car il dpend de limplantation
du bus pour lequel ils ont t gnr.
Le mode statique et le mode dynamique

Le prcompilateur OMG-IDL gnre automatiquement les souches de
communication avec les objets. Ces souches utilisent le bus pour raliser
la coopration des objets des applications. Cette approche statique est
bien adapte pour la conception et l'excution d'applications dont les
spcifications OMG-IDL sont stables. Nanmoins, dans la plupart des
applications complexes, certaines spcifications voluent au cours du
temps par l'ajout de nouvelles oprations et/ou de nouveaux types
d'objets ou par la modification des spcifications existantes. Dans ces
contextes, l'approche statique, par prgnration automatique de
souches, ne convient plus. Elle cre un lien statique ( la compilation)
entre les applications clientes et les interfaces IDL des objets utiliss.
Ainsi, lorsque les interfaces voluent, il faut modifier et recompiler toutes
les applications clientes et serveurs.
D'un autre ct, CORBA offre un ensemble de mcanismes pour exploiter
et implanter dynamiquement des objets rpartis: le rfrentiel des
interfaces (IFR), l'interface d'invocations dynamiques (DII) et l'interface de
squelettes dynamiques (DSI). Ces mcanismes dynamiques (qu'on
dtaillera dans la partie 7.3) permettent de construire des applications qui
sadaptent automatiquement aux changements et volutions des
spcifications IDL.
La syntaxe IDL
Ce paragraphe montre l'aide d'un exemple simple la syntaxe dIDL. Il
s'agit dans cet exemple d'un guichet bancaire qui distribue
automatiquement des billets, en utilisant une carte de crdit. La
prsentation d'un tel objet et ses interactions avec le clavier, le lecteur de
cartes et l'imprimante est comme suit:
Dans un premier temps on s'aperoit que la syntaxe de l'IDL prsente
d'indiscutables ressemblances avec celle de C++. Cependant, de
// Exemple DL pour un distributeur automatique de billets
module DAB{ typedef string BandeMagnetique;
interface Entre { typedef string CommandeOprateur;
void SaisieCarte( in BandeMagnetique item);
void SaisieClavier( in CommandeOprateur cmd); };
interface Sortie{ boolean Impression( in string texte); };
interface TerminalDAB{ void FinDeTransaction();
void RapportDeTransaction();
};
};
nombreuses diffrences existent entre les deux: la smantique n'est pas
la mme, les paramtres dans les dclarations doivent tre nomms et
quantifis, etc. IDL est un langage de description fortement typ. En effet,
toute variable et attribut d'objet doit tre d'un type formellement dfini.
L'IDL comporte une longue liste de types de base partir desquels de
nouveaux types peuvent tre dfinis, ainsi quun type passe-partout, le
INT 2004
INT-LOR-GRS-v2.03
85
type any qui englobe tous les autres. Le type any est dcod, larrive,
laide dune spcification de type appele typecode. Toutes les
dfinitions de constantes, d'exceptions, d'interfaces et de modules ont
une tendue et ne sont valides qu' l'intrieur de la section o elles
apparaissent. Pour importer des dfinitions extrieures, il faut utiliser
l'oprateur "::". Dans notre exemple, la variable "Commande Oprateur"
n'est valide que dans l'interface Entre.
Une interface est un mot cl du langage IDL qui regroupe des sousensembles cohrents de constantes, de types, d'exceptions, d'oprations
et de variables.
Une opration est dfinie par trois parties obligatoires et trois autres
facultatives. Dans cet exemple aucune option facultative n'apparat. Les
trois options requises sont le type de la valeur renvoye par l'opration, le
nom de l'opration, et enfin la liste des paramtres de l'opration. Chaque
paramtre est qualifi par l'un des mots cl in, out, ou inout, suivi de son
type et de son nom. Dans l'exemple de l'opration impression, le type de
la valeur renvoye est boolean, le nom de l'opration est impression et il
n'y a qu'un paramtre de type de base string, nomm texte. Le mot cl in
indique que ce paramtre est non modifiable.
LORB: le bus d'objets rpartis

CORBA
L'ORB est l'entit charge de l'acheminement des requtes et du retour
des rsultats ou des exceptions vers le client. Le bus CORBA est donc
lintermdiaire/ngociateur travers lequel les objets vont pouvoir
dialoguer. Il fournit les caractristiques suivantes:
La liaison avec tous les langages de programmation:
cependant, actuellement lOMG a seulement dfini officiellement cette
liaison pour les langages C, C++, SmallTalk, Ada, COBOL et Java.
La transparence des invocations: les requtes aux objets semblent
toujours tre locales, le bus CORBA se chargeant de les acheminer
en utilisant le canal de communication le plus appropri.
Linvocation statique et dynamique: ces deux mcanismes
complmentaires permettent de soumettre les requtes aux objets. En
statique, les invocations sont contrles la compilation. En
dynamique, les invocations doivent tre contrles lexcution.
Un systme auto-descriptif: les interfaces des objets sont connues
du bus et sont aussi accessibles par les programmes par
lintermdiaire du rfrentiel des interfaces.
Lactivation automatique et transparente des objets: les objets
sont en mmoire uniquement sils sont utiliss par des applications
clientes.
Linteroprabilit entre bus: partir de la norme CORBA 2.0, un
protocole gnrique de transport des requtes (GIOP pour General
Inter-ORB Protocol) a t dfini permettant linterconnexion de bus
CORBA provenant de fournisseurs distincts, une de ses instanciations
est lInternet Inter-ORB Protocol (IIOP) fonctionnant au-dessus de
TCP/IP.
INT 2004
INT-LOR-GRS-v2.03
86
Les composantes
Le bus CORBA fournit les composantes et services suivants (voir figure
7.3):
ORB (Object Request Broker) est le noyau de transport des requtes
aux objets. Il intgre au minimum les protocoles GIOP et IIOP.
Linterface au bus fournit les primitives de base comme linitialisation
de lORB.
SII (Static Invocation Interface) est linterface dinvocations statiques
permettant de soumettre des requtes contrles la compilation des
programmes. Cette interface est gnre partir de dfinitions OMGIDL.
DII (Dynamic Invocation Interface) est linterface dinvocations
dynamiques permettant de construire dynamiquement des requtes
vers nimporte quel objet CORBA sans gnrer/utiliser une interface
SII.
IFR (Interface Repository) ou banque d'interfaces est le rfrentiel des
interfaces contenant une reprsentation des interfaces OMG-IDL
accessible par les applications durant lexcution.
Client
Serveur
SSI
SII
DII
Interface Bus
DSI
Adaptateur d'objets
OA
Object Request Broker
Rfrentiel Interfaces
IFR
Rfrentiel Implantations
ImpIR
Fig. 7.3: Composantes du bus CORBA
INT 2004
SSI (Skeleton Static Interface) est linterface de squelettes statiques

qui permet limplmentation des objets de recevoir les requtes leur
tant destines. Cette interface est gnre comme linterface SII.
DSI (Dynamic Skeleton Interface) est linterface de squelettes
dynamiques qui permet dintercepter dynamiquement toute requte
sans gnrer une interface SSI. Cest le pendant de DII pour un
serveur.
OA (Object Adapter) est ladaptateur dobjets qui soccupe de crer
les objets CORBA, de maintenir les associations entre objets CORBA
et implmentations et de raliser lactivation automatique si
ncessaire.
ImplR (Implementation Repository) est le rfrentiel des
implmentations qui contient linformation ncessaire lactivation. Ce
rfrentiel est spcifique chaque produit CORBA.
INT-LOR-GRS-v2.03
87
Ces diffrentes composantes sont toutes dcrites dans le langage OMGIDL, ce qui les rend accessibles au travers du bus. Cela permet aussi
dhomogniser les diffrentes implmentations possibles de la norme car
diffrentes approches peuvent tre envisages pour construire un bus:
1 bus = 1 processus: les objets sont dans le mme espace mmoire
que les clients. Cest le cas typique des applications embarques. Ici,
le langage OMG-IDL sert spcifier les objets.
1 bus = 1 OS: les clients et les fournisseurs sont des processus
diffrents sur la mme machine. Le bus CORBA peut alors tre tout
ou partie du systme dexploitation. 1 bus rseau: les processus sont
sur des sites diffrents et les requtes sont vhicules travers le
rseau, cest le cas sur Internet avec IIOP.
Fdration de bus CORBA: plusieurs bus distincts peuvent tre mis
ensemble pour former une fdration. Les communications entre ces
bus peuvent se faire soit par le protocole commun IIOP soit travers
des passerelles spcifiques ou gnriques (DII-DSI).
L'ORB vu du ct client
Du ct du client, l'interface dynamique (DII) permet d'envoyer une
requte (voir figure 7.4) vers n'importe quel objet prsent sur le rseau
un moment donn, en particulier des objets pour lesquels le client n'a
pas de souche. La spcification DII de la norme CORBA dcrit deux
modes d'invocation dynamique, un mode synchrone dans lequel le client
est bloqu en attendant la rponse du serveur et un mode asynchrone
(appel deferred synchronous) o le client n'attend pas la rponse du
serveur et peut la demander plus tard. Le serveur quant lui ne distingue
pas les invocations statiques, qui utilisent la souche du ct client et les
invocations dynamiques qui ne l'utilisent pas. En effet, dans une
invocation statique, le programme client utilise la souche gnre partir
du source IDL pour envoyer ses requtes l'objet distant, par contre dans
une invocation dynamique, le programme client construit dynamiquement
une requte sans utiliser la souche. L'ORB ne fait pas de distinction entre
les deux mcanismes. L'invocation dynamique est importante dans le
sens o elle permet d'isoler les programmes clients de changements dans
l'implmentation des objets, changement de programmes ou changement
de localisation.
La construction d'une invocation dynamique passe par quatre tapes:
L'identification de l'objet destinataire de la requte;
Rcupration de l'interface de l'objet destinataire;
Construction de l'invocation;
Excution et rception des rsultats et des exceptions ventuelles.
La premire tape utilise le service de nommage (Naming service) et le
service d'annuaire (Trader service) pour identifier les objets. Durant
l'excution, le client tant dynamique dcouvre tous les services
disponibles via l'ORB auquel il est connect. L'ORB renvoie ensuite grce
l'opration get_interface une rfrence qui permet d'extraire de la
banque d'interfaces l'information ncessaire la construction de
l'invocation dynamique. A partir de cette information, la norme DII spcifie
une opration create_request pour construire la requte.
La requte est envoye de manire synchrone avec l'opration invoke ou
de manire asynchrone avec l'opration send, qui rend immdiatement le
contrle au programme client. Une fois fait, le client peut s'enqurir de
INT 2004
INT-LOR-GRS-v2.03
88
l'tat de la requte avec l'opration get_response. Lorsque celle-ci

renvoie un rsultat positif, le client peut l'utiliser dans le
Client
Souche1
Requte 1
Client
DII
Souche2
Requte 2
Requte 1
ORB
Invocation statique
ORB
Invocation dynamique
Fig. 7.4: Invocation statique/dynamique ct client
paramtre result de l'opration create_request, sinon le client est inform

d'une exception.
Toute la squence de ces oprations aboutit donc au mme rsultat
qu'une invocation statique mais permet en plus d'assurer un complte
indpendance vis--vis des changements d'implantations ou de
localisation des serveurs.
Remarque:
Avant de pouvoir fonctionner, l'ORB doit tre initialis l'aide de
l'opration ORB_init dfinie dans le module CORBA de la norme Corba.
Cette initialisation peut tre faite plusieurs fois et renvoie les mmes
rsultats si les mmes paramtres sont utiliss.
L'ORB vu du ct serveur
Du ct serveur, la situation est plus complique qu'elle ne l'est de ct
client. L'Adaptateur d'Objet (OA Object Adapter) se charge de donner
l'impression au client que l'objet qu'il invoque est toujours actif, et prt
rpondre ses requtes. Il dfinit galement l'interface entre le serveur et
l'ORB. Cette complexit provient du fait que dans un rseau dynamique,
les serveurs peuvent actifs ou inactifs, et chaque serveur peut
implmenter un ou plusieurs objets. L'Adaptateur d'Objet permet de
prparer les objets la rception des requtes et d'informer l'ORB une
fois ces requtes sont excutes. Il est aussi responsable de la
sauvegarde de l'tat des objets si ceux-ci sont amens tre dsactivs
entre deux requtes. L'Adaptateur d'Objet assure, plus concrtement, les
INT 2004
INT-LOR-GRS-v2.03
89
fonctions suivantes en s'appuyant sur l'ORB ou sur les Services Objet

Communs (CorbaServices):
Gnration et interprtation des rfrences aux objets;
Invocation des mthodes;
Scurit des interactions;
Activation et dsactivation des serveurs et des implmentations
d'objets;
Enregistrement des implmentations.
L'Adaptateur d'Objets dpend de la nature du serveur. Plusieurs types
d'adaptateurs existent alors, l'un des plus grands et spcifi par la norme
Corba est le BOA Adaptateur d'Objets de base (Basic Object Adaptor). Il
suppose que le serveur est une application spare de l'application
cliente. Le Library Object Adapter, est un Adaptateur d'Objet qui suppose
que le serveur est en fait une DLL qui sera charge dynamiquement dans
l'application cliente, et l'Object-Oriented Database Adaptor, qui suppose
que le serveur est une base de donnes oriente objet. De mme on
pourrait imaginer des Adaptateurs d'Objets conus pour des systmes
d'objets diffrents, spcifiques des besoins particuliers.
Du ct du serveur les requtes passent soit par le squelette associ un
objet donn, soit par le DSI dans le cas dynamique (voir figure 7.5).
Serveur
Serveur
BOA
BOA
Squelet
te 1
Squelet
te2
Requte
1
Requte
2
DSI
Requte
1
ORB
Invocation
statique
ORB
Invocation dynamique
Fig. 7.5: Invocation statique/dynamique ct serveur
INT 2004
INT-LOR-GRS-v2.03
90
Conclusion
Le serveur a la charge de dcoder l'objet destinataire. Les objets dans les
serveurs sont administrs par le BOA ou par un Adaptateur d'Objets
spcifique au serveur correspondant.
Chaque objet du cot serveur est connu par un squelette. De mme qu'il
existe une interface d'invocation dynamique du ct client, la norme
Corba dfinit galement une interface dite de squelette dynamique
(skeleton dynamic) du ct serveur. Le DSI reprsente en fait
l'homologue du DII se trouvant au ct client. Le DSI permet l'ORB de
transmettre des requtes des objets pour lesquels le serveur n'a pas de
squelette proprement parler. Ceci est notamment le cas lorsqu'on
cherche intgrer des applications non conformes CORBA: non orient
objet ou antrieures la norme, etc. Le DSI est comme le DII, il permet
d'offrir une flexibilit et une adaptabilit dans l'volution et la maintenance
des systmes d'objets distribus. Un des avantages du DSI rside dans
son utilisation pour communiquer d'un ORB un autre. En effet, le DSI
permet de construire aisment des passerelles entre ORBs, le serveur du
premier ORB est en mme temps client du second pour des objets
distants en question.
La norme CORBA distingue la couche des services avec le langage de
spcification IDL, et la couche transport avec la spcification de l'ORB.
Les services sont dfinis sous forme d'objets en IDL, les compilateurs les
transforment en des programmes clients et serveurs dans les langages de
programmation choisis par les programmeurs. L'ORB est quant lui dfini
de manire trs gnrale, tant du ct client que du ct serveur, dans
l'optique d'une intgration facile dans des schmas trs varis. Il offre des
mcanismes compltement dynamiques (DII et DSI) qui sont
particulirement adapts des systmes d'informations amens
voluer rapidement, protgeant ainsi clients et serveurs des changements
d'implmentation ou de localisation qui pourraient survenir. Ils permettent
galement d'interconnecter des ORB diffrents ou un ORB une
application non orient objet.
CORBA dun point de vue

gestion de rseaux
Pour conclure ce chapitre, quelques proprits rendant CORBA trs
attractif pour la conception de systmes distribus:
Courbe dapprentissage minimale pour un programmeur Java ou C++;
Vritable orientation objet profonde;
Lobjet est implicitement distant aux yeux du programmeur (sous
CMIS/P, lobjet est explicitement distant);
Adoption trs largie (cest le bus standard remplaant le RMI de
Java);
Maturit des produits;
Adoption par lITU-T sous influence de TINA
Remarquons nanmoins que CORBA ne sera jamais un remplaant
1 pour 1 de CMIS-P, qui offrait de puissants accs (scoping, filtering) et
dont la notion de Managed Object ne trouve pas directement dquivalent
sous CORBA.
INT 2004
INT-LOR-GRS-v2.03
91
Chapitre 8 - Larchitecture NGOSS du

TeleManagement Forum
Le consortium TMF
Le TeleManagement Forum (TM Forum) est un consortium priv but
non lucratif qui fournit une stratgie ainsi que des solutions pratiques pour
amliorer la gestion et le fonctionnement des services de communication
et dinformation. Le TM Forum liste plus de 350 membres comprenant tant
des fournisseurs de services, des quipementiers, des socits de
services ou des intgrateurs, et ce du monde entier.
Parmi les entrants rcents, il est noter une forte participation dorigine
chinoise.
Lesprit du TM Forum consiste traditionnellement en limplication
personnelle de consultants privs soutenus par leurs employeurs.
Le cheval de bataille actuel du TM Forum est le New Generation
Operations Systems and Software (NGOSS). Il sagit dun programme
intgr innovant, pour le dveloppement et le dploiement de systmes et
de logiciels.
Le programme NGOSS fait partie du programme technique global du TM
Forum, qui sattache des activits collaboratives facilitant
limplmentation relle des services de tlcommunications.
Le TM Forum contribue au domaine des TIC depuis plus de 15 ans. A
citer parmi les rsultats les plus connus, le TOM et le TMN++ (vue C++ de
laccs aux objets du TMN).
On trouvera sur le site www.TMForum.org de nombreuses informations et
documents de haute qualit.
Le NGOSS
Le NGOSS se propose doffrir un standard pour le dveloppement et le
dploiement de composants OSS/BSS facilement intgrables, grables et
flexibles.
Le NGOSS est constitu dun ensemble de documents jouant le rle
doutils de spcifications industrielles, et de conseils qui couvrent des
domaines stratgiques. Une mthodologie dutilisation des outils est
fournie.
Le NGOSS repose sur une approche oriente cycle de vie en ce qui
concerne le dveloppement de systmes de gestion; cette approche
utilise des dfinitions claires des processus daffaire (business
processes), des spcifications pour automatiser ces processus ainsi que
des outils de test des systmes vis--vis de la conformance au NGOSS.
INT 2004
INT-LOR-GRS-v2.03
92
En rsum, le NGOSS est un paradigme architectural proposant une

approche intgrant quatre axes:
Une analyse des processus et flux opratoires de loprateur (les
workflows ou business processes dans le jargon TMF); cette
tape utilise le eTOM (extended Telecom Operations Map) qui est
dtaill plus bas;
Lanalyse et la conception du systme, qui est base sur le SID
(Shared Information Data);
Lanalyse et la conception de la solution, qui sintresse aux
problmes dinteroprabilit et propose une approche oriente
contrats pour les interfaces entre systmes;
La validation de la solution vis--vis des critres de conformit mis
par le TMF.
La figure 8.1 illustre lapproche propose:
Fig. 8.1: vue densemble du NGOSS
Il est noter que les solutions bases sur le NGOSS, selon lesprit des
concepteurs,
utiliseront
des
concepts
et
des
technologies
conventionnelles disponibles immdiatement sur le march. Il sagit donc
dune approche essentiellement pragmatique facilitant lacceptance. Cet
aspect est comparer avec lapproche de TINA.
Par ailleurs le NGOSS nest prescriptif que pour les points de rfrence
dits cardinaux o linteroprabilit est obligatoire. Ceci permet la fois
daccrotre la comptitivit (grce lefficacit des composants NGOSS)
et de respecter lutilisation des systmes lgataires.
INT 2004
INT-LOR-GRS-v2.03
93
Les sections suivantes vont dtailler les quatre axes du NGOSS: le

eTOM, le SID, les contrats et la TNA, la validation et la conformit.
Le eTOM
La figure 8.2 montre les diffrents composants de la enhanced Telecom
Operations Map (eTOM).
INT 2004
INT-LOR-GRS-v2.03
94
Customer
Strategy, Infrastructure & Product
Operations
Strategy &
commit
Infrastructure
Fulfillment
Readiness
Assurance
Billing
Lifecycle management
Marketing &
Offer Management
Customer Relationship
Management
Service Development
& Management
Service Management
& Operations
Resource Development
& Management
Resource Management
& Operations
(Application, Computing and Network)
(Application, Computing and Network)
Supply Chain Development

& Management
Enterprise
mgnt
Enterprise
Management
Supplier/Partner Relationship
Management
Brand Management,
Strategic
Market Research &
advertising
&
Stakeholder &
External
Security & Fraud
Relations mgt
Disaster recovery
Planning
management
Research &
Financial &
Asset
management
Human
Resources
Technology
Development
acquisition
Enterprise Quality
Management, Process
& IT
Fig. 8.2: le eTOM
La enhanced Telecom Operations Map est une initiative continue du TM

Forum pour fournir un modle daffaire et une architecture destins aux
fournisseurs de services et autres acteurs de lindustrie des
tlcommunications. Il dcrit lensemble des processus dentreprise
utiliss par un fournisseur de services et les analyse selon diffrents
niveaux de dtail selon leur importance et leur priorit. Pour ces
entreprises, ces analyses serviront de support au cadre dcisionnel par
rapport la gouvernance stratgique; dautre part, elles fournissent un
INT 2004
INT-LOR-GRS-v2.03
95
point de rfrence neutre par rapport aux rvisions des processus

internes, des partenariats, alliances, et autres relations avec les acteurs
impliqus. En ce qui concerne les fournisseurs par exemple, le eTOM
souligne les frontires potentielles des composants logiciels en fonction
des besoins des clients, et dnote les fonctions, les entres et les sorties
ncessaires.
Le eTOM est bas sur le TOM tout en le gnralisant pour quil devienne
un modle de processus daffaire complet supportant:
Un modle pour le-entreprise;
Un processus systmatique de dcomposition des processus, des flux
et de leurs descriptions.
Ces spcifications de processus, qui comprennent des dfinitions de haut
niveau de linformation requise, reprsentent un lien fondamental avec le
travail systmique du NGOSS.
Le SID (Shared Information Data

model)
Lindustrie des tlcommunications a besoin de technologies avances
pour amliorer le dlai de mise sur march des nouveaux produits et
services. Les fournisseurs, de leur ct, savent quen proposant des
solutions et des composants de gestion intgrs, la future intgration
globale en sera simplifie; avec comme consquence la diminution du
temps ncessaire au dploiement des nouveaux services. Pour obtenir
une gestion intgre de ces diffrents composants, un vocabulaire
commun doit tre dfinit et doit faire lobjet dun accord global.
Le modle Shared Information/Data (SID) est conu pour fournir ce
vocabulaire commun. Son but est de fournir un ensemble commun de
dfinitions et de relations concernant linformation et les donnes utiliss
dans les architectures NGOSS. Le SID dveloppe en fait trois points de
vue de conceptualisation de linformation:
Une vue oriente affaire des Entits Affaire (business entities) qui
supportent les processus eTOM;
Une vue systme reposant sur la notation UML qui permet de raliser
une solution rpondant au besoin daffaire;
Une vue oriente implmentation, ralise en formalisme spcifique
de la plateforme de dveloppement.
La version actuelle (Phase III) propose des objets ABE (Aggregate
Business Entities) pour les domaines daffaire Client, Produit, Ressource
et ABEs Communs.
La version en cours de dveloppement (Phase IV) introduira de plus une
reprsentation pour la vue systme et raffinera les aspects relationnels
entre ABEs existants.
Le document GB922 avec ses 14 addendums utilise une approche
narrative progressive pour expliquer chacun des Domaines ainsi que les
ABEs associs. Les addendums dcrivent les Entits dAffaires laide de
loutil UML ainsi que dun dictionnaire de donnes facilitant lusage des
processus daffaire du eTOM.
Le SID Phase III version 3.5 comprend des dfinitions dABEs et lUML
associ, pour le Contrat (y compris le SLA), lInteraction dAffaire, les
INT 2004
INT-LOR-GRS-v2.03
96
Types de Base, le Projet, lOrganisation, lEquipe, le Calendrier, le Client,

le Produit, la Qualit de Service, le Rsum du Service, la Ressource
Physique, la Ressource Logique, la Stratgie. De plus, le document
GB922 inclus une architecture SID rvise y compris des spcifications
dABEs jusquau niveau 3 et le mapping entre les ABEs et les processus
eTOM de niveau 2.
Rle au sein du NGOSS

Le SID doit tre considr comme un modle complmentaire du eTOM
en ce sens quil fournit, dun point de vue des entits daffaires, les
modles de rfrence de linformation et des donnes ainsi quun
catalogue commun de vocabulaire supportant les modles daffaires du
eTOM. En consquence le SID et le eTOM, utiliss conjointement, offrent
un outil efficace pour dfinir comment les entits du systme sorganisent
pour rpondre un besoin daffaire.
Applications
Les lments du SID peuvent tre considrs de plusieurs faons. Un
analyste des processus daffaire pourrait par exemple tre intress par
un point de vue affaire des lments de donnes. Dun point de vue
systme, un concepteur de contrat pourrait sintresser aux oprations
agissant sur une entit daffaire.
Conclusion
Les documents du SID consistent en un document principal dcrivant le
modle SID, la relation avec dautres entits du TM Forum, ainsi que des
extraits du contenu du modle. Les nombreux addendums fournissent des
dfinitions dABEs et des modles pour les ABEs communs.
Linterface contractuelle et la
TNA
La Technology Neutral Architecture (TNA) du NGOSS est dfinie par la
suite de documents TMF053.
Lune des approches proposes est la cration de modles
technologiquement neutres en avance de phase sur le dploiement, et
luilisation de plateformes spcifiques. Ceci implique le dveloppement de
vues daffaire, de vues systme et de vues informationnelles en
collaboration avec les activits lies au eTOM, au SID et aux projets
Catalyst3.
Dautre part le TNA spcifie galement un certain nombre de services
gnriques de plateforme (n.b. comparer avec les services COSS de
CORBA). Ceux-ci sont spcifis laide du SID, rsultant en des modles
formels UML.
les projets Catalyst sont des projets industriels concrets bass sur le NGOSS,
partenaires du TMForum.
INT 2004
INT-LOR-GRS-v2.03
97
Linterface contractuelle
Le contrat NGOSS est lunit fondamentale dinteroprabilit au sein dun
systme NGOSS. Linteroprabilit est une notion importante concernant
les quatre vues dfinies sur la mthodologie Cycle de Vie du NGOSS. Par
exemple, le contrat est utilis pour dfinir la spcification dun service,
mais aussi de linformation et le code qui limplmentent. Le contrat est
aussi utilis pour monitorer le service et ainsi assurer que les obligations
externes du contrat (p. ex. concernant un SLA) sont respectes; par
ailleurs il dfinit quelles mesures sont prendre en cas de violation.
Le contrat dfinit galement la faon dutiliser le service (c.a.d. son
invocation). Ceci reprsente davantage quune spcification dinterface
logicielle; on y trouve galement la dfinition de pr- et postconditions, la
smantique associe linvocation, les stratgies affectant la
configuration et lutilisation du service, et bien dautres aspects.
En rsum le contrat est une faon de rifier la spcification dun service
ainsi que dassurer limplmentation du service (y compris des obligations
envers dautres entits du systme).
La Technological Neutral Architecture

Le document TMF053 dcrit les principaux lments de la TNA:
Les contrats,
La transparence de distribution,
Les services de gestion des processus,
Les services de gestion de la SID,
Les services de gestion des stratgies,
Les services dadaptation et de mdiation.
La validation et la conformit
Le programme de conformit
Le programme de conformit a pour but de fournir lintention de
lindustrie des tlcommunications un ensemble de critres de test ansi
que de mthodes de test adaptes. Ce travail cherche permettre
didentifier des produits ou solutions OSS qui sont partiellement ou
pleinement conformes aux principes du NGOSS.
Le programme de test
Le programme de test est une activit continue phase par les world
events du TMForum. Le programme de test finalise actuellement la
couverture du eTOM.
Lensemble des tests sont documents par la suite de documents
TMF050.
Prochaines tapes
A long terme le programme de test aboutira une suite de tests couvrant
lensemble du NGOSS. Le but est daccrditer les produits et solutions
compatibles par un label NGOSS Powered.
INT 2004
INT-LOR-GRS-v2.03
98
Loutil de test en ligne

Un service web permet de tester la compatibilit des produits et
applications avec les standards du NGOSS. Bas sur le moteur Jrules
d'ILOG, cet outil permet dexcuter les tests de compatibilit NGOSS tels
que dfinis par les documents TMF050 et TMF050a, ainsi que de recevoir
des lments informatifs permettant de procder la finition des
applications.
En rsum
Le TMForum propose une architecture nouvelle, intgratrice, originale par
de nombreux aspects. Il est souligner lapproche pragmatique dsireuse
de susciter lacceptance des concepts par les industriels. Dautre part
lapproche propose est radicalement base sur la notion de processus
daffaires (les business processes) desquels sont dduits lensemble des
composants des systmes. Cette approche est trs innovante en ce sens
quelle place, comme on le voit sur la figure 8.2, lutilisateur du systme
la source de toute activit du systme de gestion.
Enfin, il y a un rapport subtil entre larchitecture TINA et le NGOSS. Le
NGOSS entre en quelque sorte de plain pied par la porte quavait
entrouverte TINA et son architecture de services. On peut considrer que
le TMForum reprend de nombreuses ides de TINA (et de CORBA), mais
en les adaptant au monde industriel et ses contraintes, et en les rendant
ainsi bien plus sduisantes.
INT 2004
INT-LOR-GRS-v2.03
99
Conclusion
La gestion de rseaux est lun des domaines les plus complexes auxquels
lon puisse se confronter; elle cumule la distribution, le modle objet, le
temps rel, le transactionnel, la gestion dquipements complexes. Cest
en consquence une source de cot importante pour loprateur, qui se
voit contraint dinvestir des sommes significatives et des comptences
critiques dans une fonction qui semble non immdiatement rentable.
Nanmoins, le souhait exprim ici concerne la comprhension de la
ncessit de la fonction Gestion de Rseaux, et son intrt pour
lentreprise quest loprateur; ce nest qu travers de la gestion efficace
que ce dernier sera en mesure doffrir les services qui le diffrencieront de
la concurrence, tels que des Rseaux Privs Virtuels, de la connectivit
sur demande etc.
Par ailleurs, les auteurs de ce document souhaitent exprimer leur souci de
situer cet expos au fil du temps, les technologies voluant au fur et
mesure de leur cycle de vie et se succdant les unes les autres. Nous ne
sommes pas dans un monde de certitudes dans ce domaine, mais au
contraire dans une sphre dinterrogations et de remises en cause
permanentes, ce qui de lavis des auteurs, doit contribuer une meilleure
rflexion et une plus profonde comprhension du fond de la
problmatique envisage.
INT 2004
INT-LOR-GRS-v2.03

Gestion Reseaux v2.03

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gestion Reseaux v2.03

Transféré par

Droits d'auteur :

Formats disponibles

Gestion de rseaux et services

Gestion de rseaux et services, une introduction

Dont lINT fait partie.

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

1.0: version initiale

Les figures du chapitre 8 par courtoisie du

Gestion de rseaux et services, une introduction

Documents concerns ou cits

Gestion de rseaux et services, une introduction

[19] ISO/IEC ISP 10607-3 (1995): "Information technology - International

Gestion de rseaux et services, une introduction

[39] ITU-T Recommendation X.217 (1995): "Information Technology - Open

Gestion de rseaux et services, une introduction

[ISO 10165-1]: ISO 10165-1/ITU-T X.720: Management Information Model, 1993.

Gestion de rseaux et services, une introduction

Table des matires

Gestion de rseaux et services, une introduction

Gestion des performances ............................................................................................27

Gestion de rseaux et services, une introduction

Chapitre 7 - CORBA et la gestion des rseaux.................................................................77

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

Tableau 7.1: Exemples de rgles de projection ....................................................................83

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

Integration Reference Point

Gestion de rseaux et services, une introduction

Chapitre 1 Gestion des rseaux

Les disciplines de l'administration d'un systme

Ladministration des utilisateurs

Gestion de rseaux et services, une introduction

la qualit de service, qui est la perception du rseau ressentie par

Ladministration des serveurs

Ladministration de la machine de transport

Les architectures de l'administration des rseaux

Gestion de rseaux et services, une introduction

Fig. 1.1: les modles dorganisation

Gestion de rseaux et services, une introduction

utilisation dpend de l'environnement et de la complexit des services

Fig. 1.2: architecture centralise

Les fonctionnalits de l'administration des rseaux

La gestion des fautes

La gestion des configurations et des noms

La gestion des performances

Les critres pour une organisation logique

Gestion de rseaux et services, une introduction

tre de deux types: les informations issues directement du systme gr

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

Chapitre 2 - Comparaison gestion TMN

Comparaison des modles

Modlisation des classes d'objets grs

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

Un paquetage est dcrit l'aide d'un formulaire. Si le paquetage peut tre

Groupe_compteur ATTRIBUTE GROUP <Nom du groupe d'attribut>

Gestion de rseaux et services, une introduction

Gestion de rseaux et services, une introduction

cette opration, si l'objet de gestion contient d'autres objets de gestion,

Fig. 2.2: larbre de nommage

Gestion de rseaux et services, une introduction

Modle informationnel de la communaut Internet