L'invention concerne une technique d'obtention par un premier nœud d'une information relative à une congestion d'une route entre ce premier nœud et un deuxième nœud. Plus précisément, cette route permet un acheminement de paquets du premier nœud à destination du deuxième nœud.

L'invention se situe dans le domaine des télécommunications et plus particulièrement dans le domaine de la détection d'une congestion dans des réseaux de communication par paquets.

L'invention trouve une application particulièrement avantageuse pour le contrôle d'admission de session dans de tels réseaux de communication par paquets.

Une congestion est susceptible de se produire sur tout équipement situé sur le chemin emprunté par un paquet. Plus précisément, un équipement peut être congestionné au niveau de mémoires d'entrée ou de sortie, de files d'attente internes,...

Des fonctions de notification de congestion ont été définies par les organismes de normalisation pour les réseaux de communication par paquets. Ces fonctions reposent sur divers mécanismes, parmi lesquels on peut citer un mécanisme de notification explicite de congestion ECN, pour « Explicit Congestion Notification », un mécanisme de notification explicite de congestion vers l'avant FECN, pour « Forward Explicit Congestion Notification », un mécanisme de notification explicite de congestion vers l'arrière BECN, pour « Backward Explicit Congestion Notification » ou bien encore des combinaisons de ces différents mécanismes. Le terme « avant » correspond au sens de transmission d'un paquet, c'est-à-dire vers le destinataire du paquet, et le terme « arrière » correspond au sens opposé de transmission du paquet, c'est-à-dire vers l'émetteur du paquet. Ces différents mécanismes utilisent un champ de l'entête des paquets de données pour porter une information relative à la congestion d'un des nœuds acheminant le paquet. Ainsi, cette information relative à la congestion est transmise dans le plan de transfert des données. Par exemple, pour un réseau de communication de type IP, pour « Internet Protocol », le document de l'IETF, pour « Internet Engineering Task Force », RFC 3168 spécifie la manière dont un paquet IP porte une notification explicite de congestion ECN en avant. On appelle par la suite un tel paquet IP un paquet marqué.

Pour le protocole de transport TCP, pour « Transmission Control Protocol », s 'appuyant sur le protocole IP, il est prévu, pour une session TCP établie entre un nœud émetteur et un nœud récepteur, que le nœud récepteur notifie le nœud émetteur d'un segment TCP de l'apparition d'une congestion lors de l'envoi d'un acquittement. Le nœud émetteur peut alors modifier certains paramètres du protocole TCP pour tenter de faire disparaître la situation de congestion. Aucune information relative à la localisation de la congestion n'est disponible dans ce cas. Toujours pour ce protocole de transport TCP, des études ont été menées pour notifier une congestion vers l'arrière. A titre d'exemple, le document de l'IETF draft-salim-jhsbnns-ecn-00 de juin 1998 propose d'utiliser des messages du plan de commande pour notifier l'apparition d'une congestion vers l'arrière. Plus précisément, le message de contrôle « Source Quench » du protocole ICMP, pour « Internet Control Message Protocol », défini par le document RFC 792, est utilisé pour notifier l'émetteur du paquet. Un tel message permet notamment à un nœud acheminant un paquet de notifier implicitement l'émetteur du paquet que celui-ci a été supprimé ou bien marqué par le routeur. Le message comprend notamment une partie du paquet supprimé. Différentes optimisations ont été proposées, par exemple dans l'article « Congestion Control in TCP/IP networks : a combined ECN and BECN approach » de F. Akujobi et al, publié dans les actes de la conférence MILCOM 2003, afin de limiter l'envoi de ces messages ICMP « Source Quench ».

Toutefois, ces solutions présentent l'inconvénient de demander une interaction importante entre les plans de commande et de transfert puisque le plan de commande doit obtenir du plan de transfert le paquet supprimé ou marqué. De ce fait, la notification à l'aide de ces messages nécessite des ressources processeur et mémoire au niveau du nœud qui notifie. Ces solutions présentent également l'inconvénient d'impliquer une charge du lien en arrière, c'est-à- dire du nœud qui émet un message ICMP « Source Quench » vers le nœud émetteur du paquet, cette charge étant liée à la transmission de ces messages. Ces messages sont également susceptibles de ne pas arriver jusqu'au nœud émetteur et ce dernier n'est pas à même de détecter une perte de l'un de ces messages. Le nœud émetteur reçoit également trop d'informations, qu'il ne peut utiliser, du fait de l'envoi d'un message pour chaque paquet supprimé ou marqué. De plus, ces méthodes ne sont applicables que pour une session TCP établie.

Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.

