Architecture de rseau dinformation

des tlcommunications TINA

par Simon ZNATY

Directeur technique dEFORT (tudes et Formations en Tlcommunication)

1. Architecture TINA ...................................................................... TE 7 380 - 2

2. Architecture de traitement ........................................................ 3
2.1 Concepts de modlisation dinformation .................................................. 3
2.2 Concepts de modlisation de traitement................................................... 4
2.2.1 Objet de traitement............................................................................. 4
2.2.2 Interface opration ............................................................................. 4
2.2.3 Interface flot ........................................................................................ 4
2.2.4 Spcification des objets de traitement et de leurs interfaces ......... 4
2.3 Concepts de modlisation dingnierie ..................................................... 4
2.4 Services du TINA DPE ................................................................................. 5
3. Architecture de service .............................................................. 6
3.1 Objectifs........................................................................................................ 6
3.2 Session ......................................................................................................... 7
3.2.1 Session daccs................................................................................... 7
3.2.2 Session de service .............................................................................. 8
3.2.3 Session de communication ............................................................... 8
4. Architecture de ressource.......................................................... 8
4.1 Modlisation des ressources gres : modle gnrique de ressource
de rseau TINA (NRIM) ............................................................................... 8
4.1.1 Rseau en couche............................................................................... 8
4.1.2 Connectivit dans la couche .............................................................. 9
4.1.3 Subdivision par rapport la topologie ............................................. 9
4.1.4 Subdivision par rapport la connectivit......................................... 9
4.1.5 Relations entre couches adjacentes et adaptation .......................... 9
4.1.6 Structure du modle NRIM ................................................................ 9
4.2 Gestion des connexions TINA .................................................................... 10
4.2.1 Fragment de graphe de connexions ................................................. 11
4.3 Spcification des interfaces ........................................................................ 11
5. Conclusion ................................................................................. 13
Doc. TE 7 380
Pour en savoir plus ............................................................................

H istoriquement, le concept de rseau intelligent (IN, Intelligent Network)

plonge ses racines dans les notions de rseau et de services. Larchitec-
ture du rseau intelligent repose sur un ensemble de principes : sparation du
traitement dappel et des services, cration et dploiement rapide des services,
indpendance vis--vis des fournisseurs, etc. mesure que le rseau intelligent
se dveloppe, larchitecture doit tenir compte de possibilits plus complexes au
niveau du rseau (connexions large bande, multimdias, multipoints, multi-
destinataires), ce qui accrot le besoin de souplesse. La cration souple et
lintroduction de nouveaux services doivent reposer sur de nouveaux principes,

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms TE 7 380 1
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA ___________________________________________________________________

comme la sparation de lapplication et des ressources quelle met en uvre,

la gestion facile des donnes des clients, etc. Pour rpondre ses besoins, le
consortium TINA (Telecommunications Information Networking Architecture) a
dvelopp une architecture globale permettant la cration, le dploiement,
lexploitation et la gestion des services lchelle mondiale. Il sagit dlaborer
un modle de rfrence homogne pour des architectures de tlcommunica-
tion ouvertes englobant des services dexploitation et de gestion, intgrant
les domaines rseau intelligent et rseau de gestion des tlcommunications
(TMN, Telecommunications Management Network). TINA utilise les progrs les
plus rcents en traitement rparti (ODP, Open Distributed Processing), et en
conception oriente-objet pour assurer linteroprabilit, la rutilisation du logi-
ciel et des spcifications, la rpartition flexible du logiciel et lhomognit
dans la conception des services et leur gestion. Linitiative TINA vise jeter les
bases techniques de la gnralisation et du dploiement des services dinfor-
mation dans les rseaux et influer sur les normes IN et TMN futures ou sur
leur volution.
Pour ce faire, le consortium TINA a dfini un ensemble de concepts fortement
inspirs du modle de rfrence ODP et du rseau de gestion de tlcommu-
nications (TMN) pour dfinir une architecture globale centre sur le concept de
services de tlcommunication et offrant un environnement qui, dune part
facilite la cration de service et la gestion de service et de rseau et dautre part
supporte linterfonctionnement des systmes htrognes.

Du mme auteur, on pourra se reporter larticle consacr la prsentation du rseau intel-

ligent [TE 7 320].

1. Architecture TINA La troisime catgorie fait rfrence aux ressources physiques

Un service ralis selon les principes et concepts dfinis par
TINA (Telecommunications Information Network Architecture) [1]
comme tout autre service de tlcommunication ou dinformation,
consiste en un ensemble de composants de services interagissant
entre eux. Chaque composant de service peut tre lui-mme
dcompos en un ensemble dobjets de traitement. La communi-
cation (interaction) entre objets de traitement est supporte dans
TINA par des mcanismes de distribution offerts par un environne-
ment de traitement rparti.
Afin dobtenir une bonne structuration, modularit et rutilisabi-
lit dans larchitecture TINA, trois catgories de composants de
service sont dfinies (figure 1) :
composants de service ;
composants de ressources ;
lments.
Dans la premire catgorie, nous trouvons les composants utili-
ss pour la cration de services de tlcommunication et services
de gestion. Le consortium TINA (TINA-C) a entre autres prdfini
certains composants appartenant cette catgorie et devant pren-
dre place dans tout dploiement de service de tlcommunication.
On peut citer le gestionnaire de session de communication dont le
rle est dallouer les ressources de communication associes une
session de service.
Ces composants de service peuvent utiliser les composants de
ressources, ces derniers fournissant une reprsentation abstraite
des ressources physiques disponibles. Parmi les composants de
ressources dfinis dans la deuxime catgorie, sont prsentes les
ressources de transmission et les ressources de commutation.
telles que les commutateurs, les ordinateurs et les quipements
spciaux (quipements multimdias par exemple).
Labstraction des ressources physiques apparat aux couches
gestion dlment de rseau et gestion de rseau (EML et NML) du
TMN (Telecommunications Management Network) [2]. Larchitec-
ture TINA peut donc tre perue comme larchitecture TMN avec
les couches gestion de service, gestion de rseau, gestion dl-
ment de rseau et lment de rseau.
Larchitecture TINA est subdivise en trois architectures :
larchitecture de traitement (computing architecture ) ;
larchitecture de service (service architecture ) ;
larchitecture de rseau (network architecture ).
Larchitecture de traitement ( 2) fournit les bases pour la ruti-
lisabilit et linteroprabilit du logiciel de tlcommunication en
sappuyant fortement sur ODP (Open Distributed Processing). Une
terminologie de base ainsi que des concepts de modlisation sont
proposs pour les points de vue information, traitement et ingnie-
rie dfinis dans la recommandation ODP [3]. Le concept de mod-
lisation est appliquer pour la conception et le dploiement des
services de tlcommunication et des services de gestion.
Larchitecture de traitement sattache aussi fournir un proto-
type denvironnement de traitement rparti (Distributed Processing
Environment, DPE) pour les services TINA. Elle dcrit les fonction-
nalits de ce TINA-C DPE, ces principaux composants et son inter-
face de programmation.
Nota : le TINA-C DPE peut tre vu comme une abstraction des systmes distribus tels
que CORBA (Common Object Broker Architecture) avec une spcialisation pour le domaine
des tlcommunications. De ce fait, il peut tre dploy par exemple sur une plate-forme
CORBA.
Larchitecture de service ( 3) fournit un ensemble de concepts et
de principes pour raliser, dployer et exploiter des services de

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 7 380 2 Techniques de lIngnieur, trait Tlcoms
__________________________________________________________________ ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA

Oprateur
Utilisateur Fournisseur
de service
Composants de service

Services de Services de
tlcommunication gestion Gestion de service

Composants de ressources Gestion de rseau

Ressources Ressources Gestion de connexions
de transmission de commutation d'lments de rseau

lments lments de rseau

Commutateur Commutateur

Figure 1 Vue densemble

de larchitecture TINA

