FR 2973976 A1 20121012 FR 1153133 A 20110411 Protocole pour routage de flots par interrogation d'un serveur distant La présente invention est relative au routage par flots dans un réseau de communication de type Internet. Ces réseaux de communication reposent sur la suite protocolaire TCP/IP Historiquement, ils sont basés sur un routage de paquets : chaque paquet est aiguillé de façon autonome au sein du réseau jusqu'à la destination finale qui a la responsabilité d'assembler correctement les paquets pour reconstituer les données initiales. Il y a en outre aucun lien entre la nature des données transportées et le routage. Le besoin est venu de créer ce lien afin de discriminer certains types de trafic par rapport à d'autres, notamment en fonction à la fois de la nature du trafic (flux vidéo, transactions HTTP etc.) et du réseau d'accès (Wi-Fi, 3G, Ethernet, FemtoCell, etc.) Ce besoin a provoqué la création d'une famille de mécanismes permettant d'affiner le routage avec une granularité basée sur le flot de paquets et non plus le paquet pris individuellement. Ces mécanismes sont généralement appelées « IP Flow Routing ». Elles s'appliquent notamment aux technologies d'accès radios. Les opérateurs de tels réseaux peuvent en effet ne souhaiter transmettre qu'un certain type de trafic. Par exemple un réseau de type LTE (pour « Long Term Evolution ») peut donner une préférence à la transmission de trafic de voix sur IP (ou « Voice over IP », VOIP) par rapport à du trafic HTTP (HyperText Transfer Protocol), tandis que le choix inverse pourrait être fait pour un réseau de type Wi-Fi, tel que spécifié par le standard IEEE 802.11. Les hôtes eux-mêmes peuvent avoir à faire cette détermination de choisir un réseau d'accès plutôt qu'un autre afin de transmettre un flot de données. Par exemple, un terminal de communication bi-mode peut privilégier un réseau d'accès LTE pour le trafic voix ou vidéo et un réseau d'accès Wi-Fi pour d'autres types de trafic. Cette détermination et le contrôle du routage basée sur le type de flot est possible avec certains systèmes d'exploitation, comme le module « Linux Advanced 1 Routing and Traffic Control » (LARTC). La figure 1 schématise le mécanisme offert par LARTC. Un hôte H s'interface avec deux réseaux d'accès AN I et AN2. Les réseaux d'accès sont eux-mêmes connectés au réseau internet N. L'hôte H possède une interface IF1 avec le réseau d'accès AN1 et une interface IF2 avec le réseau d'accès AN2. L'hôte H peut donc communiquer avec le réseau internet N par l'un ou l'autre des réseaux d'accès AN 1, AN2. Il est possible de définir des tables de routage associés à chacun de ces réseaux d'accès dans l'hôte H, ainsi que des règles de routage permettant de définir les cas d'utilisation de l'une ou l'autre de ces tables de routage. Ces mécanismes sont par exemple explicités sur le lien web : http://lartc.org/howto/lartc.rpdb.multiple-links.htn-al Également, le lien http://lnux-ip.net/html/lnux-ip.html explique, au paragraphe 4.9, les politiques de routage dans un noyau Linux. Toutefois, cette possibilité est insuffisante, à elle seule, pour répondre pleinement aux exigences des opérateurs des réseaux d'accès. Il s'agit en effet d'un mécanisme statique où les règles et tables de routage sont configurées dans l'hôte H. Les modifications de ces règles et tables de routage ne peuvent être effectuées que localement et de façon dépendante de l'hôte : le format des règles, les interfaces de configuration etc. sont différentes en fonction des systèmes d'exploitation des hôtes et en fonction des implémentations. La présente invention vise donc à améliorer la situation en permettant aux opérateurs des réseaux d'accès de contrôler les politiques de routage utilisés par les hôtes. Pour ce faire, elle pour premier objet un procédé d'émission de flots composés de paquets de données par un hôte de communication possédant un ensemble de points de sortie permettant l'émission des flots, ceux-ci étant acheminés vers un point parmi l'ensemble de points de sortie en fonction d'informations de routage déterminées par des caractéristiques des flots. Ce procédé comporte en outre une 2 étape d'interrogation d'un serveur distant afin de recevoir au moins une partie des informations de routage. Selon un mode de réalisation de l'invention, ce procédé peut comprendre - une étape d'émission par le serveur distant d'un message de notification vers l'hôte de communication, ce message de notification contenant des informations de routage et n'étant pas sollicité par l'hôte de communication, et - une étape de mise à jour par l'hôte de communication de ses propres informations de routage en fonction des informations de routage contenues dans le message de notification. Il peut également comporter une étape préalable de détermination du serveur distant déclenchée lors de la connexion dudit hôte de communication au réseau d'accès associé au serveur distant. Il peut comprendre une étape préalable de réception de l'identifiant de ce serveur distant dans un message de réponse provenant d'un serveur de configuration dynamique (de type DHCP). Suite à la réception dudit identifiant, l'hôte de communication peut interroger un serveur de noms de domaines (de type DNS) pour résoudre l'identifiant et obtenir une adresse I R L'invention a aussi pour objet un hôte de communication possédant - un ensemble de points de sortie permettant l'émission de flots composés de paquets de données, - une mémoire contenant des informations de routage - un dispositif de routage pour acheminer les flots vers l'un parmi l'ensemble de points de sortie en fonction d'informations de routage déterminées par des caractéristiques des flots, et un client protocolaire pour recevoir d'un serveur distant au moins une partie de ces informations de routage. L'invention a également pour objet un serveur disposant d'une interface pour 3 recevoir des requêtes provenant d'hôtes de communication, chaque requête contenant l'identifiant d'un point de sortie d'un des hôtes, et pour émettre une réponse à l'hôte contenant des informations de routage relatives au point de sortie et déterminées à partir d'une base de données associant des informations de routage à des identifiants de points de sorties. Ainsi, les serveurs de politique de routage peuvent être hébergés et contrôlés par les opérateurs des réseaux d'accès qui ont de ce fait la pleine maîtrise des règles et politiques utilisés par les hôtes. Celles-ci peuvent notamment être gérées de façon dynamique : toute mise à jour sur les serveurs de l'opérateur a un impact immédiat sur toute nouvelle requête en politique de routage émanant des hôtes. En outre, la communication des politiques de routage est effectuée au dessus de la pile protocolaire utilisée par les réseaux d'accès. Elle ne dépend donc plus des systèmes d'exploitation déployés sur les hôtes. Outre le fait qu'il s'agisse d'un souhait important des opérateurs, il y a également un autre avantage à leur laisser le contrôle des politiques de routage : ils possèdent une meilleure vue sur ce que le réseau est à même de transmettre ou pas, à la fois d'un point de vue statique (technologie, configuration...) que dynamique (mesure de la charge, de la QoS...). D'autres avantages et les caractéristiques de l'invention apparaîtront de façon plus claire dans la description de mises en oeuvre qui va suivre en liaison avec les figures annexées. La figure 1, déjà commentée, schématise une architecture mettant en oeuvre l'état de la technique. La figure 2 schématise une architecture de réseau supportant l'invention, ainsi qu'une architecture fonctionnelle possible pour un hôte de communication selon l'invention. La figure 3 représente un graphe temporel illustrant le procédé selon l'invention. La figure 4 illustre une architecture de réseau incorporant des serveurs DHCP et DNS, selon un mode de réalisation de l'invention. 4 2973976 La figure 5 représente un graphe temporel relatif à ce mode de réalisation. D'une façon générale, un hôte IP (host en langue anglaise) peut comporter plusieurs points de sortie. À chacun de ces points de sortie est associée une adresse IR 5 Ces points de sortie appartiennent à des interfaces, chaque interface pouvant avoir un ou plusieurs points de sortie. Dans l'exemple de la figure 2, l'hôte de communication H est connecté à un réseau de coeur N par deux réseaux d'accès NA et NB. Il comporte deux interfaces de 10 communication vers ces réseaux d'accès, IFA, IFB respectivement. La première interface IFA comporte deux points de sortie P1, P2 correspondant à deux adresses IP distinctes. La seconde interface IFB comporte un seul point de sortie P3 correspondant à une adresse IR Dans la suite de la description, on ne mentionnera pas la présence de points 15 d'entrée au sein de ces interfaces, dans la mesure où ils ne jouent pas de rôle particulier dans le cadre de l'invention. De façon connue en soi, l'hôte de communication H comporte un dispositif de routage R et des clients protocolaires HTTPc, FTPc. Le dispositif de routage a pour rôle d'aiguiller un flot de paquets de données issu d'un client protocolaire vers l'un des 20 points de sortie P1, P2,P3. Ce routage par flot s'effectue pour les flots de paquets, et non pas pour chaque paquet pris individuellement. Pour ce faire, le dispositif de routage R extrait des caractéristiques des flots de données. Cette extraction va au-delà des entêtes « adresse 25 destination » et « port destination » utilisés pour le routage de paquets. Les caractéristiques à extraire ou à déterminer pour chaque flot de paquets peuvent dépendre d'informations de routage contenues dans une mémoire P de l'hôte de communication H. Il existe quelques travaux visant à définir les champs pouvant être utilisés pour la 30 sélection des flots de paquets de données. On peut par exemple citer le RFC 2280, « Routing Policy Specification Language » et le RFC 6080, « trafic Selectors for Flow Bindings ». 5 Cette extraction en profondeur peut n'être réalisée entièrement que pour le premier paquet d'un flot, afin de déterminer ses caractéristiques et s'il répond aux conditions fixées par une règle de routage. Pour les paquets subséquents, il peut suffire de déterminer son appartenance au flot. Pour ce faire, une analyse d'un nombre plus limité d'entêtes du paquet IP peut être suffisante. Typiquement, une telle identification peut être effectuée sur la base d'un 5-tuple formé des adresses et ports source et destination, ainsi que de l'identifiant du protocole utilisé (c'est-à-dire TCP, UDR..). Selon un mode de réalisation de l'invention, ces informations de routage peuvent être composées de tables de routage et de règles de routage. Plusieurs tables de routage peuvent ainsi être disponibles pour le dispositif de routage R. Les règles de routage peuvent indiquer quelle table de routage s'applique en fonction de caractéristiques de flots de paquets. Les caractéristiques sont directement ou indirectement issues des entêtes des paquets. Ces entêtes sont généralement des entêtes de la couche IP mais des mécanismes plus complexes peuvent être mis en oeuvre nécessitant d'explorer d'autres couches protocolaires. Ces techniques peuvent être celles connues sous le terme de « Deep Packet Inspection » (DPI, ou « Inspection de paquets en profondeur » en langue française) qui consiste à aller au-delà de l'entête IP pour explorer le contenu du paquet. Il peut également être possible de déterminer des caractéristiques qui agrègent plusieurs entêtes ou dérivent d'un ou plusieurs entêtes. Dans une mise en oeuvre basée sur le mécanisme «Advanced Routing » du système d'exploitation Linux, ces règles sont stockées dans une partie de la mémoire P appelée « Routing Policy DataBase » (RPDB). Les règles contrôlent l'ordre dans lequel le dispositif de routage R effectue une recherche dans les tables de routage. Chaque règle possède une priorité. A l'émission du premier paquet d'un flot, le dispositif de routage R parcourt l'ensemble des règles dans l'ordre des priorités et stoppe ce parcours lorsqu'il 6 rencontre une règle dont les prémisses sont vérifiées par le flot à router. Le dispositif de routage applique alors la règle. Typiquement, il s'agit d'utiliser une table de routage particulière désignée par cette règle et d'y effectuer une recherche de route, mais d'autres options sont également possibles. Exemple de routage de flots basé sur une caractéristique de protocole Dans l'exemple de la figure 2, deux clients protocolaires HTTPc et FTPc peuvent émettre des flots de paquets de données à destination de deux serveurs protocolaires, 10 respectivement HTTPs et FTPs, et recevoir des flots de données en réponse, également conformes aux protocoles HTTP (HyperText Transfert Protocol) et FTP (File Transfert Protocol). Pour transmettre leurs flots de paquets de données, les deux clients protocolaires HTTPc et FTPc communiquent avec le dispositif de routage R. 15 Des informations de routage ont été prévues dans la mémoire P pour acheminer différemment ces deux flots. Ces informations de routage peuvent prendre la forme de règles et éventuellement de table de routage. Par exemple, la mémoire P peut comprendre les deux règles suivantes (exprimées en pseudo- langage naturel pour la facilité de compréhension) : 20 SI protocole = HTTP ; route=IFA SI protocole=FTP; route=lFB Ces deux règles expriment que les flots correspondant à une session HTTP sont routés sur l'interface IFA, et atteindront donc le serveur HTTPs par le réseau d'accès NA, et que les flots FTP sont routés sur l'interface IFB et atteindront donc le serveur 25 FTPs via le réseau d'accès NB. Une autre mise en oeuvre consiste à dispose dans la mémoire P de deux règles et de deux tables de routage TH et TF Les deux règles peuvent avoir pour forme : 30 SI protocole=HTTP ; route=TH SI protocole=FTP ; route=TF Plutôt que d'indiquer une interface de sortie, cette mise en oeuvre permet 7 d'indiquer une table de routage à utiliser : la table TH pour le protocole HTTP et la table TF pour le protocole FTP. D'autres mises en oeuvre et structures de la mémoire P sont bien évidemment possibles. La détermination du protocole utilisé par un flot donné peut être effectuée en déterminant la valeur du champ « Protocol » de l'entête IR Il est ainsi possible d'aiguiller différemment le trafic FTP et le trafic HTTP, en 10 tenant compte au mieux des avantages et caractéristiques techniques des réseaux d'accès NA et NB. Interrogation d'un serveur de règles (protocole HRP) 15 Par ailleurs, l'hôte H dispose d'un client protocolaire HRPc pour recevoir d'un serveur distant SA, SB au moins une partie des informations de routage stockées dans la mémoire P. Il peut être prévu que des informations de routage soient mémorisées dans la mémoire P par d'autres moyens et que seule une partie des informations de routage 20 proviennent d'un ou de plusieurs serveurs distants. Selon une mise en oeuvre préférentielle, on dispose d'un serveur pour chaque réseau d'accès. De cette façon, chaque opérateur de réseau possède la maîtrise de son propre serveur et peut ainsi gérer les informations de routage qui sont transmises aux hôtes de communication. Ainsi, dans l'exemple de la figure 2, le réseau d'accès 25 NA est associé à un serveur SA et le réseau d'accès NB est associé à un serveur SB. Les serveurs SA, SB disposent classiquement d'une interface pour recevoir des requêtes provenant des hôtes de communication et pour émettre une réponse à ces hôtes. Ils disposent en outre d'une base de données associant des informations de 30 routage à des identifiants de points de sorties (c'est-à-dire, typiquement, à des adresses IP). 8 La figure 3 illustre un cycle typique de mise en oeuvre du protocole de l'invention. Ce protocole peut être appelé HRP pour « Host Routing Policy ». Il consiste en plusieurs types de messages : un message de requête, un message de réponse, et éventuellement un message de notification. Ces messages peuvent être transportés par différents protocoles de transport comme UDP ou TCP. Dans un premier temps, le client protocolaire HRPc de l'hôte de communication H transmet un message M1 au serveur SA, pour son point de sortie pl. Ce message peut contenir un identifiant du type de message. Cet identifiant peut simplement indiquer qu'il s'agit d'une requête conforme au protocole HRP selon l'invention. Il peut également contenir un identifiant d'échange, permettant une corrélation entre la requête et la réponse par l'hôte de communication H. Il peut également contenir d'autres paramètres. Par exemple, un paramètre peut indiquer que la requête émane d'un hôte de communication. Il peut en effet être prévu qu'un serveur puisse interroger par le même protocole un autre serveur et que les serveurs puissent ainsi échanger des informations de routage. Cela peut permettre de disposer aisément de plusieurs serveurs pour un même réseau d'accès afin de permettre une répartition de la charge. Les mises à jour peuvent ainsi être diffusées sur l'ensemble des serveurs par ce mécanisme d'interrogation entre serveurs. Un serveur peut éventuellement même interroger un autre serveur pour copier l'intégralité de la base de données d'un autre, notamment en cas de démarrage. À la réception de ce message M1, le serveur SA peut utiliser l'identifiant du point de sortie pl à partir duquel le message M1 a été émis par l'hôte H. Cet identifiant peut tout simplement être l'adresse IP contenue dans l'entête « source address » du paquet IP encapsulant le message M1. D'autres identifiants peuvent être utilisés. Notamment l'identifiant peut être déterminé par l'hôte de communication H et transmis comme paramètre du message 9 de requête M1. À partir de cet identifiant, le serveur SA peut interroger sa base de données pour récupérer des informations de routage associées. Ces informations de routage peuvent être directement utilisées comme réponse à l'hôte de communication H, ou bien elles peuvent fournir des informations primaires à partir desquelles peuvent être dérivées des informations secondaires qui sont fournies comme réponse à l'hôte. En effet, il peut être prévu que le serveur possède un dispositif de traitement qui construit ou dérive à la volée des informations de routage à partir d'informations primaires (« templates ») et de l'identifiant du point de sortie de l'hôte. La réponse M2 adressée à l'hôte de communication H peut contenir : un identifiant du type de message. Cet identifiant peut indiquer qu'il s'agit d'un message de réponse du protocole HRP. Un identifiant d'échange qui doit être le même que celui contenu dans le message M1. L'hôte de communication peut ainsi corréler les deux messages M1 et M2 et comprendre que le message M2 reçu est la réponse du message M1 envoyé. Des informations de routage. Ces informations de routage peuvent être réparties sur plusieurs messages de réponse M2. Dans ce cas, chaque message de réponse doit contenir le même identifiant d'échange. Ils peuvent également contenir un drapeau indiquant que d'autres messages de réponse suivent. À la réception de ce message M2 (ou de ces messages), le client protocolaire HRPc envoie des mises à jour U1 à la mémoire P. Sur la figure 3, la mémoire P est agrégée avec le dispositif de routage R pour simplifier la lecture. Selon un mode de réalisation de l'invention, les informations de routage peuvent être des règles. Ces règles peuvent ne définir que ce qui est autorisé sur le point d'interface concerné. Par défaut, ce qui n'est pas explicitement autorisé par une règle est donc interdit. L'hôte H peut structure les informations reçus de différentes façon. Notamment, il 10 peut structurer tout ou parti des informations de routage reçues sous la forme de table de routage. Selon un mode de réalisation préférentiel, une requête vers un serveur doit être envoyée pour chaque point de sortie pl, p2, p3 de l'hôte de communication H. Le client protocolaire HRPc peut donc également envoyer un autre message de requête pour le point de sortie p2 vers le même serveur SA. Ce message, ainsi que le message de réponse, ne sont pas représentés sur la figure 3. Ils sont similaires aux messages M1 et M2 et ne diffèrent que par les valeurs du contenu. Le client protocolaire HRPc envoie un autre message de requête M3 pour le troisième point de sortie p3 appartenant à l'interface IFB. Cette requête est adressée au serveur SB associé au réseau d'accès NB. Ce serveur SB, similaire au serveur SA, répond à l'hôte de communication H par un message de réponse M4 contenant des informations de routage déterminées à partir d'une base de donnée. À la réception de ce message de réponse M4, le client protocolaire HRPc envoie une mise à jour U2 à la mémoire P associée au dispositif de routage R. Ce dispositif de routage R peut alors traiter les flots avec ces informations de routage mises à jour. Dans l'exemple des figures 2 et 3, on suppose que le serveur SA transmet une règle spécifiant qu'il accepte le trafic HTTP. Le serveur SB, quant à lui, transmet une règle spécifiant qu'il accepte le trafic FTP. De telles règles peuvent avoir pour forme : IF protocol=FTP ; route=IFB/p3 IF protocol=http ; route=IFA/pl Le dispositif de routage transmet donc le flot FTP FF vers le point de sortie p3. Il traverse le réseau d'accès NB avant d'atteindre le réseau coeur N et le serveur FTPs. Le flot HTTP FH est acheminé vers le point de sortie pl. Il traverse le réseau d'accès NA avant d'atteindre le réseau coeur N et le serveur HTTPs. 11 Dans un mode de réalisation de l'invention, l'hôte H peut avoir des moyens pour résoudre des problèmes liés à la cohérence des informations de routage qui lui sont communiqués sur ces différents points de sortie. Notification Par ailleurs, les serveurs SA, SB peuvent transmettre des informations de routage aux hôtes de communication, autrement que sur requête de ces derniers. En effet, dans la plupart des cas, il est estimé que les hôtes de communication transmettent ces requêtes lors de leur connexion au réseau d'accès, mais il peut également être prévu que les opérateurs des réseaux d'accès procèdent à des modifications de leurs politiques de routage et puisse modifier la base de données associée au serveur. Dans cette optique, le protocole HRP peut comporter un message de notification. Un message de notification se caractérise par sa transmission à l'initiative d'un serveur, sans sollicitation de l'hôte de communication. Ils peuvent être transmis à un hôte en particulier ou à l'ensemble des hôtes connus d'un serveur. Dans ce dernier cas, une mise en oeuvre peut consister à transmettre la notification sur une adresse multicast spécifique pour ce mécanisme. Une autre mise en oeuvre consiste à disposer au sein du serveur d'une mémoire pour y stocker les adresses des hôtes de communication avec lesquels le serveur est amené à échanger des messages, et de s'y reporter lorsqu'une notification globale est à envoyer. Dans l'exemple de la figure 3, le serveur SA transmet un message de notification M5 au hôte de communication H. Ce message de notification peut contenir : un identifiant du type de message. Cet identifiant peut indiquer qu'il s'agit d'un message de notification du protocole HRP. Des informations de routage. Un type d'événement qui décrit le but de la notification (par exemple, ajout ou suppression) A sa réception, le client protocolaire HRPc peut adresser une mise à jour U3 de la mémoire R. 12 2973976 Détermination d'un serveur de règles de routage Plusieurs mises en oeuvre sont possibles pour permettre à un hôte de 5 communication H de connaître l'adresse d'un serveur SA, SB, auprès duquel il peut obtenir les informations de routage. Son adresse (ou autre identification) peut être localement configurée par l'administrateur de l'hôte. Une autre mise en oeuvre peut consister à ce que l'hôte de communication 10 émette une requête sur une adresse multicast prédéterminée afin qu'un serveur puisse lui répondre et établisse ainsi une connexion hôte-serveur. Cette requête peut être émise lors de la connexion de l'hôte de communication H au réseau d'accès NA, NB. Une autre mise en oeuvre peut consister à obtenir l'identifiant du serveur distant 15 dans un message de réponse provenant d'un serveur d'allocation dynamique d'adresses. Une telle mise en oeuvre est illustrée par la figure 4. Cette figure 4 reprend les dispositifs illustrés par la figure 2 et y ajoute des serveurs de configuration dynamique DHCPA, DHCPB, et des serveurs de noms de domaine, DNSA, DNSB 20 Ces serveurs de configuration dynamique sont typiquement conformes au RFC 2131, « Dynamic Host Configuration Protocol ». Un tel serveur est généralement connu sous le terme de « serveur DHCP ». Les serveurs de configuration dynamique DHCP sont typiquement utilisés pour permettre de configurer un hôte dynamiquement un hôte de façon transparente et 25 sans intervention d'un administrateur ou même de l'utilisateur de l'hôte. Lors de sa connexion à un réseau de communication, des échanges standardisés permettent à l'hôte H d'acquérir automatiquement les informations essentielles pour communiquer avec ce réseau de communication. Parmi les informations essentielles figurent généralement l'adresse IP que cet hôte doit utiliser pour ses communications. 30 Selon l'invention, l'hôte H peut également acquérir l'identifiant des serveurs distants SA, SB grâce à ce mécanisme et l'utilisation de ce type de serveurs. 13 La figure 5 illustre les échanges entre l'hôte H et le réseau d'accès NA. Le même type d'échange est mis en place avec le réseau d'accès NB. Un premier message MD1 peut être adressé par un client protocolaire DHCPc contenu dans l'hôte H vers le serveur DHCPA. Ce message MD 1 peut être transmis lors de la connexion de l'hôte H au réseau d'accès NA. Il peut s'agir d'un message de type « DISCOVER » conforme au protocole DHCP selon le RFC 2131. Le serveur DHCPA transmet en réponse un message MD2 contenant une adresse IP que l'hôte peut utiliser pour communiquer avec le réseau d'accès NA. Le client protocolaire DHCPc peut alors transmettre un message MD3, utilisant cette adresse IP contenant un champ d'option spécifiant qu'il souhaite un identifiant d'un serveur distant. Ce champ d'option est une chaîne de caractères. Pour déployer l'invention dans un réseau public, ce champ d'option doit faire l'objet d'une demande de normalisation auprès de l'IANA. Cette chaîne peut par exemple être « HRP-FQDN- OPT » De façon connue en soi, il peut également inclure un champ d'option spécifiant qu'il souhaite un identifiant d'un serveur de noms DNS (Domain Name Server). Ce message peut être un message « REQUEST » conforme au RFC 2131. Le serveur de configuration dynamique DHCPA peut alors envoyer un message de réponse MD4. Ce message de réponse peut être un message « REPLY » conforme au RFC 2131. Il peut contenir un identifiant d'un serveur de noms de domaines DNS (par exemple, son adresse IP). Il peut également contenir un identifiant du serveur distant SA. Cet identifiant peut être l'adresse IP du serveur distant SA. Il peut alternativement être un identifiant logique FQDN (FuIIy Qualified Domain Name) conforme au RFC 1035 de l'IETF. Cet identifiant peut être contenu dans un champ d'option du message MD4 conforme au protocole DHCP. Ce champ peut être un champ « HRP FQDN Option » de ce message « REPLY ». Il peut comporter un identifiant du champ, une longueur et une valeur. Cette valeur peut être conforme aux recommandations du RFC 1035 de l'IETF, intitulé « Domain Names - Implementation and Specification » Si le serveur de configuration DHCPA n'est pas prévu pour gérer cette extension 14 selon l'invention, ou bien si aucune information n'est disponible pour cet hôte, il peut par exemple ne pas renvoyer de champ « HRP FQDN option » dans le message MD4, ou bien renvoyer un champ « HRP FQDN Option » avec une longueur nulle. Il est possible pour les hôtes H d'inclure un champ « HRP FQDN Option » dans des requêtes subséquentes au serveur de configuration DHCPA. Dans cette situation, celui-ci peut renvoyer la valeur, cette valeur pouvant éventuellement différer de la valeur initiale pour différentes raisons (reconfiguration du réseau d'accès NA etc.). A la réception de ce message MD4, le client protocolaire DHCPc peut adresser une requête MD5 à un serveur de noms de domaine DNSA (dont l'identifiant a pu être fourni par le serveur de configuration DHCPA préalablement) afin de résoudre l'identifiant FQDN reçu. De façon classique, le serveur de nom DNSA renvoie un message de réponse MD6 contenant l'adresse IP correspondant à cet identifiant FQDN. Le client protocolaire DHCPc peut transmettre l'adresse IP reçue au client protocolaire HRPc par un message MD7 interne à l'hôte de communication H. Le format de ce message interne dépend de l'architecture de l'hôte H et des interfaces de programmation API des différents clients protocolaires. Différentes mises en oeuvre sont possibles et aisément accessibles à l'homme du métier. Le client protocolaire HRPc peut alors transmettre une requête M1 au serveur distant SA, recevoir une réponse M2 et mettre à jour la mémoire P via un message de mise à jour U1, ainsi que cela a été expliqué pour la figure 3. Comme dit précédemment, les mêmes échanges peuvent avoir lieu pour le réseau d'accès NB. D'une façon générale, en Ipv4, le champ d'option « HRP FQDN », ou un équivalent, peut être inséré dans les messages DHCP, « Discover » et « Request » par un hôte de communication. Un serveur de configuration dynamique DHCP peut insérer un champ d'option « HRP FQDN » incluant une valeur représentative de l'identifiant du serveur distant (et une longueur de champ) dans des messages DHCP « Reply » adressés à l'hôte de communication H. En lpv6, un client peut insérer une option « OPTION_IA_HRP_FQDN » dans un 15 entête DHCPv6 Option Request Option, tel que défini par le RFC 3315 de l'IETF, dans les messages « Solicit », « Request », « Renew », « Rebind », « Information-Request » et « Reconfigure ». Le serveur de configuration dynamique DHCP peut insérer l'identifiant du serveur 5 distant dans un champ d'option spécifique qui contient un code d'option (devant être normalisé par l'IANA), une longueur de champ et une valeur, représentative de cet identifiant. 10 15 16 REVENDICATIONS1) Procédé d'émission de flots (FF, FH) composés de paquets de données par un hôte de communication (H) possédant un ensemble de points de sortie (pl, p2, p3) permettant l'émission desdits flots, lesdits flots étant acheminés vers l'un dudit ensemble de points de sortie en fonction d'informations de routage déterminées par des caractéristiques desdits flots, comportant en outre une étape d'interrogation d'un serveur distant (SA, SB) afin de recevoir au moins une partie desdites informations de routage. 2) Procédé selon la revendication précédente, comportant en outre une étape d'émission par ledit serveur distant d'un message de notification audit hôte de communication, ledit message de notification contenant des informations de routage et n'étant pas sollicité par ledit hôte de communication, et une étape de mise à jour par ledit hôte de communication de ses propres informations de routage en fonction des informations de routage contenues dans ledit message de notification. 3) Procédé selon l'une des revendications précédentes, comportant une étape préalable de détermination dudit serveur distant (SA, SB) déclenchée lors de la connexion dudit hôte de communication (H) au réseau d'accès associé audit serveur distant. 4) Procédé selon l'une des revendications précédentes, comportant une étape préalable de réception de l'identifiant dudit serveur distant (SA, SB) dans un message de réponse provenant d'un serveur de configuration dynamique (DHCPA, DHCPB). 5) Procédé selon la revendication précédente, dans lequel, suite à la réception dudit identifiant, ledit hôte de communication interroge un serveur de noms de domaines (DNSA, DNSB) pour résoudre ledit identifiant et obtenir une adresse IR 6) Hôte de communication (H) possédant un ensemble de points de sortie (P1, 17P2, P3) permettant l'émission de flots (FF, FH) composés de paquets de données, une mémoire (P) contenant des informations de routage et un dispositif de routage (R) pour acheminer lesdits flots vers l'un dudit ensemble de points de sortie en fonction d'informations de routage déterminées par des caractéristiques desdits flots, et un client protocolaire pour recevoir d'un serveur distant au moins une partie desdites informations de routage. 7) Hôte de communication selon la revendication précédente, prévu pour déterminer ledit serveur distant (SA, SB) lors de la connexion dudit hôte de lg communication (H) au réseau d'accès associé audit serveur distant. 8) Hôte de communication selon l'une des revendications 6 ou 7, prévu pour recevoir l'identifiant dudit serveur distant (SA, SB) dans un message de réponse provenant d'un serveur de configuration dynamique (DHCPA, DHCPB). 9) Hôte de communication selon la revendication précédente, prévu pour, à suite à la réception dudit identifiant, interroger un serveur de noms de domaines (DNSA, DNSB) pour résoudre ledit identifiant et obtenir une adresse IP. 20 10) Serveur (S) disposant d'une interface pour recevoir des requêtes provenant d'hôtes de communication, chaque requête contenant l'identifiant d'un point de sortie d'un desdits hôtes, et pour émettre une réponse audit hôte contenant des informations de routage relatives audit point de sortie et déterminées à partir d'une base de données associant des informations de routage à des identifiants de points de sorties. 15