Selon un premier aspect, l'invention a pour objet un procédé d'obtention par un premier nœud d'une information relative à une congestion d'une route permettant un acheminement de paquets dudit premier nœud à destination d'un deuxième nœud dans un réseau de communication par paquets, ladite congestion étant susceptible de dégrader ledit acheminement, ledit procédé d'obtention comprenant les étapes suivantes mises en œuvre par le deuxième nœud :

- une étape de réception d'un premier paquet en provenance du premier nœud et à destination du deuxième nœud, acheminé par l'intermédiaire d'au moins un troisième nœud ;

- une étape de traitement dudit premier paquet dans un plan de commande dans lequel les premier et deuxième nœuds échangent des messages de contrôle, à l'issue de laquelle une émission d'un message de contrôle à destination du premier nœud est demandée ;

- une étape d'obtention de ladite information à partir du premier paquet reçu ; - une étape d'envoi d'un deuxième paquet au premier nœud, ledit deuxième paquet portant ledit message de contrôle et comprenant ladite information obtenue.

Ce premier paquet est prévu pour déclencher l'émission du message de contrôle dans le plan de commande.

De manière connue, le plan de commande permet aux différents nœuds d'échanger des informations de contrôle entre eux. Le plan de transfert est en charge de l'acheminement des paquets entre les nœuds.

Une route permet d'acheminer des paquets d'un premier nœud vers un deuxième nœud, appelé également nœud de destination. Cette route traverse un ou plusieurs nœuds intermédiaires. La congestion est susceptible d'affecter différentes ressources de ces nœuds intermédiaires : il peut s'agir d'une congestion affectant une file d'attente du deuxième nœud, une congestion affectant des ressources matérielles du deuxième nœud, ... La route se trouve alors également congestionnée.

L'information relative à une congestion dans le sens descendant, c'est-à-dire dans le sens de transmission des paquets, est déterminée dans le plan de transfert par un des nœuds intermédiaires congestionnés et est destinée à marquer les paquets dans ce sens de transmission, une fois acheminés par le nœud intermédiaire congestionné. Selon l'invention, l'information relative à une congestion sur la route, reçue dans un premier paquet, est recopiée dans un deuxième paquet, portant un message de contrôle, transmis en réponse au premier paquet. Ce deuxième paquet est transmis à destination du premier nœud, en réponse au premier paquet. Ainsi, cette information relative à une congestion de la route est fournie uniquement sur sollicitation du premier nœud et est transmise en arrière, c'est-à-dire dans le sens opposé au sens de transmission du premier paquet. La charge générée par la mise en œuvre du procédé selon l'invention est réduite aussi bien au niveau des ressources matérielles et processeur du deuxième nœud qu'au niveau des liens empruntés pour arriver à destination du premier routeur.

Il est ici souligné que le premier paquet est un paquet qui est à destination du deuxième nœud et qui nécessite un envoi d'un message de contrôle en réponse à destination du premier nœud.

L'information relative à une congestion de la route correspond par exemple à la valeur prise par le bit CE du champ d'information ECN de l'entête d'un paquet, tel que spécifié dans le document de l'IETF RFC 3168. Une valeur de « 1 » permet d'indiquer une congestion.

Seule une modification minime du fonctionnement au niveau des plans de commande et/ou de transfert est requise, à savoir la recopie de l'information de congestion dans le paquet de réponse. L'interaction entre les plans de commande et de transfert n'est également pas modifiée. Ainsi, en cas de persistance de la congestion, la notification est faite une seule fois alors que dans les solutions de l'état de la technique, un grand nombre de paquets est susceptible d'être transmis du plan de transfert au plan de commande afin de générer des messages de contrôle ICMP « Source Quench ».

Les notifications de congestion ne sont pas émises spontanément, c'est-à-dire en l'absence de sollicitation, et il est ainsi possible au premier nœud de détecter une absence de réponse à l'envoi du premier paquet. Le premier nœud peut alors transmettre de nouveau le premier paquet au deuxième nœud. Les notifications de congestion sont par ailleurs émises hors hors bande, c'est-à-dire qu'elles ne nécessitent pas un établissement d'une session TCP.

Ceci permet de détecter finement les fluctuations de trafic et de localiser des congestions même évanescentes dans le réseau. Il est possible de découper la route entre les premier et deuxième nœuds en une pluralité de segments, dont certains correspondent par exemple au raccordement entre deux sous-réseaux, et de connaître l'état de congestion de chacun des segments. Au contraire, l'information fournie dans les messages d'acquittement TCP est une information globale sur la route empruntée et elle ne permet pas de localiser précisément les éléments du réseau ou segments de la route à l'origine de la congestion.