tlcommunication. Dans un systme TINA, un service consiste en

un ensemble dobjets interagissant entre eux et dploys sur un
environnement de traitement rparti. Larchitecture de service dfi- Entreprise Capture des besoins
nit les objets requis pour raliser un service, leur composition et
leurs interactions.
Analyse/Conception
Trois concepts importants sont retenir dans cette architecture : Information Traitement
de haut niveau
le concept de session qui concerne les activits de services ;
le concept daccs relatif aux associations de lusager et du
terminal avec les services et le rseau ; Ingnierie Conception dtaille
le concept de gestion pour la gestion des services.
Larchitecture de rseau ( 4) dfinit un ensemble de concepts et Technologie Implantation
de principes pour la spcification, la conception, limplantation et
la gestion de rseaux de transport. Entre autres sont dfinis un
modle informationnel gnrique de ressource de rseau (NRIM,
Figure 2 Points de vue ODP
Network Resource Information Model ), des graphes de connexion
fournissant une vue oriente service de la connectivit et la gestion
des connexions. Cette dernire permet ltablissement, le contrle
et la gestion des connexions dans le rseau. tout systme distribu et nest pas spcifique au monde des
Par ailleurs, larchitecture de rseau dfinit les principes gn- tlcommunications [3]. Le but de larchitecture de traitement
riques pour la mise en uvre dapplications de gestion de service, TINA-C est de raffiner et dadapter la norme ODP afin quelle soit
de systme distribu et de ressource au sens rseau. En terme de applicable aux services de tlcommunication en particulier. En
concepts gnriques, on retrouve les aires fonctionnelles de la effet, un service de tlcommunication est une application distri-
gestion : configuration, performances, fautes, scurit et comptabi- bue qui sexcute sur les diffrents nuds dun rseau de tl-
lit. Un autre concept important est celui dobjet de traitement qui communication.
sert modliser des gestionnaires et des agents. Larchitecture ODP comprend cinq points de vue qui fournissent
des lments de base pour spcifier des systmes ODP : entre-
prise, information, traitement, ingnierie et technologie (figure 2).
Larchitecture de traitement TINA-C se concentre en particulier sur
2. Architecture de traitement les points de vue information, traitement et ingnierie.

Larchitecture de traitement dfinit les concepts de modlisation

devant tre appliqus afin de mettre en uvre des services de tl-
communication ou de gestion dans TINA et donc fournit les bases
pour les deux autres architectures. Cette architecture dfinit aussi
lenvironnement de traitement rparti (DPE) qui fournit linfrastruc-
ture systme permettant aux objets dinteragir entre eux de
manire transparente. Ces concepts sappuient sur le traitement
rparti ouvert (ODP). ODP est une norme pour la construction de
2.1 Concepts de modlisation
dinformation
La modlisation dinformation dans TINA dcrit la structure qui
modlise linformation dans le systme. Elle concerne dune part la
spcification des entits et dautre part la spcification des rela-

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms TE 7 380 3
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA ___________________________________________________________________
tions entre ces entits [4]. Sont aussi prises en compte les contrain-
tes et les rgles qui gouvernent le comportement des entits et des
relations, y compris les rgles de cration et de suppression
Deux types de notation sont utiliss par TINA pour spcifier les
entits et leurs relations :
la notation graphique OMT (Objet Modeling Technique) [5]
avec une migration vers la notation graphique UML (Unified Mode-
ling Language) [6] standardise par lOMG (Object Management
Group) ;
les notations textuelles Quasi-GDMO et Quasi-GRM qui sont
des adaptations des notations proposes par la gestion OSI ;
GDMO (Guidelines for the Definition of Managed Objects) [7] per-
met de spcifier semi-formellement les types dobjets et GRM
(General Relationship Model) [8] a t dfini afin de spcifier des
types de relations.
2.2 Concepts de modlisation
de traitement
Les concepts de modlisation de traitement fournissent un cadre
pour les spcifications de traitement [9].
2.2.1 Objet de traitement
Dans le point de vue de traitement, une application distribue
consiste en un ensemble dobjets de traitement. Dans la suite, le
terme objet dsigne un objet de traitement. Un objet encapsule des
donnes et des traitements. Il fournit un ensemble de fonctions
accessibles par dautres objets. Les fonctions dun objet sont orga-
nises en groupes appels services. Un objet offre donc plusieurs
services, accessibles au travers dinterfaces de traitement.
La spcification dune interface comprend des aspects fonction-
nels et non fonctionnels. Les aspects non fonctionnels concernent
les performances, la qualit de service et les contraintes de distri-
bution. Ces aspects sont spcifis en utilisant des attributs de ser-
vice associs aux interfaces.
Deux types dinterfaces sont considrs : interface opration
( 2.2.2) et interface flot ( 2.2.3).
2.2.2 Interface opration
Une interface opration est une interface dont toutes les inter-
actions sont des oprations. La figure 3a illustre les notations gra-
phiques utilises par TINA-C pour reprsenter la relation client/
serveur entre objets. Un rectangle dsigne un objet de traitement
(OT), un petit carr noir reprsente une interface. Un trait reliant un
objet une interface indique que lobjet est un client de linterface.
Un objet peut tre serveur dune interface et client dune autre
interface.
Comme dans ODP, il existe deux types doprations : linterroga-
tion et lannonce. Une interface opration inclut plusieurs opra-
tions, de type interrogation ou annonce.
Exemple : une interface opration fournit des oprations dtablis-
sement, de contrle et de libration de connexions entre deux points
de terminaison dans un rseau.
Une interface opration fournit des oprations de cration, de libra-
tion de session, dajout dun utilisateur une session et de retrait dun
utilisateur dune session.
2.2.3 Interface flot
Un flot est un concept abstrait qui reprsente une communica-
tion pour un change de flux dinformation dans lequel le contenu
du flux est ignor. Ce flux est visible uniquement du point de vue
de son contrle. Par exemple, il est possible dadresser les opra-
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 7 380 4 Techniques de lIngnieur, trait Tlcoms
OT1 OT2 OT1 OT3
OT4 OT3 OT2
a relation client/serveur b interface flot
Interface
OT Objet de traitement
Source
Interface flot Puits
Figure 3 Reprsentations graphiques de TINA-C
tions play, stop un serveur vido afin de contrler lexcution
dun film. TINA offre les services de contrle et de configuration
dun canal pour le transport de flux dinformation. Par ailleurs, il
est possible de ngocier une certaine qualit de service qui sera
associe au canal. Un flot est toujours unidirectionnel et est orga-
nis en une squence de bits qui peut se prsenter sous la forme
dune trame au niveau applicatif.
La figure 3a illustre les notations graphiques utilises par
TINA-C pour reprsenter la relation producteur/consommateur
entre objets. Un rectangle reprsente un objet de traitement (OT),
un petit carr indique une interface flot, un petit cercle de couleur
blanche (resp. noire) dcrit une source (resp. un puits) dune
interface flot. Il est possible de lier plusieurs sources un puits et
plusieurs puits une source.
2.2.4 Spcification des objets de traitement
et de leurs interfaces
Pour la spcification semi-formelle des objets de traitement et de
leurs interfaces, TINA-C a dfini le langage ODL (Object Definition
Language) [10] qui est une extension du langage OMG-IDL. TINA-
ODL est un surensemble dOMG-IDL afin que les services de tl-
communication ou de gestion spcifis avec ODL puissent tre
construits au-dessus de plates-formes rparties ORB (Object
Request Broker) commerciales conformes aux spcifications de
lOMG.
ODL est un langage de description dfini par TINA-C pour les
spcifications de traitement dinterface et dobjet. Il offre gale-
ment des notations graphiques de traitement dun systme. Le lan-
gage ODL a t normalis par lITU-T sous la recommandation
Z.130 [11].
La spcification dobjet de traitement avec ODL est structure
en :
une spcification de comportement ;
une spcification dattribut de service ;
une spcification dinterfaces supportes.
2.3 Concepts de modlisation
dingnierie
Les concepts de modlisation dingnierie TINA-C fournissent un
cadre pour dcrire lorganisation dune infrastructure abstraite per-
mettant lexcution des objets de traitement TINA-C [12]. Les appli-
cations TINA, consistant en un ensemble dobjets de traitement,
sappuient sur cette infrastructure abstraite qui permet leur
dploiement, leur excution et leurs interactions. Linfrastructure
abstraite est appele environnement de traitement rparti TINA
(TINA DPE, TINA Distributed Processing Environment) (figure 4).
__________________________________________________________________ ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA

