FR 2815799 A1 20020426 FR 0013513 A 20001023 Procédé pour informer de la capacité de traitement spécifique d'un noeud d'un réseau de télécommunication La présente invention est relative aux réseaux de télécommunication dont les noeuds sont capables de traiter de façon spécifique, les messages d'information qu'ils reçoivent. L'invention s'applique particulièrement aux réseaux actifs. Ce concept de réseau actif a été introduit par les travaux du DARPA en 1994 et ont fait l'objet d'une première conférence internationale, IWAN 99 (international Workshop on Active Networks). Selon ces travaux, un réseau actif est un réseau dans lequel les noeuds, ou certains d'entre eux, sont capables de traiter d'une façon spécifique, les messages véhiculés par le réseau. Autrement dit, cela signifie que ces noeuds doivent être capables de dérouler un algorithme autre que ceux qu'ils connaissaient lors de leur conception. Au sein d'un réseau actif, tous les noeuds ne sont pas obligatoirement pourvus de cette capacité de traitement : on distingue donc des noeuds actifs de noeuds non actifs (c'est-à-dire normaux). Le traitement qu'un noeud actif peut mettre en oeuvre peut être de différente nature : . Il peut s'agir d'exécuter les données contenues dans le message reçu. Ces données sont alors du code exécutable. Ou bien, il peut s'agir d'aller récupérer un code exécutable quelque part sur le réseau, en fonction des données reçues. Ce traitement peut être relatif à au moins deux différents niveaux de la couche de protocoles de communication mis en oeuvre par le réseau : À un niveau application, il peut s'agir de décoder et modifier la charge utile du message reçu. À un niveau routage, il peut s'agir de prendre des décisions de routage en fonction du résultat de ce traitement. Autrement dit, un message peut contenir des informations, ou même l'algorithme lui-même, servant à le router. Ces décisions peuvent toutefois aussi dépendre de l'environnement. Par exemple, dans la mesure où les noeuds du réseau peuvent être actifs ou non actifs, l'algorithme de routage mis en oeuvre par un noeud actif donné peut prendre en compte ceci pour décider vers où router le message reçu. Notamment, il peut être intéressant de router un message en priorité vers un noeud actif plutôt que vers un noeud normal (c'est-à-dire non actif) qui ne sera pas forcément à même de le traiter correctement. Or, actuellement, rien n'existe dans l'état de la technique pour résoudre ce problème nouveau. Par conséquent, les messages sont routés indépendamment de l'environnement. La présente invention a pour but de résoudre ce problème technique. Pour ce faire l'invention a pour objet un procédé pour informer de la capacité d'un noeud d'un réseau de télécommunication de traiter les messages d'information de façon spécifique, ce noeud émettant de façon périodique des messages de routage vers des noeuds. Le procédé se caractérise en ce qu'il comporte une étape consistant à insérer dans les messages de routage, des informations relatives à cette capacité. L'invention a pour autre objet un noeud de réseau disposant de moyens pour traiter les messages d'information de façon spécifique, et de moyens pour émettre de façon périodique des messages de routage vers des noeuds voisins d'un réseau de télécommunication. Ce noeud de réseau se caractérise en ce qu'il comporte de surcroît des moyens pour insérer dans les messages de routage, des informations relatives à cette capacité. Ainsi, par le biais du protocole de routage, chaque noeud a la connaissance des capacités de chaque autre noeud de son environnement de pouvoir traiter des messages. Autrement dit, chaque noeud est capable de déterminer si un noeud de son environnement est un noeud actif ou un noeud normal. L'invention et ses avantages apparaîtront de façon plus claire dans la description qui va suivre, en liaison avec les figures jointes. La figure 1 illustre un paquet de routage conforme à une mise en oeuvre de l'invention. La figure 2 illustre un paquet de routage conforme à une deuxième mise en oeuvre de l'invention. Cette technologie des réseaux actifs s'applique particulièrement bien aux réseaux de type Internet, c'est à dire basés sur un protocole de communication de type IP interner Protocol). Dans ce contexte, les noeuds sont appelés routeurs, et donc les noeuds actifs sont des routeurs actifs. Dans le cadre d'un réseau Internet, le protocole de routage est, dans la majeure partie des cas, conforme au standard OSPF (Open Shortest Path First) tel que décrit dans le RFC 2328 de l'IETF (Internet Engineering Task Force). Selon ce standard, les routeurs s'informent régulièrement de leurs états par l'échange de messages ODPF. En fonction de la valeur d'un champ type , ces messages OSPF peuvent contenir différents types de messages. Parmi ces types de messages, on peut citer les messages dits hello , et les messages de mise à jour d'état de connexion (Link State Update). Les messages hello ont pour but d'informer les voisins d'un routeur de l'état de celui-ci. Ces messages hello sont transmis à intervalle régulier, de sorte que si un routeur ne reçoit pas de messages hello d'un autre routeur pendant un intervalle sensiblement supérieur, il peut en déduire que ce dernier est hors service, et peut prendre les dispositions ad-hoc (par exemple, modifier ses tables de routage). Les messages Link State Update ont typiquement pour but de mettre à jour les tables de routage que chaque routeur du réseau possède. En effet, chaque routeur ne peut avoir initialement la connaissance de la topologie de l'ensemble du réseau ou du sous-réseau auquel il appartient. Aussi, le rôle des messages Link State Update)) est de leur permettre d'échanger des informations afin que les routeurs puissent acquérir la connaissance de la topologie de ce réseau. Cette connaissance peut alors être utilisée par les routeurs pour construire sa propre table de routage, qu'il peut alors utiliser pour router les messages qu'il reçoit. Les messages LSA Update peuvent contenir une ou plusieurs unité d'information appelée Link State Advertisement (LSA). Un LSA contient de l'information sur une connexion entre le routeur et un de ses voisins. Le RFC (Request For Comments) 2370 de l'IETF a introduit la notion de LSA opaque (Opaque LSA, en langue anglaise), dans un but d'ouverture du protocole OSPF. Ces LSA opaques sont destinés à véhiculer de l'information spécifique à des applications mises en oeuvre par les routeurs. Un message LSA opaque se compose de deux parties : 'Un entête, Un corps de message, contenant des informations spécifiques à l'application concernée par le message. Selon une mise en oeuvre préférentielle de l'invention, on utilise ces messages LSA opaques pour transmettre des informations relatives à la capacité d'un noeud de traiter les messages d'information de façon spécifique. La figure 1 schématise la structure d'un message LSA opaque conformément au RFC 2370. Les champs LS age , Options ), 9, 10 or 11 , Advertising Router)), LS Sequence Number ), LS checksum ) et Lenght correspondent aux spécifications des messages LSA et ne seront donc pas détaillées ici. Les champs Opaque Type et Opaque ID sont spécifiques aux messages LSA opaque. Le premier champ, Opaque Type permet de signaler que le message LSA en question est un message LSA opaque contenant des informations relatives à la capacité du routeur émetteur (identifié par le champ Advertising Router ) de traitement spécifique des messages d'information. La valeur que doit prendre ce champ est indifférente du moment que tout les routeurs appartenant au réseau ou au sous réseau la connaissent. Dans le cadre du réseau Internet mondial, la charge de fixer cette valeur revient actuellement à LIANA (Internet Assigned Number Authority) au sujet de laquelle on peut trouver des informations sur le site internet http : //www. iana. org. Le champ suivant, Opaque D M permet de préciser plus précisément la caractéristique concernant ce traitement spécifique que l'on veut indiquer. En effet, en plus de préciser que le routeur en question est capable d'effectuer un traitement spécifique des messages d'information reçus, il peut être souhaitable de préciser quel types de traitement il peut mettre en oeuvre, dans quelles mesures et suivant quelles contraintes etc. Un exemple d'une telle caractéristique est l'environnement d'exécution. On peut donc par exemple choisir que la valeur 0 (zéro) dans le champ Opaque ID signifie que la caractéristique précisée par le message LSA opaque est l'environnement d'exécution. Les informations relatives à la caractéristique environnement d'exécution peuvent être insérées dans le corps du message, c'est-à-dire à la suite de l'entête définie par le protocole OSPF. Selon une mise en oeuvre de l'invention, ce corps de message C peut être subdivisé en plusieurs champs. Le champ EE ID)) indique un identificateur unique de l'environnement d'exécution. Cet identificateur unique peut être enregistré auprès d'une instance officielle. Une telle instance peut par exemple être l'ANANA (Active Network Assigned Number Authority). Typiquement, cet identificateur détermine de façon univoque l'environnement d'exécution du routeur en question. Cet environnement d'exécution comprend le système d'exploitation qu'il met en oeuvre, mais aussi d'éventuelles spécificités. Par exemple, ce système d'exploitation peut être une machine Java. Auquel cas il est important de préciser la version de la machine virtuelle, son fournisseur etc. dans la mesure où il peut exister des problèmes de compatibilité d'une machine virtuelle à une autre. Il est aussi à noter qu'un même routeur peut mettre en oeuvre plusieurs environnements d'exécution distincts. Le champ suivant, référencé EE Info Length sur la figure 1, représente la longueur du champ suivant. Cette longueur peut par exemple être exprimée en nombre de mots de 32 bits. On peut, par convention, décider que la valeur 0 signifie que le champ suivant à une longueur limitée aux 16 bits permettant de finaliser l'alignement sur 32 bits Le champ suivant, EE Info)) permet l'insertion d'informations supplémentaires concernant l'environnement d'exécution. À titre d'exemples non exhaustifs, on peut insérer dans ce champ une liste de modules logiciels (ou librairies) disponibles sur ce serveur, des informations relatives à des droits d'accès etc. La figure 2 illustre une deuxième mise en oeuvre de l'invention. En effet, l'invention est susceptible de s'appliquer à tout type de protocoles autres que OSPF, et notamment au protocole RIPng. Ce protocole est par exemple spécifié dans le RFC 2080, intitulé Ring for IPv6)). Un message R) Png comporte une ou plusieurs entrées de table de routage RTE (Route Table Entry). La figure 2 représente une de ces entrées. Selon cette mise en oeuvre, le dernier champ, référencé metric est utilisé pour préciser la nature de l'entrée. Il joue un rôle similaire à celui du champ Opaque Type dans la mise en oeuvre avec OSPF. De la même façon, sa valeur est à préciser par un organisme tel l'IANA. Si le champ metric contient cette valeur la sémantique des champs de l'entrée est modifiée pour contenir des informations concernant les capacités actives du routeur. Les champs EE info et EE ID sont similaires à ceux décrits dans la première mise en oeuvre avec OSPF. Le champ EE Info # permet de signifier que l'information relative à l'environnement d'exécution (contenue dans le champ EE Info ) ne peut être incluse dans un seul message Ring. Sa valeur peut donc être le nombre de messages RtPng consécutif contenant des informations relatives au même environnement d'exécution. Enfin, le champ EE Info L.)) permet de préciser la taille de la donnée utile dans le champ EE Info . REVENDICATIONS 1) Procédé pour informer de la capacité d'un noeud d'un réseau de télécommunication de traiter les messages d'information de façon spécifique, ledit noeud émettant de façon périodique des messages de routage vers des noeuds voisins dudit réseau de télécommunication, caractérisé en ce qu'il comporte une étape consistant à insérer dans lesdits messages de routage, des informations relatives à ladite capacité. 2) Procédé selon la revendication précédente, dans lequel les informations relatives à ladite capacité comprennent des informations concernant l'environnement d'exécution dudit routeur. 3) Procédé selon l'une des revendications 1 et 2, dans lequel lesdits messages de routage sont des messages LSA opaques conformes au protocole OSPF. 4) Procédé selon la revendication précédente, dans lequel les informations relatives à ladite capacité sont insérées dans les champs " Opaque Type ", " Opaque ID " et éventuellement dans le corps du message. 5) Procédé selon les revendications 2 et 4, dans lequel le champ Opaque ID indique que des informations concernant l'environnement dudit routeur sont contenues dans ledit corps du message. 6) Procédé selon l'une des revendications 1 et 2, dans lequel lesdits messages de routage sont conformes au protocole Ring. 7) Procédé selon la revendication précédente, dans lequel les informations relatives à ladite capacité sont insérées dans des entrées de tables de routage (RTE). 8) Noeud de réseau disposant de moyens pour traiter les messages d'information de façon spécifique, et de moyens pour émettre de façon périodique des messages de routage vers des noeuds voisins d'un réseau de télécommunication, caractérisé en ce qu'il comporte de surcroît des moyens pour insérer dans lesdits messages de routage, des informations relatives à ladite capacité. 9) Noeud de réseau selon la revendication précédente, dans lequel les informations relatives à ladite capacité comprennent des informations concernant l'environnement d'exécution dudit routeur. 10) Noeud de réseau selon l'une des revendications 8 et 9, dans lequel lesdits messages de routage sont des messages LSA opaques conformes au protocole OSPF. 11) Noeud de réseau selon la revendication précédente, dans lequel les informations relatives à ladite capacité sont insérées dans les champs Opaque Type , Opaque ID et éventuellement dans le corps du message. 12) Noeud de réseau selon les revendications 9 et 11, dans lequel le champ Opaque ID)) indique que des informations concernant l'environnement d'exécution dudit routeur sont contenues dans ledit corps du message. 13) Noeud de réseau selon l'une des revendications 8 et 9, dans lequel lesdits messages de routage sont conformes au protocole Ring. 14) Noeud de réseau selon la revendication précédente, dans lequel les informations relatives à ladite capacité sont insérées dans des entrées de table de routage (RTE).