Le procédé d'obtention offre par ailleurs une alternative à la détection de congestion à l'aide de procédures SNMP, pour « Simple Network Management Protocol ». Ces procédures prennent en compte des variations de trafic sur des périodes de temps plus longues par la mise à jour et l'export par les nœuds de valeurs de compteurs de trafic à des collecteurs centraux selon le protocole SNMP. Le temps de réaction nécessaire selon ces procédures est plus important.

Grâce au procédé d'obtention, il est ainsi possible à un opérateur de réseau de connaître le niveau de congestion de certains éléments du réseau ou segments par interrogation. Ceci permet de protéger ou de modifier des sessions en cours. Cette protection peut passer par la mise en œuvre de procédures de contrôle d'admission pour de nouvelles sessions ou bien encore de modulation de débit. En cas de modulation de débit, on peut utiliser par exemple des techniques de codage dites échelonnables ou « scalable » SVC, pour « Scalable Video Coding ». Une augmentation de débit est alors possible lorsque les conditions de charge du réseau le permettent, par exemple une augmentation du débit disponible ou une absence de congestion.

Selon une caractéristique particulière, les premier et deuxième nœuds mettant en œuvre un acheminement différencié des paquets en fonction de classes de service, le premier paquet reçu comprend une information relative à une classe de service donnée et ladite information obtenue est relative à une congestion affectant au moins ladite classe de service.

Il est alors possible d'obtenir une information relative à une congestion de la route pour l'acheminement des paquets marqués comme appartenant à la classe de service donnée.

L'opérateur de réseau peut alors prendre des mesures visant à protéger les sessions correspondants à certaines classes de service. Dans une variante, il est possible au nœud intermédiaire d'indiquer une congestion pour toutes les classes de service de niveau supérieur à la classe de service donnée. Ceci permet en une seule demande d'obtenir les informations relatives à la congestion d'un ensemble de classes de service.

Selon une autre caractéristique particulière, le message de contrôle envoyé correspond à un message de réponse à un autre message de contrôle reçu dans le premier paquet.

Il est possible de prévoir un nouveau message de contrôle dans un protocole du plan de commande, ce nouveau message requérant l'envoi d'un autre message de contrôle en réponse.

Cet autre message de contrôle est une demande d'écho transmise du premier nœud à destination du deuxième nœud.

Un tel autre message de contrôle est par exemple le message « Echo Request » auquel est associé le message « Echo Reply » pour le protocole ICMP.

Selon encore une autre caractéristique particulière, l'entête du premier paquet indique qu'une durée de vie dudit premier paquet a expiré.

II est encore possible d'obtenir les informations relatives à une congestion sur un chemin à l'aide du programme utilitaire, connu sous le nom de « Traceroute », et qui permet de déterminer la route empruntée par un paquet de données. Dans ce cas, la réponse attendue à un tel paquet correspond à un message de contrôle d'erreur. Pour le protocole ICMP, il s'agit par exemple du message « Time Exceeded ».

Selon encore une autre caractéristique particulière, le deuxième paquet étant transmis à destination du premier nœud par l'intermédiaire d'au moins un quatrième nœud, ce quatrième nœud ne modifie pas l'entête du deuxième paquet.

Il est ici souligné que les routes entre deux nœuds respectivement dans le sens montant et dans le sens descendant ne sont pas obligatoirement identiques.

Lorsqu'une congestion est susceptible de se produire également dans le sens montant, c'est-à-dire du deuxième nœud au premier nœud, les nœuds intermédiaires ne doivent pas modifier l'entête du deuxième paquet dans le plan de transfert. Il suffit ainsi de modifier le fonctionnement des nœuds intermédiaires dans le plan de transfert pour les messages de contrôle utilisés dans la mise en œuvre du procédé d'obtention. Le fonctionnement des nœuds dans le plan de commande n'est pas modifié.

Selon un deuxième aspect, l'invention concerne un nœud dans un réseau de communication par paquets, agencé pour échanger avec un autre nœud des informations de contrôle dans un plan de commande, :

- des moyens de réception, agencés pour recevoir en provenance de l'autre nœud un premier paquet ; - des moyens de traitement dudit premier paquet dans le plan de commande, agencés pour demander une émission d'un message de contrôle à destination de l'autre nœud à l'issue du traitement du premier paquet ;