des ressources de traitement (processus, tches, threads ) ;

Applications TINA
OT
Infrastructure
TINA DPE
Figure 4 Infrastructure abstraite
Lobjet de traitement devient au point de vue ingnierie un objet
de traitement dingnierie (eCO, engineering Computational
Object). Il existe une diffrence dabstraction entre ces deux objets.
Alors quun objet de traitement a la vue uniquement des inter-
actions avec dautres objets de traitement, un eCO peut interagir
avec dautres objets dingnierie diffrents des eCO. Il doit en effet
interagir avec des objets dingnierie qui tablissent sa communi-
cation avec dautres eCO ou qui offrent des transparences la dis-
tribution.
Les concepts de modlisation dingnierie dcrivent linfrastruc-
ture comme un ensemble de nuds DPE interconnects entre eux.
La partie du nud DPE supportant larchitecture DPE est appele
la plate-forme DPE, elle fournit la fonctionnalit du DPE aux
composants applicatifs. Les ressources supportant la plate-forme
DPE sont appeles environnement de communication et de traite-
ment natif (NCCE, Native Computing and Communication Environ-
ment). Les NCCE peuvent tre htrognes. Les nuds DPE sont
interconnects par un rseau de transport (kTN, kernel Transport
Network) (figure 5).
Un nud DPE consiste en un ensemble de ressources quil gre
de faon autonome. Les ressources dun nud sont :
des ressources de mmoire (mmoire vive et mmoire
morte) ;
des ressources de communication (mcanismes de communi-
cation intranud et mcanismes daccs rseau).
Un nud contient un ensemble de capsules. Une capsule est
une configuration dobjets dingnierie constituant une abstraction
dun processus local un nud et de son espace dadressage
associ. Elle correspond lunit de traitement et de stockage. Elle
reprsente la machine virtuelle dexcution des objets. Un proces-
sus Unix est un exemple de capsule.
Une capsule contient un ensemble de grappes. Une grappe
(cluster ) correspond une configuration deCO constitue des
fins de persistance (activation, dsactivation), de placement et de
migration. Un eCO nappartient qu une seule grappe. Un eCO
peut tre rajout ou supprim dune grappe dynamiquement.
Un nud contient donc des capsules, qui contiennent des
grappes, qui contiennent des eCO.
La communication entre eCO appartenant la mme grappe est
mise en uvre par des mcanismes spcifiques du systme (appel
de procdure, IPC : Inter Process Communication, etc.). Lorsque les
eCO lier appartiennent des grappes diffrentes, la communica-
tion est prise en compte par un canal.
2.4 Services du TINA DPE
Le TINA DPE est une infrastructure qui fournit des services aux
objets des applications TINA quelle excute. Ces services sont soit
des fonctions afin de supporter les mcanismes dinteractions
entre objets, soit des fonctions suffisamment gnriques pour tre
appliques un grand nombre de domaines. Les deux types de
services ont en commun le fait doffrir une interface de traitement,
et donc sont accessibles partir dobjets de traitements TINA. Les
fonctions distribues correspondant ces services sont encapsu-
les dans le DPE (figure 6). Actuellement, six services sont dfinis,
mais il nest pas impossible que dans le futur cette liste sallonge
lorsque seront identifis dautres besoins en terme de fonctions
gnriques :

eCO
Applications
eCO eCO

Plate-forme Plate-forme Plate-forme

DPE A DPE A DPE A
Infrastructure NCCE A NCCE A NCCE A
nud DPE A nud DPE A nud DPE A

Kernel Transport Network

Transport Network TE
TE
Figure 5 Modle de linfrastructure
et de son environnement

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms TE 7 380 5
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA ___________________________________________________________________

Applications TINA

OT

Distributed Processing Environment (DPE)

Fonction Fonction Fonction Fonction Fonction

de de de de de
courtage scurit conteneur notification surveillance
de
performance

Fonction Fonction Fonction

Fonction
de cycle
d'installation
de
transaction de vie configuration

Services du DPE

Figure 6 Services et fonctions du TINA DPE

service de courtage : il assure la publicit et la recherche

