Brevet FR2847099A1 — publié le 20040514

La présente invention concerne une architecture pour la sécurisation du trafic de signalisation dans un réseau de télécommunication et pour l'optimisation des ressources de traitement de la signalisation. L'invention se situe dans le domaine des réseaux de télécommunication, qu'ils transportent de la voix et/ou de la vidéo et/ou des données. Elle trouve typiquement son application dans les nouvelles architectures de réseau, dites architectures NGN (de l'anglais "Next Generation Network") permettant d'offrir tout type de service, téléphonique et/ou multimédia, et elle présente une sécurisation améliorée, et de moindre coût, du trafic de signalisation. Elle permet en outre une optimisation des ressources de traitement de cette signalisation. La sécurisation de la signalisation dans un réseau est essentielle. Elle concerne d'une part la sécurisation contre la défaillance d'un équipement par la prise en charge par d'autres équipements des tâches qu'il effectuait, et d'autre part la sécurisation, dans le réseau de transport, des messages de signalisation. Pour la sécurisation du transport des messages de signalisation, le réseau doit pouvoir faire face à des coupures de transmission dues indifféremment à une rupture de lien ou à une défaillance d'un équipement de routage. La solution actuelle pour faire face à une telle rupture consiste à prévoir plusieurs chemins possibles ou à recalculer en temps réel une nouvelle route pour transmettre ce type de trafic. En ce qui concerne la sécurisation contre la défaillance d'un équipement, la solution consiste à au moins dupliquer cet équipement dans l'architecture. Dans toutes les architectures de réseau connues à ce jour, la sécurisation contre la défaillance d'un serveur par exemple, consiste à mettre à disposition plusieurs serveurs identiques, puis à partager la charge entre ces serveurs. Ainsi, si un serveur tombe en panne, le trafic de signalisation peut être pris en charge par un ou plusieurs autre(s) serveur(s) identique(s). La répartition de charge se fait de manière mécanique dans les points source de trafic, par exemple dans les commutateurs d'abonnés d'un réseau téléphonique. Ce partage reste basé sur une individualisation des équipements. En effet, pour répartir le trafic de signalisation entre les serveurs, le point source doit connaître individuellement chaque serveur, c'est à dire qu'il doit connaître chaque adresse de chaque serveur sur lequel il est susceptible d'envoyer des messages de signalisation. Pour mieux comprendre les inconvénients de l'art antérieur, l'invention va maintenant être présentée en regard d'un exemple particulier et bien connu de l'art antérieur : - la figure 1 représente en effet un schéma d'une architecture classique du réseau téléphonique commuté. Bien sûr ce n'est qu'un exemple illustratif pour aider à la compréhension, mais il ne faut pas oublier que tous les inconvénients qui vont être décrits maintenant apparaissent également dans les réseaux de télécommunication multimédias. Pour un service comme le trafic téléphonique, à l'échelle d'un pays comme la France, le nombre de commutateurs de transit CTi dans le réseau s'élève à plusieurs dizaines. Chaque point source de trafic, c'est à dire chaque commutateur d'abonnés CAA1, CAA2, ne peut voir qu'un nombre restreint de commutateurs de transit, respectivement CT1 à CTn et CT11 à CTk. L'affectation de chaque commutateur d'abonnés CAA1, CAA2 à un nombre restreint de commutateurs de transit est déterminée en fonction de critères géographiques et/ou de critères de trafic en quantité ou en type par exemple. L'ingénierie de conception de tels types de réseau en est grandement complexifiée. De plus, chaque client Al, A2 est rattaché de façon unique à un seul commutateur d'abonnés respectivement CAA1, CAA2. Outre les problèmes évidents de sécurisation que cela implique, chaque commutateur d'abonnés comporte donc une table listant tous les clients qu'il dessert. La table de clients ainsi que la puissance de traitement des commutateurs CAA1, CAA2 limitent donc leur couverture géographique à une zone respectivement Z'1, Z'2, encore dénommée plaque géographique dans la suite. De la même manière, les commutateurs de transit ont une couverture géographique, Zl et Z2, limitée par leur capacité à dialoguer avec un nombre restreint de commutateurs d'abonnés CAA. Par conséquent, en cas de pic de demande d'établissement d'appel, surtout lors d'événements exceptionnels tels qu'un accident, une catastrophe, une manifestation sportive etc..., la surcharge de traitement des demandes devra être supportée par le commutateur d'abonnés CAAi de la zone Z'i concernée ou, selon les cas, par le nombre limité de commutateurs de transit desservant une même plaque géographique. Ce phénomène peut alors conduire à une surcharge géo-localisée voire même à un blocage du réseau à l'intérieur d'une plaque géographique. Par ailleurs, pour pouvoir établir une session de communication entre un abonné appelant Al et un abonné appelé A2 dépendant de commutateurs de transit respectivement CT1 à CTn et CT11 à CTk n'appartenant pas à la même plaque géographique, respectivement Zl et Z2, un dialogue doit s'établir entre les deux commutateurs de transit couvrant les différentes plaques géographiques Zl, Z2. Ainsi, dans l'exemple de la figure 1, le trafic de signalisation est adressé par le commutateur d'abonnés CAAl au commutateur de transit CT1 par le chemin chl puis un dialogue s'établit entre ce commutateur CT1 de la plaque géographique Zl et un commutateur de transit CT12 de la plaque géographique Z2 dont dépend l'abonné appelé A2. Ce dialogue entre les commutateurs CT1 et CT12 est représenté par la double flèche chll sur la figure 1 et est plus communément appelé "bi-transit".L'établissement d'une telle session en bi-transit sollicite alors deux fois la puissance de traitement des équipements, ce qui présente un impact non négligeable sur le coût et la rapidité d'établissement de la session. Pour que la panne d'un commutateur de transit puisse être absorbée par les autres commutateurs de transit, il faut sur-dimensionner ces commutateurs de transit. Ainsi, lorsque k commutateurs de transit se partagent la charge de trafic T d'une même plaque géographique Z2, il faut que k-1 commutateurs de transit puissent écouler T/k trafic supplémentaire. Cela signifie qu'en fonctionnement nominal, la charge de trafic de chaque commutateur de transit ne doit pas dépasser (k-l)/k % de sa capacité de traitement. Or, dans la situation actuelle, minimiser le sur-dimensionnement des commutateurs de transit implique d'accroître leur nombre k. Cela va à l'encontre des objectifs prépondérants de simplification de configuration et de gestion imposant une réduction du nombre k de commutateurs de transit. Les inconvénients des réseaux actuels ont été décrits en regard d'un réseau téléphonique classique, mais bien sûr, il ne faut pas oublier qu'ils existent également dans d'autres types de réseaux, tels que les réseaux multimédias. C'est le cas par exemple des réseaux de télécommunication multimédia configurés dans un environnement SIP (de l'anglais "Session Initiation Protocol"), pour faire de la téléphonie sur Internet ou du routage de sessions multimédia. Dans de tels réseaux, les commutateurs de transit sont plus généralement dénommés serveurs d'appel de transit ou encore "proxy", et les points source de trafic sont bien souvent confondus avec les terminaux des abonnés appelant. Enfin, les architectures actuelles des réseaux impliquent également une sécurisation interne des équipements. Pour cela, elle est réalisée par duplication des cartes dans chaque équipement. Or, une sûreté accrue du réseau permettrait de réduire les exigences au niveau de chaque équipement. Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer une architecture pour la sécurisation du trafic de signalisation dans un réseau de télécommunication, ladite architecture étant composée d'au moins un point source de trafic et d'une pluralité de serveurs d'appel, qui permettrait d'une part d'augmenter la zone de couverture des serveurs, indépendamment de leur puissance individuelle de traitement, pour éviter des saturations localisées du trafic, supprimer les phénomènes de bi-transit et supprimer la dépendance univoque de chaque client à un serveur unique de rattachement, et d'autre part de simplifier l'ingénierie du réseau et de réduire les coûts de sécurisation. La solution au problème technique posé est obtenue, selon la présente invention, du fait que ladite architecture est caractérisée en ce que : - les serveurs d'appel sont rassemblés dans au moins un pool organisé en anneau, - au moins un moyen d'acquisition de données associé audit réseau de télécommunication est en liaison avec lesdits serveurs d'appel dudit pool, - des moyens multiplexeurs à insertion / extraction permettent de véhiculer sur l'anneau dudit pool des messages échangés entre le point source de trafic et au moins un serveur dudit pool, au moins un desdits moyens multiplexeurs à insertion extraction étant apte à aiguiller le trafic de signalisation en fonction de paramètres quantifiables et/ou en fonction de règles mécaniques. Dans un mode préféré de réalisation les paramètres quantifiables correspondent notamment au taux d'occupation du (des) serveur(s) qui est (sont) rattaché(s)au(x) moyen(s) multiplexeur à insertion/extraction capable(s) d'aiguiller le trafic de signalisation. Comme règles mécaniques, on peut citer la nature de la requête contenue dans la signalisation, des règles de probabilités de prise en charge ou des règles systématiques de prise en charge. Ainsi, l'architecture selon l'invention permet d'élargir la zone de couverture des serveurs, indépendamment de leur puissance individuelle de traitement, puisqu'elle permet de répartir le trafic de signalisation sur l'ensemble des serveurs d'un pool dont la zone de couverture ne dépend pas nécessairement de paramètres géographiques. Les serveurs ne couvrent alors plus nécessairement une plaque géographique si bien que les problèmes de sursaturation très localisée du trafic sont évités et le phénomène de bi-transit est repoussé jusqu'aux frontières du réseau d'un opérateur. Cette architecture permet également d'optimiser la sécurisation du plan de commande du réseau, c'est-à-dire du pilotage des ressources et des services. De plus, l'organisation en anneau du pool de serveurs permet de sécuriser la transmission du trafic de signalisation contre des coupures éventuelles de transmission le long de l'anneau. L'invention permet également un traitement en local, c'est-à-dire au niveau de chaque serveur, de la prise en compte de la charge de chaque serveur et donc une prise de décision en local concernant l'aiguillage du trafic de signalisation. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante faite à titre d'exemple illustratif et non limitatif en regard des figures annexées qui représentent : -la figure 2, un schéma de principe d'une architecture selon l'invention, pour la sécurisation du trafic de signalisation dans un réseau de télécommunication quelconque, et pour l'optimisation des ressources de traitement de la signalisation -la figure 3, une application de l'architecture de la figure 2 au réseau téléphonique, -la figure 4, une application de l'architecture de la figure 2 à un réseau multimédia, La figure 2 schématise le principe d'une architecture permettant la sécurisation des messages de signalisation et l'optimisation des ressources de traitement de la signalisation, au moment de l'établissement d'une session de communication,dans un réseau R de transmission de flux d'informations de type voix et/ou vidéo et/ou données. Pour ce faire, elle est composée d'au moins un point source de trafic référencé ST sur la figure 2, d'une pluralité de serveurs d'appel SI à Sn et d'au moins un point de destination de trafic référencé DT. Des moyens d'interconnexion au réseau R, tels que des passerelles d'accès P1, P2, ...Pi par exemple, sont reliés de manière connue aux sources de trafic ST et aux destinations de trafic DT. Les serveurs d'appel SI à Sn, destinés à traiter les messages de signalisation et à envoyer des messages de commande pour établir une session de communication, sont regroupés dans au moins un pool référencé 10 sur la figure 2. Dans ce cas, l'ensemble des serveurs du pool est vu par l'environnement comme un serveur unique, hormis par le système de gestion du réseau qui connaît les adresses de chaque serveur. Cela signifie que, vis-à-vis de l'extérieur du pool, préférentiellement, il n'existe qu'une seule adresse commune. De manière avantageuse, ce pool 10 est organisé en anneau. Ainsi, il offre une transmission sécurisée des messages de signalisation en bénéficiant de tous les mécanismes bien connus de sécurisation contre les coupures de transmission le long d'un anneau. De plus, la structure en pool de l'architecture est sécurisante contre les défaillances des serveurs d'appels puisque, dans ce cas, la charge du serveur défaillant est répartie sur l'ensemble des autres serveurs du pool. La zone de couverture du pool dépend de l'utilisation que l'on veut en faire. Dans son application la plus simple, le pool est par exemple dédié à un service ou à un groupe de services, il est donc rattaché à tous les clients de ce service ou groupe de services. Par conséquent, tous les serveurs d'appel SI à Sn d'un même pool 10 sont identiques et doivent rendre le même service, ou groupe de services, que celui auquel est dédié le pool. La zone de couverture d'un pool ne dépend donc pas nécessairement de paramètres géographiques et ne se limite donc pas à une plaque géographique. Elle s'étend en effet à l'ensemble des clients du (des) service(s) au(x)quel(s) le pool est dédié, si bien qu'elle peut aller jusqu'à couvrir la totalité des clients d'un opérateur, notamment lorsque le service rendu est le service téléphonique par exemple. Un réseau de télécommunication peut donc comporter plusieurs pools de serveurs. Dans une variante, il est toutefois possible d'envisager une structuration logique des pools. Un pool est dédié à un service ou à un ensemble de services. Or un serveur peut rendre des services propres à des pools différents. Ce serveur appartiendra donc à deux pools différents. Dans cette situation, le serveur n'appartient donc pas de façon unique à un pool. Dans ce cas, l'organisation des pools dans le réseau est dite logique, par opposition à une architecture ou chaque serveur serait affecté physiquement un pool unique. L'anneau formant le pool 10 fonctionne selon un principe proche d'un système de jeton bien connu de l'homme du métier. Pour cela, des moyens multiplexeurs à insertion/ extraction, notés MIE dans la suite de la description, et référencés sur la figure 2 d'une part Ml, M2 et d'autre part El, E2, E3, sont disposés sur l'anneau et permettent de véhiculer les messages de signalisation échangés entre un serveur Si et un point source de trafic ST. Certains de ces MIE, référencés El à E3, sont rattachés à un ou plusieurs serveurs d'appel avec lesquels ils communiquent. Ces MIE Ei sont dits "intelligents" car ils possèdent une fonction particulière supplémentaire par rapport aux MIE classiques Mi. Cette fonction consiste notamment à analyser les paramètres quantifiables, c'est à dire notamment le taux d'occupation des serveurs qu'ils desservent, et/ou à prendre en compte les règles mécaniques à appliquer, puis à aiguiller le trafic de signalisation en fonction du résultat de cette analyse. L'aiguillage du trafic de signalisation consiste à choisir de prendre en charge ou non le traitement du message circulant sur l'anneau, donc l'envoyer vers le serveur choisi ou réinjecter le message dans l'anneau. Cet aiguillage du trafic s'exécute selon le mode "appel par appel" qui consiste à analyser chaque demande d'établissement de session de communication. Cette demande est envoyée successivement à chaque moyen multiplexeur à insertion/extraction intelligent Ei de l'anneau qui analyse la capacité du (des) serveur(s) qu'il dessert à prendre en charge la session. Lorsqu'un MIE Ei rejette le message car, par exemple, le(s) serveur(s) qu'il dessert est(sont) trop occupé(s), le message circule sur l'anneau jusqu'au MIE Ei+1 suivant, et ainsi de suite jusqu'à ce qu'un MIE intelligent intercepte le message pour l'adresser à un serveur qu'il dessert et dont, par exemple, le taux d'occupation est suffisamment faible pour qu'il puisse traiter ce message. Bien sûr, le taux d'occupation des serveurs peut ne pas être le seul critère de décision pour aiguiller le trafic et les MIE intelligents peuvent tenir compte d'autres critères dans leur analyse, comme par exemple les règles mécaniques. Ces règles correspondent notamment à la nature de la requête contenue dans la signalisation, telle que le type de service par exemple, à des règles de probabilité de prise en charge, et/ou à des règles systématiques, c'est-à-dire la prise en charge de un message sur N par exemple. Un moyen 20 d'acquisition d'informations associé au réseau R est en relation avec les serveurs SI à Sn du pool. Ce moyen d'acquisition d'informations est par exemple constitué d'au moins une base de données qui regroupe des données concernant tous les utilisateurs du pool et tous les équipements du réseau R. Une seule base de données est représentée sur la figure 2, cependant elle peut être indifféremment centralisée ou distribuée par exemple et, pour des raisons de sécurisation des données, elle est de préférence dupliquée. La notion de service utilisée dans cette invention couvre tous les types de services, les services réseaux avec commandes de ressources et les services applicatifs c'est-à-dire les services vus par l'utilisateur final, tels que la Vidéo à la demande, la visioconférence, la consultation, etc... Donc, pour les services réseaux, les messages échangés peuvent comprendre des données de commande de réseau pour piloter les ressources du réseau en vue d'établir une session de communication. D'autre part, lorsque les pools sont dédiés à un service applicatif ou groupe de services applicatifs, les messages peuvent comprendre des données de commande de service. La manière dont les messages de signalisation sont échangés dans cette architecture est représentée par les flèches 1 à 6. Dans cet exemple, une session de communication doit être établie entre une source de trafic ST et une destination de trafic DT. Pour établir cette session de communication, des messages de signalisation doivent préalablement être envoyés et traités. Ainsi, la source ST transmet une requête en établissement d'une session de communication au pool de serveurs d'appel (flèche 1) . Le MIE Ml reçoit cette requête et l'insère, de manière classique, dans l'anneau (flèche 2). Chaque MIE Ei intelligent successif analyse, par exemple, le taux de charge du (des) serveur(s) qu'il dessert et choisit successivement d'aiguiller ou non la requête vers un serveur d'appel en fonction de son taux de charge. Ainsi, dans l'exemple de la figure 2, El laisse passer le message sur l'anneau tandis que E2 le récupère (flèche 3) et l'envoie sur le serveur d'appel S2 qu'il dessert. Le serveur d'appel S2 traite alors la requête et, s'il ne possède pas les informations suffisantes dans sa mémoire, sollicite le moyen d'acquisition d'informations 20 associé au réseau R, par une succession d'échanges de données (flèches 4 et 5). Ainsi, le serveur d'appel S2 cherche à connaître notamment l'adresse des passerelles d'accès P1 et de sortie P2 du réseau R à solliciter, les ressources à solliciter dans ces passerelles P1 et P2, l'adresse de la destination de trafic DT etc... Une fois la requête traitée, S2 répond et envoie un message de commande sur l'anneau (flèche 6) en vue de commander, ou non, l'établissement d'une session de communication. Selon le type de réseau utilisé, la réponse et le message de commande du serveur S2 peuvent être envoyés de différentes manières qui sont décrites cidessous en regard des figures 3 et 4. La nature de l'anneau peut induire l'utilisation de dispositifs particuliers pour le routage des messages de signalisation. La nature des MIE, notamment, est directement issue du type d'anneau mis en u̇vre. Ainsi, ce peut être par exemple des MIE SDH (de l'anglais " Synchronous Digital Hierarchy"), équipements classiques que l'on rencontre actuellement dans les réseaux synchrones des opérateurs de télécommunications. Dans un autre exemple, dans un réseau basé sur la technologie IP(de l'anglais "Internet Protocol"), ces MIE peuvent être des routeurs. Dans un premier mode de réalisation, l'anneau peut être physique, c'est à dire que les liens entre MIE successifs sont directs. Ces liens peuvent être assurés de façon physique, par des fibres optiques par exemple, ou de façon logique par l'intermédiaire de faisceaux directs, dans le cas du RTC (Réseau téléphonique commuté), ou de tunnels directs, dans le cas du MPLS (de l'anglais "Multiprotocole Label Switching") ou du L2TP (de l'anglais "Layer 2 Tunneling Protocol") etc... Dans un deuxième mode de réalisation, l'anneau est dit logique. Dans ce cas, au moins un lien entre deux MIE successifs n'est pas direct. Ce peut être le cas par exemple si le réseau de transport support est IP et que les messages entre deux MIE sont routés de façon dynamique au travers d'un ou plusieurs routeurs. L'exemple schématisé sur la figure 3 s'appuie sur le réseau téléphonique commuté RTC classique dans lequel un abonné Al veut joindre un destinataire D2. Dans ce cas, le point source de trafic correspond au commutateur d'abonnés référencé CAA1 et le point de destination de trafic correspond au commutateur d'abonnés référencé CAA2. Les serveurs d'appel à mettre en pool correspondent aux commutateurs de transit CT1 à CTn et sont organisés en anneau. Dans un premier temps, le commutateur d' abonnés CAA1 reçoit de l'abonné appelant Al une requête en établissement de session et la transfère au MIE Ml de l'anneau (flèche 1). Simultanément, il établit un lien, de manière classique, vers la passerelle P1 d'accès au réseau R. Le MIE Ml insère la requête dans l'anneau (flèche 2). La requête circule alors sur l'anneau jusqu'à ce qu'un MIE intelligent Ei la prenne en charge (flèche 3) et la transmette à un serveur qu'il dessert. Cette prise en charge par le MIE Ei est, par exemple,fonction de la charge des serveurs qu'il dessert, c'est à dire de la puissance de calcul de ces serveurs à l'instant où la requête circule sur l'anneau. Dans l'exemple de la figure 3, les MIE El et E2 laissent passer la requête tandis que le MIE E3 la transmet au CT1. Le commutateur de transit CT1, rattaché au MIE E3, traite alors la requête et, s'il ne possède pas d'informations suffisantes dans sa mémoire, il sollicite le moyen 20 d'acquisition d'information associé au réseau par une succession d'échanges de messages schématisé par les flèches 4 et 5. Ces échanges de messages lui permettent de connaître les différentes informations dont il a besoin pour piloter les ressources afin d'établir la session de communication.Les informations qui lui sont nécessaires sont notamment: l'adresse du commutateur d'abonné de destination CAA2, l'adresse d'une passerelle P2 de sortie du réseau et ayant des ressources disponibles vers le commutateur CAA2 de destination, les ressources à solliciter dans la passerelle P1 vers le réseau R, les ressources à solliciter dans la passerelle P2 en sortie du réseau R, les ressources à solliciter entre la passerelle P2 et le commutateur d'abonnés CAA2. Le commutateur de transit CT1 répond ensuite à la requête et renvoie sa réponse sur l'anneau (flèche 6). Sa réponse consiste à rejeter ou à accepter la requête en établissement d'appel. Lorsque la requête est acceptée, le commutateur CT1 pilote donc les passerelle P1 et P2 par un dialogue schématisé par les doubles flèches 7 et 8 pour positionner leurs ressources, puis il envoie l'ordre au commutateur d'abonné CAA2 de destination (flèche 9) d'achever l'établissement de la session d'appel de manière traditionnelle en direction du destinataire D2. L'exemple schématisé sur la figure 4 s'appuie sur un réseau de télécommunication de type multimédia. Plus particulièrement ce réseau fonctionne par exemple selon le protocole SIP (de l'anglais "Session Initiation Protocol") qui est utilisé pour la signalisation des appels téléphoniques ou multimédias sur Internet. Il permet donc d'établir les paramètres d'une session entre deux terminaux, ou au cours d'une communication, de modifier ces paramètres, ou de mettre fin à une communication. Ce protocole a fait l'objet d'une norme d'établissement d'appel multimédia définie à l'IETF (Internet Engineering Task Force). Il est de plus en plus utilisé et tend à supplanter la norme H323 qui est très répandue mais plus complexe à utiliser. Dans cet exemple, le point source de trafic est confondu avec le terminal Tl ou T2 de l'abonné appelant Al. Ces terminaux peuvent aussi bien être des ordinateurs, que des téléphones, que des assistants personnels etc... Sur cette figure, les mêmes références sont utilisées pour désigner les mêmes éléments. Les serveurs d'appels SI à S4, encore dénommés "proxy" en terminologie SIP, sont assemblés en pool organisé en anneau référencé 10. Dans ce type de réseau, les requêtes en enregistrement comme en établissement de session de communication sont traitées sensiblement de la même manière que pour le réseau téléphonique illustré sur la figure 3, à ceci près que la requête émane directement du terminal Tl, ou T2, de l'utilisateur appelant Al. Pour l'enregistrement par exemple, phase n'existant pas en téléphonie classique, l'utilisateur Al envoie un message, via la passerelle d'interconnexion P1, pour informer le réseau qu'il s'est connecté et qu'il est désormais joignable. La requête d'enregistrement est donc envoyée, via la passerelle P1, au MIE Ml (flèches 1 et 1'). Les étapes suivantes, jusqu'au choix du serveur SI destiné à traiter la requête, sont identiques aux exemples précédents. Dans les échanges (flèches 4 et 5) qu'il a avec le moyen 20 d'acquisition d'informations, le serveur SI y inscrit la relation qui existe entre les adresses URI de l'utilisateur Al ( de l'anglais "Uniform Ressource Indicator" ), de type adresse e-mail, et l'adresse numérique IP (de l'anglais "Internet Protocol") du terminal utilisé, Tl par exemple, et toutes les informations que le terminal Tl appelant a transmis avec sa requête. Le serveur d'appel SI répond alors (flèches 6, 7, 8' et 8) pour informer du succès ou de l'échec de la transaction. Pour l'établissement d'une session de communication, le mécanisme est le même. Le contenu des messages change. Le terminal Tl par exemple, envoie une requête d'établissement contenant en particulier l'adresse URI du destinataire A2. Cette requête suit le processus décrit précédemment (flèches 1, 1', 2 et 3). Grâce aux échanges (flèches 4 et 5) avec le moyen 20 d'acquisition d'informations, le serveur SI obtient la traduction de l'adresse URI de l'utilisateur destinataire A2 en une adresse IP utilisable par le réseau. Dans le cas où la requête d'établissement est acceptée, la réponse est envoyée par exemple en mode redirect.Ce mode, bien connu dans l'environnement SIP, consiste à transmettre, à l'utilisateur appelant Al, cette traduction de l'adresse URI de l'utilisateur appelé A2 en adresse numérique IP du terminal sur lequel A2 est joignable (flèches 7, 8' et 8). L'utilisateur Al peut alors contacter directement son destinataire A2 à travers le réseau. Dans ce cas, le serveur SI n'intervient plus pendant la session de communication Cette invention est généralisable à de nombreuses autres applications. Par exemple, il est possible d'envisager l'architecture selon l'invention dans un réseau mobile dans lequel les MSC (de l'anglais "Mobile Switching Center") seraient organisés en pool afin de s'affranchir totalement de la dépendance de chaque serveur à une zone géographique délimitée.Le fonctionnement est représenté par la figure 4 dans laquelle les serveurs Si sont des commutateurs MSC, qui sont équivalents à des commutateurs d'abonnés CAA dans la téléphonie fixe. Un autre exemple d'application serait l'application de l'invention à la téléphonie fixe classique mais au niveau des commutateurs d'abonnés CAA et non plus de commutateurs de transit CT comme présenté en détail précédemment figure 3. Le réseau de transit de la téléphonie mobile pourrait très bien accueillir cette invention selon le mode décrit pour la téléphonie classique en figure 3. Le fonctionnement présenté ici de ce type d'architecture, c'est-à-dire l'organisation en pool de serveurs, repose sur les hypothèses fortes suivantes : toutes les transactions relatives à une même session de communication transitent ou sont traitées par les mêmes équipements, c'est-à-dire le même MIE Mi, le même serveur d'appel Si et le même MIE intelligent Ei. Lorsque le premier MIE Ml reçoit un message (flèche 1 ou 1', voir figure 3 ou 4) à insérer dans l'anneau, il doit l'expédier vers le deuxième MIE M2. Il peut le faire selon deux méthodes. Selon la première méthode, il expédie le message à une adresse unique, ou une adresse par défaut, correspondant à l'adresse de l'anneau. Dans ce cas, l'anneau ne peut être que physique, afin d'éviter les problèmes de conflit de routage. Selon la deuxième méthode, le MIE Ml expédie le message à une adresse individualisée du MIE M2. Dans ce cas, l'anneau peut-être indifféremment physique ou logique. Cette solution reste néanmoins plus complexe à gérer. En effet, les MIE sont actifs car, il y a modification des adresses individuelles de bond en bond. D'autre part, en cas de panne d'un équipement, par exemple le MIE Mi, le MIE Mi-1 doit modifier l'adresse d'expédition des messages de l'anneau en MIE Mi+1. Cela implique que chaque MIE doit connaître une partie de la topologie de l'anneau, ce qui complexifie non seulement le fonctionnement pour la sécurisation mais aussi les tâches de configuration des MIE surtout lorsque l'on souhaite faire évoluer l'architecture de l'anneau. Tous ces points augmentent la complexité de gestion. Le relais du MIE M2 vers le premier MIE intelligent El se fait ensuite selon le même principe, et ce, jusqu'au MIE Ei qui récupère la requête et la transfert à un serveur d'appel de transit. De même, lors de la réponse du serveur d'appel ayant traité la requête, le transport du message de son MIE intelligent Ei de rattachement vers le premier MIE Ml suit les mêmes règles. Quelle que soit la méthode de routage sur l'anneau retenue, les messages véhiculés doivent contenir une information spécifique que seul le MIE Ml , et le MIE M2 dans le cas de la figure 3 , pourra identifier lors de la réponse du serveur d'appel. De cette façon, on s'assure que tous les messages relatifs à une même session entrent et sortent de l'anneau vers le commutateur d'abonnés CAA1 ou la passerelle P1 par le même point. De même, les messages ultérieurs au message initial et issus de la source doivent contenir une information permettant aux MIE Ei d'identifier les messages relatifs à une session déjà prise en charge par un serveur d'appels qu'ils desservent. De cette façon, on s'assure que tous les messages relatifs à une même session entrent et sortent de l'anneau vers un serveur d'appel par le même point Ei et donc qu'une session est prise en charge par un unique serveur. Dans ce type de réseau, c'est-à-dire la mise en place d'un pool, l'utilisation de la structure en anneau reste donc assez lourde pour les réponses en retour des serveurs. Une variante consiste à établir des relations directes entre le serveur Si et la source de trafic dès réception de la requête initiale par le serveur. Un tel fonctionnement de cette variante est illustrée figure 4 (flèche 6'). La relation directe entre le serveur SI et le terminal Tl initiateur de la requête est établie dès réception de la requête initiale par le serveur SI (flèche 3) . Toute la suite du dialogue se fait alors en direct entre le serveur SI et la source de trafic Tl, chacun d'eux conservant et utilisant l'adresse propre, privée ou non, de l'autre tout au long de la session. Comme il a été décrit plus haut tous les serveurs du pool apparaissent vis-à-vis de l'environnement, comme un serveur unique en partageant tous, par exemple, une adresse unique commune correspondant à celle du pool. Ils peuvent cependant être individualisés au sein du pool par une adresse, privée ou non, qui peut être accessible ou non de l'extérieur du pool. Ainsi, dans le cas où le dialogue entre le serveur SI et la source de trafic Tl se fait en direct, les messages en provenance du serveur SI contiennent des données sur son adresse propre permettant à la source de trafic de la mémoriser. La source de trafic doit donc mémoriser de façon temporaire la correspondance entre la session et le serveur qui la traite. La source peut alors répondre ou solliciter directement ce serveur pour toute requête ultérieure relative à cette même session. Lorsque la session prend fin, la source de trafic doit effacer de ses tables l'adresse du serveur correspondant. Dans le cas d'un dialogue via l'anneau, il est préférable que l'adresse propre au serveur soit privée et ne soit pas accessible de l'extérieur du pool, hormis du système de gestion du réseau. Les architectures physiques qui viennent d'être décrites ne sont qu'une illustration et ne sont en aucun cas limitées à ces exemples. Elles trouvent typiquement leur application notamment dans les nouvelles architectures de réseau permettant d'offrir tout type de service, téléphonique et/ou multimédia. Un avantage de ces architectures réside dans le fait que l'organisation en pool de serveurs permet de répartir la charge de trafic sur l'ensemble des serveurs du pool, d'éviter ainsi les problèmes de surcharge "géo-localisée", et de repousser les phénomènes de bi-transit jusqu'aux frontières des réseaux d'opérateurs. Ainsi, l'invention permet de gérer la puissance de calcul des serveurs situés à l'extérieur de l'anneau, mais liés à celui-ci via des MIE intelligents. L'organisation du pool de serveurs en anneau présente plusieurs avantages. Elle permet notamment un traitement local, par rapport à chaque serveur, de la prise en compte de paramètres quantifiables propres à chacun de ces serveurs, tels que la charge ou taux d'occupation. Il n'y a que les MIE Ei qui connaissent la charge des serveurs auxquels ils sont rattachés. Donc la prise de décision sur l'aiguillage du trafic de signalisation se fait en local, à l'intérieur du pool, au niveau de chaque serveur. En ce qui concerne la sécurisation des MIE Mi, la méthode classique de duplication permet de réduire les risques liés à la défaillance de l'un d'entre-eux et d'éviter que les sources de trafic ST, les destinations de trafic DT et les moyens d'interconnexion au réseau R se retrouvent isolés. La sécurisation des MIE Ei peut aussi s'effectuer selon la même méthode mais, contrairement au MIE Mi, elle n'est pas indispensable. En effet, l'isolement d'un serveur Si, suite à la défaillance du MIE Ei qui le dessert ou du lien entre le MIE Ei et le serveur Si, n'isole aucun client. La structuration en pool permet automatiquement la répartition de sa charge sur les autres serveurs comme lors de la défaillance du serveur Si lui même. REVENDICATIONS 1. Architecture pour la sécurisation du trafic de signalisation dans un réseau (R) de télécommunication, ladite architecture étant composée d'au moins un point source de trafic (ST; CAA1; Tl, T2) et d'une pluralité de serveurs d'appel (Sl-Sn; CTl-CTn), caractérisé en ce que : -lesdits serveurs d'appel (Sl-Sn; CTl-CTn) sont rassemblés dans au moins un pool (10) organisé en anneau, -au moins un moyen (20) d'acquisition de données associé audit réseau (R) de télécommunication est en liaison avec lesdits serveurs (Sl-Sn; CTl-CTn) dudit pool, -des moyens multiplexeurs à insertion/extraction (Ml, M2 ; El, E2, E3) permettent de véhiculer sur l'anneau dudit pool (10) des messages échangés entre ledit point source (ST; CAA1; Tl, T2) et au moins un serveur (Sl-Sn;CTl-CTn) dudit pool, au moins un desdits moyens multiplexeurs à insertion/extraction (El, E2, E3) étant apte à aiguiller le trafic de signalisation en fonction de paramètres quantifiables et/ou en fonction de règles mécaniques. 2. Architecture selon la revendication 1, caractérisée en ce que les paramètres quantifiables correspondent notamment au taux d'occupation du (des) serveur(s) d'appel (Sl-Sn; CTl-CTn) qui sont rattachés au(x)dit(s) moyen(s) multiplexeur à insertion/extraction (El, E2, E3) apte(s) à aiguiller le trafic de signalisation. 3. Architecture selon l'une des revendications 1 ou 2, caractérisée en ce que les règles mécaniques correspondent à la nature de la requête de signalisation et/ou à des règles de probabilités de prise en charge et/ou à des règles systématiques de prise en charge. 4. Architecture selon l'une des revendications 1 à 3, caractérisée en ce que l'anneau est formé par des liens directs entre les moyens multiplexeurs à insertion/extraction (Ml, M2 ; El, E2, E3) successifs. 5. Architecture selon la revendication 4, caractérisée en ce que les liens directs sont assurés par des fibres optiques, ou par l'intermédiaire de faisceaux directs ou de tunnels directs. 6. Architecture selon l'une des revendications 1 à 3, caractérisée en ce que l'anneau est formé par des liens entre les moyens multiplexeurs à insertion / extraction (Ml, M2 ; El, E2, E3) successifs, au moins un desdits liens n'étant pas direct. 7. Architecture selon l'une des revendications 1 à 5, caractérisée en ce que chaque moyen multiplexeur à insertion / extraction (Ml, M2 ; El, E2, E3) successif est configuré pour véhiculer sur l'anneau, à une adresse unique commune correspondant à celle du pool (10), les messages échangés entre le point source (ST; CAA1; Tl, T2) et l'un des serveurs (Sl-Sn; CT1CTn) du pool. 8. Architecture selon l'une des revendications 1 à 6, caractérisée en ce que chaque moyen multiplexeur à insertion / extraction (Ml, M2 ; El, E2, E3) successif est configuré pour véhiculer sur l'anneau, à une adresse qui leur est propre, les messages échangés entre le point source (ST; CAA1; Tl, T2) et l'un des serveurs (Sl-Sn; CTl-CTn) du pool. 9. Architecture selon l'une des revendications 1 à 8, caractérisée en ce que chaque serveur (Sl-Sn; CTl-CTn) est individualisé au sein du pool par une adresse qui lui est propre, privée ou non, accessible ou non de l'extérieur dudit pool (10). 10. Architecture selon l'une des revendications 1 à 9, caractérisée en ce que le moyen (20) d'acquisition de données est constitué d'au moins une base de données renfermant des données sur les usagers et sur les équipements du réseau (R) de télécommunication. 11. Architecture selon l'une des revendications précédentes, caractérisée en ce que les messages échangés comprennent des données de commande de réseau. 12. Architecture selon l'une des revendications précédentes, caractérisée en ce que les messages échangés comprennent des données de commande de services. 13. Architecture selon l'une des revendications 1 à 11, caractérisée en ce qu'une session directe (6') est établie entre l'un des serveurs (SI) du pool et le point source de trafic (Tl), en réponse à un premier message (3). 14. Architecture selon l'une des revendications 1 à 13, caractérisée en ce que le réseau (R) de télécommunication est le réseau téléphonique. 15. Architecture selon l'une des revendications 1 à 13, caractérisée en ce que le réseau (R) de télécommunication est un réseau multimédia. 16. Architecture selon la revendications 15, caractérisée en ce que le réseau (R) de télécommunication est configuré dans un environnement SIP.