- des moyens d'obtention d'une information relative à une congestion d'une route permettant un acheminement de paquets de l'autre nœud et à destination dudit nœud à partir du premier paquet ;

- des moyens d'envoi (106), agencés pour envoyer un deuxième paquet audit autre nœud, ledit deuxième paquet portant ledit message de contrôle et comprenant ladite information obtenue.

Selon un troisième aspect, l'invention concerne un système de communication dans un réseau de communication par paquets, dans lequel des premier et deuxième nœuds échangent des informations de contrôle dans un plan de commande, ledit système comprenant :

- ledit premier nœud, comprenant des moyens d'envoi agencés pour envoyer un premier paquet, pour lequel le deuxième nœud doit émettre en réponse un message de contrôle ;

- ledit deuxième nœud étant agencé tel que décrit précédemment.

On rappelle ici que le premier paquet est prévu pour déclencher l'émission d'un message de contrôle dans le plan de commande.

Selon un quatrième aspect, l'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'obtention selon le premier aspect, mises en œuvre par un nœud d'un réseau de communication par paquets, lorsque ce programme est exécuté par un processeur.

L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers du procédé de l'invention, en référence aux dessins annexés sur lesquels :

la figure 1 représente de façon simplifiée un réseau de communication par paquets selon un mode particulier de réalisation de l'invention ;

la figure 2 représente un schéma simplifié des étapes du procédé d'obtention et un synoptique des échanges entre les différentes entités mettant en œuvre le procédé d'obtention selon un mode particulier de réalisation de l'invention ;

la figure 3 rappelle de façon simplifiée la structure d'un paquet ;

la figure 4 représente un nœud selon un mode particulier de réalisation de l'invention. Sur la figure 1 est représenté de façon simplifiée un réseau 1 de communication par paquets. Ce réseau 1 comprend une pluralité d'équipements nœuds, dont cinq d'entre eux 10, 12, 14, 16, 18 sont représentés sur la figure 1. Par la suite, ces équipements nœuds sont appelés simplement nœuds. Ces nœuds jouent le rôle de routeurs dans le réseau 1, c'est-à-dire qu'ils sont en charge d'acheminer des paquets dans un plan, dit plan de transfert. Une route, également appelée chemin, permet un acheminement de paquets d'un premier nœud à destination d'un deuxième nœud par l'intermédiaire d'autres nœuds le cas échéant. Dans un autre plan, dit plan de commande, les nœuds s'échangent des informations de contrôle, par exemple à l'aide du protocole ICMP. Il est bien entendu que la connectivité d'un nœud ne se restreint pas au réseau simplifié tel que représenté sur les figures 1 et 2. Un nœud est en effet apte à acheminer des paquets vers une pluralité d'autres nœuds.

On appelle par la suite information relative à une congestion d'une route, une information qui indique l'existence d'une congestion pour au moins un des nœuds intermédiaires de la route. Cette congestion est susceptible de dégrader un acheminement des paquets le long de cette route dans le plan de transfert. Lorsque cette congestion se produit au niveau d'un nœud de la route, par exemple au niveau d'une file d'attente destinée à mémoriser les paquets en sortie du nœud avant retransmission vers le prochain nœud sur la route, les paquets sont marqués par le nœud avant retransmission à l'aide d'un champ d'information ECN, pour « Explicit Congestion Notification ». Ce champ d'information comprend un sous-champ d'information CE, pour « Congestion Experienced ». Les paquets sont ainsi marqués en positionnant le sous-champ d'information CE à la valeur un. A titre d'exemple illustratif, lorsque le nœud 14 se trouve congestionné pour l'acheminement des paquets reçus en provenance du nœud 12 et à destination du nœud 18, par l'intermédiaire du nœud 16, ces paquets sont marqués en sortie du nœud 14 et arrivent ainsi marqués au nœud 18.

Selon l'invention, lorsqu'un nœud récepteur doit transmettre un message de contrôle suite à la réception d'un premier paquet en provenance d'un nœud requérant, le nœud récepteur obtient l'information relative à la congestion à partir du premier paquet reçu et transmet le message de contrôle dans un deuxième paquet, dans lequel il recopie cette information. Ceci permet ainsi au nœud requérant de recevoir une information relative à la congestion de la route dans le sens descendant, c'est-à-dire du nœud requérant vers le nœud récepteur. Ainsi, le nœud requérant est capable de déterminer sur une route empruntée par les paquets vers le nœud récepteur qu'au moins un nœud intermédiaire se trouve congestionné.