dinterfaces travers lesquelles des objets peuvent rendre disponi-
bles des services que dautres objets utiliseront ;
service de transaction : il permet une communication de type
transactionnelle entre objets vrifiant les proprits ACID (atomi-
cit, concurrence, intgrit, durabilit) ;
service de conteneur : le service de conteneur de spcifica-
tions permet le stockage des spcifications de types dobjet et
dinterface. Ces types peuvent tre manipuls par la fonction de
courtage par exemple. Le service de conteneur dimplmentation
permet de stocker limplmentation de lobjet sous la forme dun
code excutable et dinformations lies son implmentation (type
de machine, compatibilit de systme dexploitation, mmoire
requise, etc.) ;
service de notification : il permet aux objets dmettre ou de
recevoir des notifications sans se soucier des objets avec lesquels
ils communiquent ;
service de scurit : il fournit un ensemble de fonctions de
scurit requises par les applications TINA (authentification, auto-
risation, contrle daccs, etc.) ;
service de surveillance des performances : il fournit les mesu-
res et les rapports de performance de lactivit des ressources de
rseau. Il permet aussi de spcifier les performances attendues de
certaines ressources et les actions correctrices pour amliorer les
performances.
Trois autres services relatifs la gestion du cycle de vie des
objets sont aussi proposs :
service de cycle de vie objet : il permet la cration, la suppres-
sion, lactivation, la dsactivation et la migration deCO ;
service dinstallation : il est fourni par chaque plate-forme
DPE afin de permettre le dploiement de types eCO dans les
nuds ;
service de configuration : il fournit des informations sur la
configuration des eCO. Parmi ces informations, on peut trouver la
localisation (nud, capsule, grappe) et ltat dactivation (activ,
dsactiv).
3. Architecture de service
Larchitecture se dfinit comme la discipline de conception et de
construction des systmes au sens large, et consiste en un
ensemble de concepts, de principes et de rgles appliquer durant
cette conception des systmes. Par analogie, larchitecture de ser-
vice TINA-C dfinit un ensemble de concepts, de principes et de
rgles ncessaires pour spcifier et mettre en uvre des services
TINA [13].
Un service TINA, comme tout autre service, est un ensemble de
biens et de fonctionnalits quun fournisseur de service offre un
client ou un souscripteur de service. Larchitecture de service
TINA doit accueillir trois catgories de services :
des services de tlcommunication qui sont les services de
transport de bits dinformation entre terminaux connects au
rseau de tlcommunication. Un service de tlcommunication a
la responsabilit de ltablissement des connexions. Le rseau de
tlcommunication est quant lui transparent par rapport aux don-
nes transportes entre des points de terminaison de rseau ;
des services de gestion qui ont pour rle de grer les ressour-
ces TINA, englobant les ressources de rseau, les ressources du
DPE ainsi que les ressources de service. Cette gestion couvre la
gestion de la configuration, de la comptabilit, de la souscription
ainsi que dautres aires fonctionnelles comme la gestion des fau-
tes, des performances et de la scurit ;
des services dinformation qui sont capables de traiter les res-
sources dinformation telles que le son, la vido, le texte, etc. Ce
traitement se fait au niveau des terminaux et consiste en le stoc-
kage et la visualisation de ces informations.
3.1 Objectifs
Les objectifs de larchitecture de service TINA sont de :
supporter une large gamme de services. En effet, larchitec-
ture de service TINA doit supporter, en plus des services de tl-
communication, ceux de gestion et dinformation et tre ouverte
pour permettre lintroduction de nouvelles classes de services ;

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 7 380 6 Techniques de lIngnieur, trait Tlcoms
__________________________________________________________________
Session d'accs Session d'accs
du domaine du domaine
utilisateur fournisseur
Session d'accs
Session de service
utilisateur
Session de communication
Utilisateur
Figure 7 Concept de session dans TINA
permettre le dveloppement et le dploiement rapides des
services en minimisant les cots et les dlais. Pour ce faire, il est
indispensable dutiliser une approche commune pour la concep-
tion et la gestion de tout type de service ;
assurer que les services dvelopps puissent tre personnali-
ss aisment afin de satisfaire aux exigences spcifiques dune
varit de clients (grands clients, clients rsidentiels). Par ailleurs,
il est ncessaire doffrir aux abonns ainsi quaux usagers finaux
un certain niveau de contrle direct pour la gestion de leurs
services ;
dfinir les services indpendamment dune technologie de
rseau donne et donc permettre une exploitation facile de nou-
velles technologies de rseau ;
offrir une gestion intgre des services et de linfrastructure
de service ;
fournir un accs universel aux services. Ainsi, les usagers
finaux seront capables daccder aux services indpendamment de
leur localisation physique et des types de terminaux utiliss.
Pour atteindre ces objectifs, TINA tire parti des nouvelles tech-
nologies de linformation, comme le traitement rparti orient
objet , et introduit de nouveaux concepts, comme le modle de
session, qui est au cur de larchitecture de service TINA.
3.2 Session
Un des buts de TINA-C tant de permettre le dploiement de ser-
vices multimdia, la notion de session a alors t introduite, gn-
ralisant le concept dappel. Un appel est ddi la ngociation et
lallocation de ressources de communication, et ne supporte pas
les fonctionnalits spcifiques au service, la diffrence de la ses-
sion de service. Cette dernire peut utiliser diffrents modles
dappel et diffrentes procdures dappel pendant sa dure de vie
en fonction des besoins des applications.
Une session est une relation temporaire entre un ensemble de
ressources (par exemple des utilisateurs) ayant une tche accom-
plir durant une priode bien dfinie.
Trois types de sessions sont dfinis par larchitecture de service
TINA : les sessions relatives la session daccs (session daccs,
session daccs utilisateur et session daccs fournisseur), les ses-
sions relatives la session de service (session de service, session
de service utilisateur et session de service fournisseur) et la ses-
sion de communication.
Cette segmentation reflte en ralit la volont de TINA de spa-
rer les aspects relatifs aux services (session daccs et session de
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA
Session d'accs Session d'accs
du domaine du domaine
fournisseur utilisateur
Session d'accs
Session de service Session de service
fournisseur utilisateur
Session de service
Fournisseur Utilisateur
service) et les aspects relatifs aux capacits de communication
(session de communication). De plus, TINA insiste sur la spara-
tion entre les objets gnriques indpendants des services (objets
des sessions daccs et de communication) et les objets spci-
fiques aux services (objets de la session de service).
La figure 7 montre clairement les diffrentes sessions dfinies
dans larchitecture TINA. Elle reprsente le cas de deux utilisateurs
interagissant dans le cadre dune mme session de service qui est
suppose dans ce cas offerte par un seul oprateur de service.
3.2.1 Session daccs
La session daccs gre la connexion de lutilisateur un sys-
tme TINA et son implication dans les services offerts par ce sys-
tme. Un utilisateur peut se connecter un systme pour lancer
des sessions de service ou se joindre des sessions de service et
peut tre associ simultanment de nombreux services. La ses-
sion daccs gre ltat de cette implication.
Un utilisateur doit tre engag dans une session daccs avant
de pouvoir participer une session de service. La session daccs
permet lutilisateur soit de demander la cration dune nouvelle
session de service, soit de demander participer une session
existante. La session daccs comporte aussi un mcanisme infor-
mant un utilisateur quil est invit participer une session de ser-
vice existante.
Par ailleurs, la session daccs garantit lutilisateur un accs
scuris et personnalis aux diffrents services supports par le
fournisseur et auxquels il a souscrit. En effet, pralablement
toute session daccs, lutilisateur et le fournisseur doivent
sauthentifier mutuellement.
Un profil utilisateur, refltant les aspects commerciaux et tech-
niques du contrat de lutilisateur avec le fournisseur, est utilis par
ce dernier pour assurer lutilisateur un accs personnalis ses
services.
Session daccs du domaine utilisateur
Cette session est gre par lutilisateur et reprsente lensemble
des capacits et la configuration dont lutilisateur fait usage pour
contacter le fournisseur.
Session daccs du domaine fournisseur
Cette session est gre par le fournisseur. Elle dbute ds que
lutilisateur devient une entit reconnue, avec un ensemble de don-
nes et de capacits dans le domaine fournisseur et se termine
quand lutilisateur na plus aucune relation avec le fournisseur, qui
TE 7 380 7
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA ___________________________________________________________________
cesse par consquent de dtenir les informations permanentes
concernant cet utilisateur.
3.2.2 Session de service
La session de service est une activation dun service valeur
ajoute particulier. Elle reprsente lintelligence ncessaire au fonc-
tionnement du service. Elle prsente les informations ncessaires
au contrle et la gestion du service, les informations globales
(nombre dutilisateurs, profils utilisateurs, etc.) ou caractrisant
une utilisation du service (rle de chaque utilisateur impliqu,
capacit de communication alloue, etc.).
Une session de service est supporte en totalit par un seul four-
nisseur et se dcompose en session de service utilisateur et ses-
sion de service fournisseur.
Une session de service peut tre instancie soit par une session
daccs, soit par une session de service fournisseur.
Session de service fournisseur
La session de service fournisseur reprsente le comportement
commun tous les utilisateurs concerns par le service, et identifie
toutes les informations et la logique ncessaires au fournisseur
pour offrir lensemble des utilisateurs un environnement qui per-
mette lexcution du service et le maintien de la session.
Une session de service fournisseur peut par ailleurs invoquer,
terminer ou contrler plusieurs sessions de communication.
Session de service utilisateur
Lorsquun utilisateur se joint une session de service, une ses-
sion de service utilisateur est cre et lui est associe dans la ses-
sion de service. Elle est supprime ds que lutilisateur
correspondant quitte la session de service. Cette session permet la
personnalisation du service afin de ladapter la configuration de
lutilisateur et de garantir le respect des contraintes et les prf-
rences de ce dernier.
3.2.3 Session de communication
Cette session reprsente, indpendamment de la technologie de
rseau dploye, une abstraction des diffrentes connexions
ncessaires pour fournir le service support et assure la connectivit
de bout en bout requise. Cette session gre galement les mca-
nismes de ngociation de bout en bout de la qualit de service.
Chaque session de communication est contrle par une seule ses-
sion de service et plus prcisment la session de service fournis-
seur de cette session.
4. Architecture de ressource
Larchitecture de ressource de rseau TINA (NRA, Network
Resource Architecture) est larchitecture qui dfinit les concepts et
les principes pour la spcification et la conception des fonctions
qui contrlent et grent un rseau TINA [14].
Les objectifs qui ont conduit la dfinition de larchitecture de
ressource de rseau sont :
larchitecture doit prsenter un service de connexion de bout
en bout qui transporte linformation entre des applications TINA, et
ce indpendamment dune technologie de rseau particulire. Ce
concept doit sappuyer sur le concept dinterface de type flot dfini
dans le modle de traitement TINA ;
les applications TINA requirent des sessions de commu-
nication multimdia et multipoint. Le service de connexion doit
supporter ltablissement et le contrle de ces sessions de commu-
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 7 380 8 Techniques de lIngnieur, trait Tlcoms
nication. Ces applications spcifient la bande passante et les para-
mtres de qualit de service (QoS) souhaits sans rfrence une
technologie de rseau. Larchitecture de ressource de rseau TINA
a la responsabilit de traduire ces exigences en QoS en des para-
mtres spcifiques une technologie et dtablir les connexions
associes.
Larchitecture de ressource de rseau TINA tire profit des
concepts tablis par la normalisation du rseau de gestion des tl-
communications (TMN, Telecommunication Management Network)
qui dfinit les bases pour la spcification et la conception de sys-
tmes de gestion interoprables. Les principes cls du TMN qui ont
t rutiliss sont la gestion des ressources de rseau par manipu-
lation des reprsentations abstraites des ressources, appeles
objets grs, et la dcomposition des fonctions de gestion en plu-
sieurs couches de gestion (gestion de service, gestion de rseau,
gestion dlment de rseau). TINA se diffrencie du TMN par luti-
lisation dune architecture de traitement rparti sappuyant sur un
DPE qui fournit la transparence par rapport la distribution aux
applications.
4.1 Modlisation des ressources gres :
modle gnrique de ressource
de rseau TINA (NRIM)
La premire tape dans la conception dapplications de gestion
de rseau est la dfinition dun modle dinformation abstrait des
ressources grer. Le modle propos par TINA est appel NRIM
(Network Resource Information Model) [15]. Il est indpendant de
la technologie et de la topologie dun rseau particulier. Il est vu
comme un modle commun constitu de classes dobjets grs
pouvant servir toute application de gestion. Il sera en particulier
utilis pour la mise en uvre des aires fonctionnelles de gestion
TINA suivantes :
gestion de configuration de topologie de rseau ;
gestion des connexions ;
gestion des fautes ;
gestion de la comptabilit.
NRIM sappuie principalement sur les concepts dfinis par la
recommandation G.805 de lITU-T [16] qui dcrit une architecture
fonctionnelle gnrale des rseaux de transport. Elle fournit un
grand nombre de termes gnriques et de concepts qui peuvent
tre appliqus afin de dcrire la topologie et la connectivit de tout
rseau de tlcommunication, indpendamment de sa technologie.
Les deux principaux concepts introduits par G.805 sont lorganisa-
tion en couches (layering ) (figure 8a ) o un rseau de transport
est dcompos en un ensemble de rseaux en couches et la
subdivision (partitioning ) (figure 8b ) qui permet de dcrire la
topologie dun rseau en couches travers les concepts de grou-
pes daccs, de sous-rseaux et de liens, et de reprsenter la
connectivit dans un rseau en couches travers des connexions
de sous-rseaux et de liens.
4.1.1 Rseau en couche
Dans la recommandation G.805 [16], le concept de rseau en
couches est utilis afin de reprsenter un rseau bas sur une
seule technologie et qui transfert des informations avec un format
donn. Des exemples de rseaux en couches sont le rseau SDH
VC4 (Synchronous Digital Hierarchy Virtual Container), le rseau
ATM VC (Asynchronous Transfer Mode Virtual Channel), le rseau
ATM VP (Virtual Path), le rseau Frame Relay, le rseau WDM
(Wavelength Division Multiplexing ), etc. Un rseau de transport est
une superposition de rseaux en couches.
__________________________________________________________________
Connexion
de lien
Couche
cliente
Couche
serveuse
a organisation en couches b subdivision
Sous-rseau Trail Connexion de lien
Figure 8 Concepts dorganisation en couches et de subdivision
4.1.2 Connectivit dans la couche
Un rseau en couches supporte une multiplicit de connexions
de rseau. Une connexion de rseau se dfinit comme la fonction
de transport capable de transfrer linformation de manire trans-
parente travers un rseau de transport entre un point dentre et
un point de sortie. Cette dfinition dcrit une connexion de rseau
unidirectionnelle avec linformation de lutilisateur circulant dans
une seule direction. Une connexion de rseau bidirectionnelle est
constitue de deux connexions unidirectionnelles, une par direc-
tion. Une connexion point--multipoint permet de transporter de
linformation de manire transparente entre une entre et plusieurs
sorties dun rseau en couche. Les connexions de rseau sont ta-
blies et libres par le processus de gestion de connexion de la
couche.
La ressource qui supervise le transfert dinformations sur la
connexion de rseau est dnomme trail. Ce terme a t introduit
afin dexprimer les caractristiques gnriques dune classe den-
tits de transport qui comprend des voies de transmission (trans-
mission paths ) et des sections de transmissions (transmission
sections ), cest--dire des classes dentits ayant la capacit de
superviser lintgrit, la validit et la qualit du transfert dinforma-
tions travers une connexion de rseau. Le trail encapsule une
connexion de rseau une fonction de terminaison source lentre
de la connexion de rseau et une fonction de terminaison collec-
teur la sortie de la connexion de rseau. Ces fonctions traitent
linformation entrant et sortant du rseau en couches afin dattein-
dre les objectifs dadministration.
Bien que ces concepts de supervision du transfert dinformation
soient des lments importants des trails ATM ou SDH, ils nappa-
raissent pas dans des rseaux en couche PDH (Plesiochronous
Digital Hierarchy) ou dans le rseau tlphonique commut qui
sont des technologies apparues bien avant la publication de la
recommandation G.805. Le concept de trail a maintenant t gn-
ralis afin que lintgrit du transfert puisse tre mise en uvre par
les mcanismes de supervision intracouche.
4.1.3 Subdivision par rapport la topologie
Alors que la connectivit dun rseau en couches dcrit les
connexions tablies et sexprime en terme dassociations entre
points particuliers, la topologie dun rseau en couches dcrit les
connexions qui pourraient exister et sexprime sous forme de rela-
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA
Connexion de lien
Fonction Fonction
d'adaptation d'adaptation
Point Trail Point
d'accs d'accs
Fonction de Fonction de
terminaison terminaison
de trail de trail
Connexion de rseau
Points de terminaison de connexion
Figure 9 Relation entre couches adjacentes
tions entre ensembles de points. Un sous-rseau est donc un
ensemble de points dans un mme rseau en couches pouvant
tre interconnects par le processus de contrle de connexion de
la couche, alors quun lien est une relation fixe entre un ensemble
de points dans un sous-rseau et un ensemble de points corres-
pondants dans un autre sous-rseau topologiquement adjacent au
premier.
Un rseau en couches peut donc tre dcompos en un
ensemble de sous-rseaux interconnects entre eux par des liens
jusquau niveau le plus bas de rcursivit, cest--dire au niveau o
le sous-rseau devient un commutateur, un brasseur, etc., au
niveau dun rseau en couches particulier.
4.1.4 Subdivision par rapport la connectivit
Puisquun rseau en couches est constitu de sous-rseaux et de
liens, une connexion de rseau est considre comme une conca-
tnation de connexions de sous-rseaux et de connexions de liens.
4.1.5 Relations entre couches adjacentes
et adaptation
Les connexions de liens dans un rseau en couches fournissent
la connectivit entre sous-rseaux topologiquement adjacents. Ces
connexions sont servies par des trails dans la couche infrieure.
Cette couche est appele la couche serveuse, et la couche
laquelle apparaissent les connexions de liens est appele la couche
cliente. Les deux couches sont dites participer une relation client-
serveur. Lensemble des connexions de liens entre deux sous-
rseaux dfinit le lien entre les deux sous-rseaux. Les liens sont
des entits fixes ou statiques et ne peuvent tre modifis que par
demande la couche serveuse (figure 9).
Linformation de la couche cliente doit tre adapte pour sa
transmission dans la couche serveuse. Cette adaptation comprend
un ou plusieurs des mcanismes suivants, en fonction des cas :
changement de dbit, multiplexage, alignement, codage. Avec
ATM et SDH, ladaptation requiert diffrents mcanismes afin de
transporter la grande varit des signaux-voix, donnes, vido, etc.
4.1.6 Structure du modle NRIM
Le modle NRIM propos par TINA-C est dcrit par un ensemble
de fragments et drive du modle dinformation gnrique de
rseau (GNIM, Generic Network Information Model ) dfini par
lITU-T dans sa recommandation M.3100 [17]. Il est plus complet
TE 7 380 9
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA ___________________________________________________________________
que le modle GNIM dans le sens o ce dernier noffre quune vue
des lments de rseau alors que NRIM fournit une vision rseau
et service. Ce sont les concepts G.805 vus prcdemment ( 4.1.1)
qui permettent la modlisation de la vision rseau. Le modle
NRIM est reprsent par un ensemble de fragments dont chacun
traite dun aspect particulier. Les fragments ne sont introduits que
pour des besoins de documentation, de facilit de comprhension
et de lisibilit, mais ne classifient aucunement les classes dobjets
dcrivant le modle dinformation de ressource de rseau NRIM.
Le fragment rseau montre la structure globale dun rseau en
couches ainsi que sa subdivision. Le fragment connectivit montre
la connectivit lintrieur du rseau en couches. Les points de ter-
minaison relatifs la connectivit lintrieur dun rseau en cou-
ches sont modliss au sein du fragment point de terminaison.
TINA-C dfinit aussi des fragments spcifiques des aires fonc-
tionnelles de gestion tels que les fragments gestion de configura-
tion des ressources et gestion des fautes.
Fragment rseau
Dans larchitecture TINA, les ressources de rseau sont regrou-
pes dans un ensemble de rseaux en couches. Chaque couche est
gre individuellement des autres couches. Il existe donc une fonc-
tionnalit de gestion par couche. Chaque rseau en couches a ses
propres lments de commutation (par exemple, des commuta-
teurs ATM pour la couche VC, des brasseurs ATM pour la couche
VP, des ADM pour la couche SDH VC4, etc.) et ses traitements sont
raliss indpendamment de ceux des autres rseaux en couches.
La relation entre rseaux en couches est de type client-serveur ;
le service fourni par chaque couche est le trail.
Le fragment rseau modlise la structure dun rseau en cou-
ches et sa subdivision. Un rseau en couches contient des trails,
des connexions, des liens topologiques et des sous-rseaux. Le
trail supervise linformation change entre points de terminaison
du rseau en couches. Une connexion de lien dcrit la connectivit
entre deux sous-rseaux. Elle est servie par un trail dans le rseau
en couche serveuse. Un ensemble de connexions peut tre group
afin de former un lien topologique. Un sous-rseau peut tre sub-
divis en de plus petits sous-rseaux avec des connexions entre
eux grce au principe de subdivision. Au plus bas niveau de rcur-
sivit, le sous-rseau devient un commutateur au rseau en cou-
ches considr.
Diffrentes parties du rseau en couches peuvent tre sous le
contrle de diffrentes administrations de rseau. La partie contr-
le par loprateur par dfaut est appele LLND (Local Layer
Network Domain) et chaque partie sous le contrle dun autre four-
nisseur de connectivit est appele FLND (Foreign Layer Network
Domain). Loprateur local aura donc la connaissance des autres
oprateurs avec lequel il est interconnect pour le rseau en cou-
ches donn travers les objets FLND.
Fragment connectivit
La connectivit lintrieur dun rseau en couches se modlise
travers les concepts de connexion de sous-rseau (SNC, Sub-
Network Connection) et de connexion de lien (LC, Link
Connection). La connexion de sous-rseau dcrit la connectivit
lintrieur dun sous-rseau. Elle peut tre tablie et libre par la
fonction de gestion des connexions. Le deuxime concept appel
connexion de lien dcrit la connectivit entre deux sous-rseaux. Il
est prconfigur.
Le concept de connexion en cascade (TC, Tandem Connection)
introduit par la recommandation G.805 reprsente une srie arbi-
traire de connexions de sous-rseau et de connexions de lien. Ce
concept est trs utile lorsquun trail traverse plusieurs sous-
rseaux et que ces sous-rseaux sont superviss par diffrentes
administrations. Dans ce cas, un fournisseur de connectivit peut
offrir dautres fournisseurs de connectivit un service de
connexion en cascade qui permet dtablir, superviser et librer
des connexions en cascade. La connexion de sous-rseau qui sup-
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 7 380 10 Techniques de lIngnieur, trait Tlcoms
porte le trail devient alors une concatnation de connexions en
cascade.
Fragment point de terminaison
Les trails, les connexions en cascade, les connexions de lien et
les connexions de sous-rseau sont toujours tablis entre deux ou
plusieurs points de terminaison. Un point de terminaison est un
point daccs un rseau en couches ou un sous-rseau.
Un point de terminaison de connexion de rseau (NWCTP,
Network Connection Termination Point) termine une connexion de
lien, une connexion de sous-rseau et une connexion en cascade.
Un point de terminaison de trail (NWTTP, Network Trail Termina-
tion Point) termine un trail. Il reprsente le point daccs un
rseau en couches.
Le point de terminaison de lien (LTP, Link Termination Point)
modlise une terminaison dun lien topologique.
Fragment configuration de ressource
Diffrentes catgories de ressources sont prsentes dans larchi-
tecture TINA. Lensemble des fragments prcdents dfinit des res-
sources qui caractrisent la catgorie ressource de rseau. Les
autres catgories sont les ressources du DPE et les ressources de
service. Les ressources du DPE reprsentent lensemble des res-
sources gres dans le DPE, tel que les interfaces et les objets de
traitement. Des exemples de ressources de service sont lagent
usager et le gestionnaire de session de service.
Une classe dobjet appele configurable est une superclasse de
toute classe dobjet 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 dobjet configurable (par exemple, lock, unlock, notification
de changement dtat). On remarquera que ces informations pro-
viennent de la fonction de gestion des tats dfinie par la gestion
systme OSI.
Fragment gestion des fautes
Le fragment gestion des fautes dfinit des objets supports pour
la gestion des fautes. Ces objets sont spcifis pour la gestion des
fautes de ressources de rseau mais leur gnricit leur permet
dtre applicables dautres types de ressources tels que les res-
sources du DPE ou celles de service. Laire fonctionnelle de la ges-
tion des fautes TINA-C recouvre les activits de surveillance
dalarme, de localisation de fautes, de correction de fautes et de
tests/diagnostics. Ce fragment dfinit entre autres la classe alarme
dont la spcification est emprunte la fonction de gestion de rap-
ports dalarmes.
4.2 Gestion des connexions TINA
Le but de la gestion des connexions dans TINA est de mettre en
uvre les connexions requises par les services de tlcommuni-
cation [18]. Le terme connexion a un sens diffrent selon le niveau
auquel on se place. Au niveau le plus haut de larchitecture, il
reprsente une liaison entre interfaces flots dobjets 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
dun commutateur appel cross-connection. Larchitecture de ges-
tion des connexions doit tre vue comme une application distri-
bue qui sexcute sur le DPE.
Les clients potentiels de la gestion de connexions sont principa-
lement les services de tlcommunication. Un client prsente au
gestionnaire de session de communication (CSM, Communication
Session Manager) ses besoins en termes de connectivit. Le CSM
se charge ensuite de ltablissement des connexions rseau
demandes.
__________________________________________________________________ ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA

4.2.1 Fragment de graphe de connexions

Lien
Le graphe de connexions (CG, Connection Graph) est un modle Port Port
qui permet aux services de tlcommunication dexprimer leurs Vertex Vertex
Port Port
exigences en termes de connectivit requise durant leur excution Lien
et ce, indpendamment des aspects de technologie de rseaux
sous-jacents et de topologie. Le graphe de connexions est linter-
face pour le niveau gestion de service. La connectivit est expri- Figure 10 Graphe de connexion
me sous forme de donnes caractristiques du flux dinformation
entre deux points de terminaison. Une session de communication
est directement associe une instance de la classe graphe de
connexion.
Trois objets sont prsents dans le modle du graphe de Interface de contrle de lien de flot
connexion : le vertex, le lien et le port (figure 10) :
le port reprsente la source ou le puits dun flot dinformation
(stream ). Il modlise le point daccs au lien ; quipement
virtuel
le lien (line ) est utilis afin de reprsenter un flot dinforma- quipement
tions entre des ports dans le graphe de connexions. Il caractrise virtuel
en fait une connectivit point point ou point multipoint, unidi- quipement
virtuel
rectionnelle, entre un port source et un ou plusieurs ports cibles ;
un vertex reprsente un groupe de ports. Il modlise
lensemble des ressources impliques dans le transport (mission,
rception) des flux dinformation. Un vertex peut reprsenter des Figure 11 Exemple de liaison dinterfaces flots
quipements tels que les convertisseurs de signaux ou encore des
quipements dusagers tels que la camra, le moniteur, le micro-
phone.