On utilise ainsi un mécanisme de notification de congestion prévu dans le plan de transfert pour un premier sens de communication pour obtenir une information relative à une congestion de la route et on reboucle cette information dans un deuxième sens de communication opposé au premier sens. Ce rebouclage ne s'effectue que pour certains premiers paquets particuliers qui vont déclencher l'émission de messages de contrôle donnés. Ces premiers paquets sont détaillés ultérieurement en relation avec la figure 2.

On se place par la suite dans le cas où les nœuds 10, 12 et 14 mettent en œuvre le procédé d'obtention selon un mode particulier de réalisation. Plus précisément, une information relative à une congestion de la route du nœud 10 à destination du nœud 14 est nécessaire au nœud 10.

La figure 2 représente de façon schématique les étapes du procédé d'obtention dans ce mode particulier de réalisation. Dans une étape El, le nœud 10 transmet un premier paquet PI à destination du nœud 14. La figure 3 rappelle dans le contexte de la présente description les éléments constituant les paquets acheminés dans le réseau de communication 1 par paquets. L'entête du paquet est constitué d'un ensemble de champs d'informations Parti à @dst.

Afin de ne pas surcharger la description, les champs d'information consolidés sous les formes Parti, Part2 ne sont pas plus détaillés ici, étant donné qu'ils ne sont pas concernés par la mise en œuvre du procédé d'obtention.

Le champ d'information CoS 30 comprend une information relative à une classe de service, lorsque le réseau de communication 1 met en œuvre un acheminement différencié des paquets en fonction de classes de service.

Le champ d'information 31 correspond au champ d'information ECN précédemment décrit.

Le champ d'information 32 TTL, pour « Time-To-Live », indique un nombre de nœuds au travers desquels le paquet peut encore être acheminé. Sa valeur est décrémentée à chaque acheminement par un nœud. Lorsque sa valeur devient nulle, la durée de vie du paquet a expiré.

Le champ d'information 33 P permet de déterminer de quel protocole est issu le paquet.

Le champ d'information 34 @src correspond à l'adresse du nœud émetteur du paquet.

Le champ d'information 35 @dst correspond à l'adresse du nœud destinataire du paquet.

Ces différents champs d'information constituent ainsi l'entête du paquet.

Le paquet comprend en outre un champ d'information 36 qui contient les données utiles du paquet. Il comprend par exemple un message de contrôle de type IGMP lorsque le champ d'information 33 indique la valeur de deux.

Ce premier paquet transite par l'intermédiaire du nœud 12 dans le plan de transfert. On se place dans le cas où le nœud 12 rencontre une congestion dans ses files d'attente internes pour l'acheminement des paquets à destination du nœud 14. Conformément au document RFC 3168, le nœud 12 positionne le sous-champ d'information CE à la valeur un dans l'entête du premier paquet PI et obtient ainsi un deuxième paquet P2 qu'il transmet vers le nœud 14.

Le deuxième paquet P2 est reçu par le nœud 14 dans une étape Fl.

Dans une étape F2, le nœud 14 traite le deuxième paquet reçu P2 dans le plan de commande. A l'issue de ce traitement, un message de contrôle doit être émis à destination du nœud émetteur du premier paquet, c'est-à-dire le nœud 10. Le nœud 14 transfère le message de contrôle au plan de transfert pour qu'il soit acheminé.

Dans le plan de transfert, le nœud 14 obtient dans une étape F3 l'information relative à une congestion à partir du deuxième paquet reçu P2. Dans une étape F4, le nœud 14 constitue l'entête d'un troisième paquet P3 à destination du nœud 10 et y copie l'information relative à la congestion obtenue à l'étape F3. Ce troisième paquet comprend également le message de contrôle à envoyer.

Toujours dans cette étape F4, le nœud 14 transmet le troisième paquet P3 à destination du nœud 10. Le troisième paquet P3 est acheminé par l'intermédiaire d'un ou de plusieurs nœuds intermédiaires.

Dans une étape E2, le nœud 10 reçoit le troisième paquet P3 et a ainsi obtenu une information relative à la congestion de la route à partir de lui-même et à destination du nœud 14.

Cette information n'est pas fournie spontanément ni en association avec un paquet qui devait être acheminé dans le sens descendant mais sur déclenchement par un nœud demandeur uniquement.

Le procédé d'obtention peut s'intégrer dans un procédé plus général, dans lequel le nœud 10 interroge successivement les différents nœuds 14, 16 composant le chemin acheminant des paquets à destination du nœud 18. Un tel chemin peut être obtenu à l'aide d'un protocole de routage. Il peut également être obtenu à l'aide d'un programme utilitaire, appelé Traceroute, dont le fonctionnement est détaillé ultérieurement en relation avec un mode particulier de réalisation.

Le nœud 10 peut alors utiliser cette information relative à une congestion obtenue pour la route à destination du nœud 18 pour admettre ou non une nouvelle session à destination d'un destinataire raccordé au nœud 18. Le nœud 10 peut également utiliser cette information relative à une congestion pour moduler les débits des communications.

Le nœud 10 peut insérer des premiers paquets PI selon certaines règles, par exemple soit régulièrement dans le flux de données, soit régulièrement pour un ensemble de communications entre lui-même et un ensemble de destinations, par exemple l'ensemble des clients raccordés à un même nœud du réseau, tel qu'un multiplexeur DSLAM, pour « Digital Subscriber Line Access Multiplexer ».

Dans un premier mode de réalisation, le premier paquet PI porte un message de contrôle ICMP « Echo request ». Dans ce cas, lors de l'étape de traitement F2 du paquet reçu, le nœud 14 détecte qu'il doit émettre un autre message de contrôle en réponse au message de contrôle ICMP « Echo Request ». Il s'agit d'un message ICMP « Echo Reply ». Le troisième paquet P3 portant le message « Echo Reply » est modifié pour permettre de reboucler l'information relative à la congestion telle que reçue. Les modifications à apporter aux nœuds pour mettre en œuvre le procédé d'obtention sont ainsi limitées.

Dans un deuxième mode de réalisation, le nœud 10 met en œuvre le programme utilitaire Traceroute mentionné précédemment. Ce programme consiste à émettre des paquets indiquant une durée de validité TTL, pour « Time-To-Live », de plus en plus grande. Chaque nœud retransmettant le paquet décrémente la durée de validité. Lorsque celle-ci devient nulle, le nœud ne transmet pas le paquet mais émet à destination du nœud 10 un message de contrôle ICMP « Time exceeded ». Dans ce deuxième mode de réalisation, lors de l'étape de traitement F2, le nœud 14 détecte qu'il doit émettre un message de contrôle en réponse au paquet reçu. Il s'agit d'un message de contrôle ICMP « Time exceeded ». Le troisième paquet P3 portant le message de contrôle ICMP « Time Exceeded » est modifié pour permettre de reboucler l'information relative à la congestion telle que reçue. On constate que dans ce deuxième mode de réalisation, les modifications à apporter aux nœuds sont également limitées.

Dans un troisième mode de réalisation, un nouveau message correspondant à une demande de fourniture de l'information de congestion est prévu pour un protocole de commande, par exemple pour le protocole ICMP. Le premier paquet PI, et par conséquent le deuxième paquet P2, portent alors ce nouveau message de contrôle. Une réponse à la demande de fourniture est également prévue pour fournir l'information relative à la congestion. Le troisième paquet P3 porte alors ce message de réponse à la demande de fourniture.

Pour l'ensemble de ces modes de réalisation, le nœud initiateur 10 provoquant l'émission du premier paquet PI et déclenchant ainsi l'émission du troisième paquet P3 peut superviser la bonne réception de ce dernier. De plus, la mise en œuvre du procédé d'obtention ne provoque aucune surcharge du réseau de communication, ces échanges de premier et troisième paquets étant ponctuels.

Le troisième paquet P3 porte ainsi une information relative à la congestion de la route du nœud 10 à destination du nœud 14 qui ne doit pas être modifiée par des nœuds intermédiaires acheminant le troisième paquet à destination du nœud 10.

Dans un mode de réalisation particulier, il est donc prévu que le ou les nœuds intermédiaires acheminant le troisième paquet P3 dans le sens montant, c'est-à-dire du nœud 14 au nœud 10, vérifient dans le plan de transfert si le troisième paquet P3 porte un message de contrôle appartenant au groupe comprenant un message ICMP « Echo Reply », un message ICMP « Time exceeded » ou bien encore la réponse à la demande de fourniture. Si tel est le cas, le nœud intermédiaire ne modifie pas le champ d'information 31 du troisième paquet P3, même s'il rencontre une situation de congestion sur ce sens montant.