Lien
Les concepts introduits pour la dfinition du graphe de Port Port
connexions peuvent tre utiliss afin de dcrire la connectivit Vertex Lien Vertex
Port Port
au niveau service (graphe de connexions logique) ou la connec-
tivit au niveau rseau (graphe de connexions physique).
Translat en Compos de Translat en
NWTTP1
Graphe de connexions logique Convertisseur
Dans le graphe de connexions logique, le vertex modlise un Trail 1 d'information Trail 2
NWTTP2
objet de traitement avec des interfaces flots au sens ODP. Lappli-
cation usager est un exemple de vertex logique. Un lien reprsente Rseau 1 en couches Rseau 2 en couches
un flot de donnes entre une source et un puits. Enfin, le port
modlise des sources et des puits dans les interfaces flots dun Figure 12 Graphe de connexion physique
objet de traitement (figure 11).

Graphe de connexions physique

Dans le cas du graphe de connexions physique, le port est une
interface physique dans le rseau. Il sagit donc dun point de ter-
minaison de chemin de rseau (Network Trail Termination Point,
NWTTP). Le lien modlise quant lui la connectivit. Il sera servi
par un ou plusieurs trails offerts par un ou plusieurs rseaux en
couches au niveau rseau. Finalement, le vertex dcrit des termi-
naux physiques ou des nuds dans le rseau possdant des
points de terminaison quil est possible dadresser. Il peut sagir
dun terminal usager avec une adresse E.164 ou encore dun nud
de service qui excute des services de tlcommunication ou de
gestion. la figure 12 a t rajout llment convertisseur dinfor-
mation dont le but est de convertir linformation caractristique
dune couche en linformation caractristique dune autre couche si
les technologies des rseaux en couches interconnects sont diff-
rentes.
Graphe de connexions nodal
Le concept de graphe de connexions nodal a t introduit pour
spcifier les besoins de connectivit dans un nud (terminal). Les
besoins de connectivit spcifis dans un nud sont similaires
ceux du graphe de connexion logique. La seule diffrence rside
dans le fait que dans un nud, il est ncessaire de diffrencier les
liens rsolus localement et ceux associs des nuds distants. Le
graphe de connexion nodal attribue les spcialisations suivantes
au vertex et au port :
le port local est quivalent au port logique. Ltablissement
dun lien entre deux vertex locaux est identique ltablissement
de lien entre deux vertex logiques ;
le port image est dfini dans le but de fournir une association
dun port logique un point de terminaison de rseau.
4.3 Spcification des interfaces
Du point de vue du traitement, les fonctions de gestion des
connexions sont offertes travers un ensemble dobjets de traite-
ment de diffrents types. Ces objets interagissent entre eux via
lenvironnement de traitement rparti (DPE). Les objets identifis
dans lapplication de gestion des connexions sont (figure 13) :
le gestionnaire de session de communication (CSM, Commu-
nication Session Manager) ;
le coordinateur de connexions (CC, Connection Coordinator) ;
le coordinateur de rseau en couche (LNC, Layer Network
Coordinator) ;
les gestionnaires de connexions (CP, Connection Performer) :
le gestionnaire de connexions de rseau (NML CP, Network
Management Layer Connection Performer),
le gestionnaire de connexions dlment de rseau (EML CP,
Element Management Layer Connection Performer).

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms TE 7 380 11
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA ___________________________________________________________________