On se place par la suite dans un réseau 1 de communication par paquets dans lequel les nœuds mettent en œuvre un acheminement différencié des paquets en fonction de classes de services CoS, pour « Class of Service ». Il s'agit par exemple d'un réseau de communication en mode Diffserv, pour « Differenciated Services ». Dans un tel réseau, les paquets portent une information relative à leur classe de service. A titre d'exemple, pour quatre classes de service notées de 1 à 4, un paquet de classe de service 1 bénéficie d'un niveau de priorité le plus élevé ; un paquet de classe de service 4 bénéficie d'un niveau de priorité le plus faible. Dans un tel réseau, il est prévu pour les trois modes de réalisations une variante permettant à un nœud d'obtenir une information relative à une congestion pour l'acheminement des paquets pour une classe de service donnée. En effet, dans un tel réseau, une file d'attente est généralement prévue pour chacune des classes de service. Une classe de service peut alors être perturbée si le trafic généré par les paquets de cette classe est supérieur aux capacités de traitement du nœud.

Le premier paquet PI transmis par le nœud 10 comprend un champ d'information 30 comprenant la classe de service pour laquelle l'information de congestion est demandée. Ainsi le nœud 10 peut obtenir une information relative à la congestion de la classe de service donnée pour la route à destination du nœud 14.

En option, un nœud intermédiaire peut également positionner l'information relative à une congestion pour toutes les classes de service de niveau supérieur à la classe de service donnée.

Un exemple de mise en œuvre du procédé d'obtention dans un réseau de communication en mode Diffserv va maintenant être décrit à titre illustratif.

Dans cet exemple, le nœud 10 joue le rôle d'un serveur de contenus, assurant les fonctions d'une plateforme de service audiovisuel et intégrant un dispositif de commande. Le dispositif de commande peut aussi être externe au serveur de contenus.

Le serveur de contenus 10 est apte à délivrer des paquets de données formant un flux vidéo à des terminaux clients, par exemple le nœud 16, à travers le réseau 1 de communication par paquets par l'intermédiaire des nœuds 12, 14. Le terminal client 16 correspond par exemple à une passerelle résidentielle, formant le point d'entrée à un réseau résidentiel d'un utilisateur. Le nœud 12 correspond à un routeur et le nœud 14 correspond à un équipement d'accès au réseau de communication, par exemple un multiplexeur DSLAM, pour « Digital Subscriber Line Access Multiplexer », auquel est raccordé le terminal client 16. Le nœud 18 correspond à un équipement du réseau résidentiel, par exemple un terminal de type PC.

Il est bien entendu que l'invention s'applique à d'autres contextes que celui qui vient d'être décrit. Par exemple, le terminal de type PC peut être connecté directement au réseau, sans l'intermédiaire d'une passerelle. De même, le nœud 16 peut être le point d'entrée d'un réseau d'entreprise. Le nœud 14 peut quant à lui être de tout type DSLAM comme déjà mentionné, ou en variante MSAN pour « MultiService Access Node » dans une technologie ADSL, pour « Asymmetric Digital Subscriber Line », ou optique FTTH, pour « Fiber To The Home ».

Le réseau de communication IP en mode Diffserv supporte simultanément des services prioritaires dits « Premium » et non prioritaires dits « Best Effort ». Tant que la proportion de trafic relatif aux services « Best Effort » par rapport à celui relatif aux services « Premium » reste importante en volume, aucun mécanisme particulier autre que les mécanismes de priorisation prévus par Diffserv n'est requis. En effet, la simple priorisation des flux de données associés à des services « Premium » sur des flux de données associés à des flux « Best Effort » permet d'assurer aux flux de données associés à des services « Premium » un niveau de qualité de service satisfaisant, en supprimant éventuellement une partie des flux de données associés aux services « Best Effort » lorsque les taux de charge deviennent très élevés.

En revanche, lorsque la proportion de services « Premium » devient importante en volume, il n'est plus possible de compter uniquement sur les mécanismes de priorisation Diffserv pour sauvegarder les flux de données associés à des services « Premium ». Dans ce cas, seules des fonctions de contrôle d'admission limitant l'établissement de nouvelles communications de type « Premium » et utilisant des ressources congestionnées, ou bien d'adaptation de débit des communications de type « Premium », par exemple à l'aide de SVC, permettent d'assurer aux communications de type « Premium » déjà établies un niveau de qualité satisfaisant.

La mise en œuvre du procédé d'obtention permet de déclencher la mise en œuvre de ces fonctions.

A l'étape El, le serveur de contenu 10 insère des messages ICMP « Echo Request » pour les services « Premium » à destination des nœuds 14, 16 formant le chemin vers le client final.

Sur réception (étape Fl) d'un premier paquet PI portant le message ICMP « Echo Request », le nœud destinataire indique (étape F4) dans un troisième paquet P2 portant un message ICMP « Echo Reply » une éventuelle congestion affectant le sens descendant des services « Premium », c'est-à-dire du serveur de contenus 10 vers le client final. Il s'agit par exemple d'un dépassement de seuil dans une file d'attente.

Sur réception de cette notification explicite, le serveur de contenus 10 met alors en œuvre la fonction de contrôle d'admission de nouvelles communications pour les services « Premium » et utilisant la ressource congestionnée. Le déblocage du serveur de contenus 10 se fait après une certaine période sans réception de notifications de congestion. Les services « Best Effort » ne sont pas affectés par la mise en œuvre du procédé pour les services « Premium ». Ainsi, même si une classe de faible priorité, par exemple pour les services « Best Effort », arrive à saturation, il n'y a pas d'impact sur les messages « Echo Reply » transmis pour la classe de priorité plus élevée.

La solution proposée est adaptée ainsi particulièrement adaptée aux systèmes dans lesquels sont définies différentes classes de trafic avec priorité de certaines classes sur les autres.

Un équipement nœud du réseau de communication par paquets va maintenant être décrit en relation avec la figure 4. Un tel équipement nœud comprend notamment :

- un module d'émission et de réception 102, agencé pour émettre et recevoir des paquets dans le plan de transfert ;

- un module 104 de traitement des paquets, agencé pour traiter les paquets à acheminer ;

- un module 106 de contrôle, agencé pour échanger avec un autre équipement nœud des informations de contrôle dans le plan de commande ; - un module de détection 108 d'une congestion, agencé pour détecter une congestion susceptible de dégrader un acheminement par cet équipement nœud de paquets émis par l'autre équipement nœud.

Le module de contrôle 106 est en outre agencé pour :

- recevoir par l'intermédiaire du module 102 et en provenance de l'autre équipement nœud un premier paquet PI,

- traiter le premier paquet PI et en fonction de celui-ci demander au module 102 l'émission d'un message de contrôle à destination de l'autre équipement nœud.

Le module 102 est également agencé pour traiter des paquets dans le plan de transfert, et notamment pour obtenir à partir du premier paquet PI, auquel le message de contrôle répond, une information relative à une congestion de la route dans le sens descendant, copier cette information dans un deuxième paquet à émettre. Ce deuxième paquet porte le message de contrôle transmis par le module de contrôle 106.

Dans un mode de réalisation, le module de contrôle 106 est également agencé pour déclencher l'envoi du premier paquet PI à destination de l'un quelconque des nœuds du réseau de communication 1.

Comme décrit précédemment, le premier paquet PI peut comprendre un message de contrôle ICMP comme décrit en relation avec les premier et troisième modes de réalisation.

Le premier paquet PI peut également être un paquet pour lequel la durée de validité expire, comme décrit en relation avec le deuxième mode de réalisation. Dans ce cas, le module de traitement de paquets 104 détecte lors du traitement du paquet que la durée de vie a expiré et transmet alors cette information au module de contrôle 106.

Dans un mode de réalisation particulier, le module de traitement 104 est également agencé pour ne pas modifier l'entête de deuxièmes paquets, lorsque ces derniers portent un message de contrôle particulier, tel que décrit précédemment.

Le module de contrôle 106 de l'équipement nœud est agencé pour mettre en œuvre celles des étapes du procédé d'obtention précédemment décrit exécutées par l'équipement nœud. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé d'obtention précédemment décrit, mises en œuvre par un équipement nœud. L'invention concerne donc aussi :

- un programme pour équipement nœud, comprenant des instructions de programme destinées à commander l'exécution de celles des étapes du procédé d'obtention précédemment décrit qui sont exécutées par ledit équipement nœud, lorsque ledit programme est exécuté par un processeur de celui-ci ;

- un support d'enregistrement lisible par un équipement nœud sur lequel est enregistré le programme pour équipement nœud. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.

L'invention concerne également un système de communication dans un réseau de communication par paquets, dans lequel des premier et deuxième nœuds échangent des informations de contrôle dans un plan de commande. Le système comprend :

- un premier nœud, comprenant un module de contrôle 106 agencé pour envoyer à un deuxième nœud un premier paquet, pour lequel le deuxième nœud doit émettre en réponse un message de contrôle ;

- un deuxième nœud tel que décrit précédemment.

Les exemples qui précèdent ne sont que des modes possibles de mise en œuvre de l'invention qui ne s'y limite pas. Notamment, d'autres réseaux peuvent être concernés, tels que les réseaux de type ATM.