rsoudre les conflits lors de la liaison des interfaces. Par

exemple, une liaison entre une interface flot dun tlphone et une
SSM interface flot dun vidophone est rduite deux flots audio. Le flot
SML Graphe de
connexion logique
vido est ignor ;
CSM maintenir le contexte de la communication dune session de
Graphe de service ;
connexion physique Domaine de supporter lclatement et la fusion de LCG. Dans le cas dun
CC l'utilisateur service de confrence, une session de service peut se diviser en
NML Trail
plusieurs sessions. Ces sessions peuvent se runir par la suite
LNC LNC CPE dans une mme session ;
Fdration
SNC fournir les politiques daccs associes chaque liaison de
NML NML CP CPE CP flot, puisque plusieurs objets dune mme session de service peu-
SNC vent invoquer des oprations sur le mme LCG.
EML EML EML EML Le CSM reoit un LCG et demande au CC un PCG (qui dfinit la
connectivit requise). Le CC est alors invoqu chaque fois que les
NEL NE NE NE NE interfaces flots des objets lier nappartiennent pas un mme
nud.
CSM : Communication Session Manager
Coordinateur de connexions (CC)
CC : Connection Coordinator
LNC : Layer Network Coordinator Lobjet CSM doit prendre en compte le fait que la connexion
CP : Connection Performer entre interfaces dobjets de traitement doit tre mise en uvre
dans un rseau de tlcommunication. Cette connectivit peut se
NE : Network Element
matrialiser par exemple en une connexion ATM de bout en bout.
CPE : Customer Premises Equipment
Cette dernire connecte les points de terminaison des terminaux
NEL : Network Element Layer sur lesquels sont excuts les objets de traitement dont les inter-
EML : Element Management Layer faces flots sont lier. Linterconnexion de points de terminaison
SML : Service Management Layer dans un rseau de tlcommunication est ralise par lobjet CC.
NML : Network Management Layer Le client de lobjet CC, savoir lobjet CSM ou tout client souhai-
SNC : Subnetwork Connection tant une connexion de niveau transport, spcifie les adresses des
SSM : Service Session Manager points de terminaison interconnecter, ainsi que les caractris-
tiques de la connexion (par exemple, qualit de service). Cette sp-
cification de connexion est indpendante de la technologie et de la
Figure 13 Exemple darchitecture de gestion des connexions structure du rseau sous-jacent. Les besoins de connectivit sont
exprims ce niveau travers le graphe de connexions physique.
Ce dernier permet la spcification de connexions point point et
Gestionnaire de sessions de communication (CSM) point multipoint unidirectionnelles.
Au point de vue du traitement au sens ODP, un service de tl- Coordinateur de rseau en couches (LNC)
communication consiste en un ensemble dobjets de traitement
sexcutant sur un DPE. Ces objets interagissent entre eux travers Pour offrir son service, lobjet CC doit slectionner lobjet LNC
des interfaces de type opration ou flot. Les interfaces oprations afin que celui-ci tablisse un trail dans un rseau en couches (par
sont lies dynamiquement et implicitement par les services du exemple, rseau en couches ATM VP, rseau en couches ATM VC,
DPE. Au contraire, les interfaces flots sont lies uniquement de rseau en couches SDH VC4, rseau en couches Frame Relay, etc.).
faon explicite. Lobjet CSM, dfini au niveau le plus haut de Un rseau en couches est dcompos en domaines, chacun sous
larchitecture de gestion de connexions, offre les services nces- la responsabilit dun oprateur de rseau par exemple. Chaque
saires pour lier des interfaces flots. Le client de lobjet CSM, gn- domaine dispose de son propre objet LNC. Lobjet CC ne demande
ralement un service de tlcommunication, indique les rfrences la mise en uvre dun trail qu un seul objet LNC ; ce dernier
des interfaces interconnecter, ainsi que les caractristiques de la prend en charge la fdration entre domaines si ncessaire. Ces
connexion logique (par exemple, qualit de service). Cette spcifi- fdrations conduiront ltablissement dune connexion en cas-
cation de connexion est indpendante de la technologie et de la cade dans chaque domaine.
topologie du rseau support, ainsi que de la distribution. Elle est
logique car elle rfrence des interfaces dobjets de traitement et Pour le client dun objet LNC, ce dernier est le seul point daccs
non des points de terminaison pouvant tre adresss dans le dans tout un rseau en couches. Il est noter que des objets LNC
rseau de tlcommunication. Les besoins en connectivit sont appartenant des rseaux en couches diffrents ninteragissent
exprims travers le graphe de connexion logique. Ce dernier per- pas entre eux.
met la spcification de connexions point point et point multi- Un objet CPE LNC est prsent dans le domaine de lutilisateur. Il
point. met en uvre la fdration entre domaine public (rseau dopra-
Pour fournir aux composants de service une abstraction des res- teur) et domaine priv (rseau priv local).
sources de communication, le CSM doit remplir les tches
suivantes : Gestionnaire de connexions de rseau (NML CP)
raliser la correspondance adquate entre le graphe de Pour mettre en uvre un trail dans un rseau en couches, lobjet
connexions logique (LCG, Logic Connection Graph ) et le graphe de LNC utilise les services offerts par lobjet NML-CP. Ce dernier
connexions physique (PCG, Physic Connection Graph ) ; contrle un sous-rseau dans un rseau en couches . Il fournit
abstraire la QoS. Le LCG offre une description oriente ser- linterconnexion de points de terminaison dans ce sous-rseau. Il
vice de paramtres de la QoS (audio, vido, audio et vido inter- permet donc ltablissement, le contrle et la libration de
actifs, transfert de donnes fiable, etc.). Le CSM est configur connexions de sous-rseaux point point unidirectionnelles et
lavance pour pouvoir traduire ces descriptions en termes de para- bidirectionnelles ou point multipoint unidirectionnelles. Lobjet
mtres de rseau (bande passante requise, taux de perte maximal, NML CP utilise les services des objets EML CP de son domaine
etc.) ; pour raliser la connexion physique de sous-rseaux.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
TE 7 380 12 Techniques de lIngnieur, trait Tlcoms
__________________________________________________________________
SNW SNW41
SNW1
SNW4
SNW444 SNW44
SNW42 SNW441
SNW443
SNW2 SNW3
SNW43
A
Gestionnaire de connexions dlment de rseau (EML CP)
Un objet EML CP dispose dun accs aux agents des quipe-
ments du rseau de tlcommunication. Il offre donc les services
dtablissement, de contrle et de libration de connexions dans
lquipement dont il a la responsabilit.
La figure 13 prsente une instanciation possible de larchitecture
de gestion des connexions. On remarque que larchitecture logique
rpartie en couches dfinie par le TMN sadapte bien sa repr-
sentation. Les services de tlcommunication apparaissent la
couche gestion de service (SML, Service Management Layer). Les
objets CSM, CC, LNC et NML CP sont prsents la couche gestion
de rseau (NML, Network Management Layer). Les objets EML CP
sont dfinis la couche gestion dlment de rseau (EML, Ele-
ment Management Layer). Enfin, les lments physiques du rseau
de tlcommunication sont reprsents la couche lment de
rseau (NEL, Network Element Layer).
Routage
Le routage est le processus qui dcide de la slection du che-
min afin dinterconnecter plusieurs points de terminaison (deux
ou plus) dans un mme rseau. Le routage est effectu deux
niveaux dans la gestion des connexions. Le premier niveau est
celui auquel le LNC dtermine les domaines impliquer alors
que le second niveau concerne le routage effectu par les CP
dans un mme domaine.
Le CC peut lui aussi tre conduit raliser le routage lorsquune
connexion ne peut pas tre fournie par un seul rseau en couches.
Dans ce cas, le CC doit identifier deux ou plusieurs rseaux en cou-
ches, demander ltablissement dun trail chacun de ces rseaux
et interconnecter ces trails.
Le routage dans un mme rseau en couche correspond au pro-
cessus charg de trouver une route possible entre deux ou plu-
sieurs points de terminaison. Cette route est trouve par des
algorithmes de routage existants ou dfinir dans le futur. Larchi-
tecture de gestion des connexions ne fournit aucune spcification
concernant ces algorithmes.
Exemple : routage dans un mme domaine
Un mme domaine est associ un seul sous-rseau appel SNW-
top. Ce dernier est subdivis en quatre sous-rseaux : SNW1, SNW2,
SNW3 et SNW4. SNW4 est subdivis son tour en quatre sous-
rseaux comme lindique la figure 14. Le gestionnaire de connexions
le plus haut dans la hirarchie est nomm CP-top. Chacun des autres
sous-rseaux est contrl par un CP (CP1, CP2, CP3, etc.).
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Tlcoms
ARCHITECTURE DE RSEAU DINFORMATION DES TLCOMMUNICATIONS TINA
SNW442 B
Figure 14 Exemple de rseau
Ltablissement dune connexion entre le point de terminaison A et
le point de terminaison B suivra les tapes suivantes.
1. Le LNC associ ce domaine demande au CP-top dtablir une
connexion rseau entre les points A et B.
2. Le CP-top dcide que la connexion passe par SNW3 et SNW4.
Il demande alors CP3 dtablir une connexion de sous-rseau entre
le point A et le lien allant vers SNW4. Le CP-top demande galement
CP4 dtablir une connexion de sous-rseau entre le lien venant de
SNW3 et le point B.
3. CP3 peut tablir directement la connexion demande puisque
SNW3 nest pas subdivis en sous-rseaux.
4. Pour tablir la connexion dans SNW4, CP4 choisit le chemin
SNW42 et SNW44. Le CP4 demande alors CP42 et CP44 dtablir
les connexions de sous-rseaux exiges.
5. CP42 peut tablir directement la connexion.
6. CP44 choisit le chemin SNW441 et SNW442.
7. Enfin, CP441 et CP442 tablissent les connexions de sous-
rseaux ncessaires.
Il peut exister plusieurs chemins selon lalgorithme de routage
utilis. Les dcisions prises par les algorithmes de routage sont
guides par les informations suivantes :
la configuration statique du sous-rseau ;
la charge des liens topologiques entre les sous-rseaux ;
ltat des lments du rseau (pannes, dgradation des per-
formances, dsactivation dun lment par la gestion des fins de
test, etc.) ;
les contraintes de routage (cot, qualit de service, slection
du rseau de transit, etc.).
5. Conclusion
travers un projet qui a impliqu une trs forte coopration
internationale, le consortium TINA a dfini une architecture logi-
cielle pour la mise en uvre des services dinformation, des ser-
vices multimdia et des services de gestion. En utilisant les
progrs les plus rcents en traitement rparti et dans le domaine
de lobjet, et en les intgrant aux systmes de tlcommunication,
TINA facilite la rutilisation des spcifications, la rpartition flexible
du logiciel et lhomognit dans la mise en uvre des services.
Le passage long terme du rseau intelligent TINA dpendra
du succs des tudes de migration et des performances des
dmonstrateurs TINA. De nombreux projets europens ainsi que
des tudes lEurescom dfinissent et mettent en uvre ces
phases de migration. Quoi quil advienne, linitiative TINA aura jet
les bases techniques de la gnralisation et du dploiement des
services dinformation dans les rseaux et influera fortement
les normes rseau intelligent [19] et TMN futures ou leur
volution [20].
TE 7 380 13