PROCEDE ET DISPOSITIF DE SELECTION D'INTERFACE DE
COMMUNICATION
Domaine de l'invention
L'invention concerne le domaine des communications réseau et en particulier porte sur un procédé et un dispositif pour sélectionner une interface de communication pour le routage de données. Etat de la Technique
Avec le développement toujours plus poussé de l'électronique, des technologies de l'information et de la communication, la commercialisation d'appareils communicants équipés de plusieurs interfaces de communication différentes est courante. Par exemple, un ordinateur portable peut être connecté à l'Internet par une connexion filaire, de type Ethernet, et par une connexion sans fil (Wifi) simultanément. Un téléphone cellulaire est connecté à l'Internet à la fois par son antenne Wifi et par son antenne 3G. Lorsque l'utilisateur d'un tel équipement souhaite émettre des données, une interface de l'équipement est sélectionnée pour l'émission. Le choix peut se faire par exemple sur la première interface de la liste des interfaces existantes sur l'équipement. L'interface retenue dépend de la politique mise en place par le système d'exploitation installé sur l'équipement. Or l'interface sélectionnée peut conduire à une mauvaise exploitation des ressources du réseau, menant à une dégradation de la qualité du réseau, telle qu'une bande passante réduite, des délais de transmissions, des pertes de données.
Par ailleurs, un routage de données non optimal peut impliquer une retransmission des données et alors induire une augmentation de la
consommation d'énergie des équipements du réseau.
Des solutions pour permettre une sélection plus optimale d'une interface sur un hôte multi-interfaces existent. Ainsi, la demande de brevet WO 2010/097057 de Sarikaya et al. propose une méthode pour configurer un hôte multi-interfaces et sélectionner une interface en se basant sur des informations de routage contenues dans un message Dynamic Host Configuration Protocol (DHCP). Cependant, une telle approche se limite à une vision locale de l'hôte, et l'interface sélectionnée est celle qui propose la métrique la plus avantageuse du lien immédiat.
Dans la demande internationale de brevet WO 2012/087184 de Telefonaktiebolaget LM Ericsson intitulée « Energy Efficient Routing and Switching », une méthode pour réaliser un routage basé sur une métrique de consommation énergétique est présentée. Un routeur (premier nœud 211 ) doté de plusieurs interfaces est utilisé pour envoyer des messages de routage qui contiennent la vue du réseau telle que perçue par ce nœud, et écouter les messages des autres nœuds. Après avoir reçu tous les messages, le premier nœud calcule les meilleurs chemins en se basant sur la consommation énergétique, et les stocke dans une table de routage. Cette méthode opère selon des protocoles de routage tels que l'Open Shortest Path First (OSPF) ou l'IS-IS
(Intermediate System to Intermediate System). L'inconvénient d'une méthode est que son application est limitée au réseau cœur, les protocoles de routage dynamique comme l'OSPF n'étant pas applicables au bord d'un réseau, c'est-à-dire aux équipements portés par un utilisateur, comme un smartphone ou une tablette, ou à des ordinateurs « end Systems ».
Les solutions connues présentent aussi un inconvénient lié à la sécurité du routage des données dans le réseau. En effet, les échanges des protocoles de routage ne s'effectuent qu'entre des routeurs du réseau
qui sont sous le contrôle strict de l'opérateur de réseau. Les messages de routage étant généralement authentifiés pour éviter toute compromission des tables de routage des routeurs, tout nœud hôte ne peut pas participer directement au protocole de routage en prenant le risque de
compromettre la sécurité du routage dans le réseau de l'opérateur.
Par ailleurs, un réseau local tel un réseau domestique ou un réseau d'entreprise est généralement plus restreint en termes de ressources réseau qu'un réseau de cœur comme celui d'un Fournisseur d'Accès Internet (FAI), et l'optimisation du routage des données au sein d'un tel réseau local est donc plus critique.
Ainsi, les approches connues ne répondent pas à l'ensemble des besoins d'optimisation de routage des données. L'invention proposée permet de répondre à ces besoins.
Résumé de l'invention
Un objet de la présente invention est de proposer un procédé de sélection d'interface qui permet à un équipement utilisateur multi- interfaces de sélectionner l'interface d'émission la plus appropriée afin d'optimiser le routage de données au sein d'un réseau local.
Un autre objet de la présente invention est de proposer un procédé qui combine un protocole adapté aux équipements finaux, comme le protocole de découverte de voisinage - « Neighbor Discovery » en anglais - avec un protocole de cœur réseau, comme le protocole OSPF, en utilisant la même métrique de coûts.
Avantageusement, la métrique peut caractériser l'énergie des liens de communication, c'est-à-dire la quantité d'énergie correspondant à
l'émission d'un paquet de données sur le lien, mais peut aussi s'appuyer sur tout type de métriques associées aux liens du réseau telles que des métriques de qualité de service (bande passante, latence, taux de pertes de paquets) ou de sécurité (niveau de sécurité sur le lien).
Avantageusement la présente invention évite le portage sur un terminal final (ou « end System » en anglais) d'un protocole de routage coûteux, en termes de ressources de calcul et stockage. Avantageusement, l'invention ne présente pas de risque de sécurité quant à une compromission des tables de routage puisque son procédé ne nécessite pas que le nœud hôte multi-interfaces participe explicitement au protocole de routage. Avantageusement, la présente invention s'implémentera dans les contextes où des terminaux multi-interfaces doivent envoyer des données au sein d'un réseau. En particulier, elle trouvera avantage dans les domaines suivants :
les réseaux domestiques ;
- les réseaux d'entreprise ;
les systèmes cellulaires regroupant diverses technologies d'accès radio ;
les réseaux ad-hoc multi-sauts, principalement sans-fil, et en particulier ceux regroupant différents types de liens radio ou filaires;
- les réseaux véhiculaires.
Dans le contexte des réseaux ad-hoc, la présente invention permet à des terminaux multi-interfaces de communiquer efficacement au sein du réseau ad-hoc, c'est-à-dire de bénéficier d'un routage optimal du trafic sans avoir à exécuter localement le protocole de routage ad-hoc, comme le protocole OLSR (Optimized Link State Routing) par exemple.
Dans le contexte des réseaux véhiculaires, la présente invention peut s'appliquer à des tablettes, ainsi qu'à des routeurs mobiles multi- interfaces. Un routeur mobile multi-interfaces est compris comme une passerelle de communication embarquée dans un véhicule et interconnectant un ou plusieurs réseaux internes au véhicule à l'infrastructure externe via diverses interfaces réseaux.
Pour obtenir les résultats recherchés, un procédé, un dispositif et un produit programme d'ordinateur sont proposés.
En particulier, l'invention s'applique dans un réseau de communication constitué d'une pluralité de routeurs connectés par des liens de communication et comprenant au moins un hôte source équipé de plusieurs interfaces de communication pour émettre et recevoir des données, chaque interface étant connectée à un routeur du réseau de communication via un lien de communication ayant un coût de lien. Le procédé revendiqué pour sélectionner une interface de l'hôte source pour transmettre des données à un hôte de destination connecté au réseau de communication, comprend les étapes de:
- émettre depuis chaque interface de l'hôte source un message de
sollicitation (RS) vers le routeur auquel ladite interface est connectée, pour demander le coût de route vers l'hôte de destination ;
- recevoir sur l'interface correspondante de l'hôte source un message d'annonce (RA) du routeur auquel ladite interface est connectée donnant une valeur du coût de route depuis ledit routeur vers l'hôte de destination ;
- calculer à partir des valeurs reçues et de la valeur de coût de lien du lien correspondant, la valeur du coût de route total vers l'hôte de destination depuis l'hôte source pour chaque interface;
- comparer les valeurs de coût de route total obtenues ; et
- sélectionner l'interface correspondant à la valeur de coût de route total la plus basse.
Dans une variante, l'étape de réception de message d'annonce de coût de route (RA) comprend une étape pour vérifier si le message d'annonce (RA) reçu contient une option de coût de route, ou ignorer le message.
Dans une autre variante, une étape initiale permet de déterminer le coût de lien de chaque lien entre chaque interface de l'hôte source et le routeur auquel ladite interface est connectée et de sélectionner l'interface ayant le coût de lien le plus faible comme interface par défaut.
De manière préférentielle, un identifiant de l'interface sélectionnée est stocké dans une table de routage de l'hôte source.
Dans une variante d'implémentation, l'étape de sélection d'une interface par défaut consiste à recevoir sur chaque interface de l'hôte source un message d'annonce (RA) du routeur auquel ladite interface est connectée qui comprend une valeur de coût de lien calculée selon une métrique de calcul de coût de lien définie pour ledit réseau de
communication. Avantageusement, le protocole dudit réseau de
communication est le protocole IPv6, et l'étape de sélection d'une interface par défaut se fait selon un protocole de découverte de voisinage (ND).
Dans une autre variante d'implémentation, le coût de lien est calculé pour différentes métriques de routage et le message de
sollicitation (RS) contient une indication du ou des métriques pour lesquels calculer le coût de lien.
L'invention concerne de plus un système pour sélectionner une
interface de communication, le système comprenant des moyens pour mettre en œuvre toutes les étapes du procédé revendiqué.
L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer les étapes du procédé revendiqué lorsque le programme est exécuté sur un ordinateur.
Description des figures
Différents aspects et avantages de l'invention vont apparaître en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous :
La figure 1 montre schématiquement un hôte source connecté à plusieurs routeurs via différents liens dans un réseau de communication ;
Les figures 2a et 2b montrent les procédures exécutées par les routeurs et l'hôte source de la figure 1 pour la sélection d'une interface par défaut ; La figure 3 montre schématiquement un exemple de différentes routes entre un hôte source et un hôte destinataire ;
La figure 4 montre les échanges de messages intervenant pour la sélection d'une route dans l'exemple de la figure 3 ;
La figure 5 montre les procédures exécutées par un routeur dans l'exemple de la figure 3 ;
La figure 6 montre les procédures exécutées par l'hôte source dans l'exemple de la figure 3.
Description détaillée de l'invention
Pour permettre une bonne compréhension de la description, une terminologie des principaux termes utilisés est donnée ci-après :
Adresse IPv6 : Identifiant unique d'un nœud dans le réseau. L'adresse IPv6 est composée de deux parties : un préfixe en partie gauche et un identifiant d'interface en partie droite.
Coût du lien : Métrique associée au lien.
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) :
Protocole de configuration dynamique des hôtes d'un réseau. Il permet notamment d'attribuer une adresse IPv6 complète à un hôte.
Hôte : Equipement terminal d'un utilisateur qui possède au moins une interface de communication pour émettre/recevoir des données et qui ne permet pas le routage de données.
Identifiant d'Interface : Partie droite de l'adresse IPv6 d'un nœud qui permet de l'identifier sur un lien. L'Identifiant d'Interface doit être unique parmi tous les Identifiants d'Interface sur un même lien.
Lien : Connexion physique directe entre deux nœuds. La connexion peut être filaire (câble Ethernet, fibre optique, etc.) ou sans fil
(ondes radio : wifi, bluetooth, 3G, etc.).
Métrique : Valeur positive non nulle associée à un lien. Elle permet de décrire le lien et de le comparer aux autres liens du réseau. Des exemples de métriques d'un lien sont : le débit, le taux de pertes, le délai, le niveau de sécurité, l'énergie, etc. Un exemple particulier est la quantité d'énergie correspondant à l'émission d'un paquet IP sur ce lien. La métrique est utilisée par les protocoles de routage dans le calcul des meilleures routes : plus la métrique d'un lien est élevée, plus le lien en question sera évité car, en général, une métrique élevée traduit un lien de mauvaise qualité.
Maximum Transmission Unit (MTU) : Taille des données maximum incluses dans un paquet IPv6. Si la quantité de données à transmettre est supérieure à la MTU, les données doivent être
fragmentées en plusieurs paquets IPv6.
Neighbor Discovery (ND) : Protocole de routage à échelle du lien (aussi appelé routage « à un saut ») qui permet la configuration d'un hôte qui se connecte au réseau.
Nœud : Tout équipement IPv6 communicant (routeur ou hôte) connecté au réseau.
Préfixe : Partie gauche de l'adresse IPv6 d'un nœud qui permet d'identifier un lien spécifique dans le réseau. Le préfixe est la partie utilisée par les routeurs pour router le trafic vers une destination. Il doit être unique au sein du réseau et est partagé par les nœuds connectés à un même lien.
Router Advertisement (RA) : Message de signalisation du protocole ND émis par un routeur soit périodiquement et à destination de tous les nœuds présents sur le lien (communication multicast), soit en réponse à un RS émis par un nœud spécifique (communication unicast).
Routeur : Equipement communicant doté d'au moins deux interfaces de communication et dont le rôle est de router les paquets de données d'un nœud à un autre dans le réseau.
Router Solicitation (RS) : Message de signalisation du protocole ND émis par un hôte et à destination d'un ou de tous les routeurs présents sur le lien.
State Less Address Auto Configuration (SLAAC) : Mécanisme permettant à un hôte de générer localement la partie Identifiant d'Interface de son adresse IPv6 en se basant sur son adresse MAC. La configuration d'un hôte par SLAAC s'oppose généralement à la configuration par DHCPv6.
La figure 1 illustre un exemple d'infrastructure de communication réseau 100 dans laquelle implémenter avantageusement l'invention. Pour des raisons de simplicité de description et non de limitation de l'invention, l'exemple de la figure 1 ne montre qu'un nombre fini d'hôtes et de
routeurs, mais l'homme du métier étendra les principes décrits à une pluralité et une variété d'hôtes (102-i), de routeurs (104-i) et de nombre et type de liens de connexion.
Un hôte (102) est connecté par une première interface 11 (103) à un premier routeur (104-1 ) via un premier lien (106) et par une seconde interface 12 (105) à un second routeur (104-2) via un second lien (108). Chaque routeur peut lui-même être connecté sur d'autres nœuds du réseau via différents liens (110).
Pour être connecté au réseau, l'hôte (102) récupère auprès de chaque routeur présent sur le lien auquel il est connecté, les informations nécessaires à sa configuration telles qu'un préfixe IPv6, la sélection d'une route par défaut, son auto-configuration par SLAAC ou DHCPv6, ou encore la taille de la MTU. Chaque routeur fournit à l'hôte les paramètres nécessaires à sa configuration. Dans les réseaux IPv6, le protocole de découverte de voisinage (ND) se charge de cet échange d'informations par des messages de Sollicitation du Routeur (RS) ou « Router Solicitation » en anglais, et des messages d'Annonce du Routeur (RA), ou « Router Advertisement » en anglais. L'homme du métier pourra se référer à la « Request for
Comments » (RFC) 4861 pour une description plus détaillée sur le format et le contenu des messages (RS) et (RA) selon le protocole IPv6.
Les figures 2a et 2b montrent les procédures exécutées par les routeurs (104-1 , 104-2) et l'hôte source (102) de la figure 1 pour la sélection d'une interface par défaut sur l'hôte source.
Un routeur émet (202) un message d'annonce (RA) sur son lien vers l'hôte source. Selon le principe de l'invention, le message contient dans une nouvelle option le coût du lien. Dans une implémentation préférentielle, le coût du lien ou « Link Cost » en anglais, est inclus dans un champ de la nouvelle option du message (RA) comme un entier non
signé sur 32 bits, tel que montré schématiquement ci-après pour un message (RA) selon le protocole IPv6:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 Type I Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Link Cost I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La signification des champs est la suivante : Type : Code identifiant l'option. Entier non signé sur 8 bits.
Length : Longueur de l'option. Entier non signé sur 8 bits. Reserved : Champ non exploité, mis à zéro par l'émetteur. Link Cost: Coût du lien. Entier non signé sur 32 bits.
Le message d'annonce (RA) est envoyé périodiquement (204) sur le lien. Selon la RFC 4861 qui définit le protocole « ND », la période d'envoi des messages RA est arbitraire mais doit être au minimum de 3 secondes. La valeur de cette période d'envoi qui peut être configurée par un administrateur réseau n'a pas d'impact sur le fonctionnement de la présente invention.
La figure 2b montre les étapes opérées au niveau de l'hôte (102) pour lui permettre de sélectionner son interface par défaut d'après la métrique de routage utilisée dans le réseau. L'hôte reçoit (2002) un message d'annonce (RA) d'un routeur sur l'une de ses interfaces (I). Le
procédé vérifie (2004) si le message reçu contient une indication de coût de lien. S'il n'y a pas cette option dans le message reçu, le procédé attend la réception d'un nouveau message (branche NON).
Si le message d'annonce (RA) reçu contient une information de coût du lien (branche OUI), le procédé continue à l'étape suivante (2006) où il vérifie si une interface par défaut est assignée. Si aucune interface n'est assignée, le procédé sélectionne (2008) l'interface (I) en cours comme interface par défaut (ID). Cette information est stockée (2010) dans la table de routage de l'hôte.
Si une interface par défaut (ID) est déjà assignée (branche OUI), le procédé compare dans une étape suivante (2012) le coût du lien reçu sur l'interface (I) en cours au coût du lien sur l'interface par défaut (ID). Si le coût du lien de l'interface en cours est inférieur au coût du lien de l'interface par défaut (branche OUI), le procédé sélectionne (2008) l'interface en cours comme interface par défaut (ID) et met à jour sa table de routage (2010) en mémorisant un identifiant de l'interface sélectionnée.
Si le coût du lien de l'interface en cours est supérieur ou égal au coût du lien de l'interface par défaut (branche NON), le procédé conserve l'interface par défaut et attend un prochain message (RA).
Ainsi, à chaque réception d'un message (RA) contenant l'option de coût du lien sur une interface, l'hôte affecte le coût du lien annoncé dans le message à cette interface. Il définit ensuite son interface par défaut en sélectionnant celle dont le coût est le plus faible. Dans l'exemple de la figure 1 , les routeurs émettent des messages RA périodiques. Le premier routeur (104-1 ) émet sur le premier lien (106) un message d'annonce (RA1 ) qui inclue l'option de coût du lien, avec une valeur de coût de lien de « 5 ». Le second routeur (104-2) émet sur le second lien (108) un message d'annonce (RA2) qui inclue l'option de coût du lien, avec une
valeur de coût de lien de «3 ». Ces messages permettent à l'hôte (102) d'affecter la valeur de coût de lien « 5 » à son interface 11 (103) et la valeur de coût de lien « 3 » à son interface 12 (105). Le procédé implémenté permet que l'interface 12 soit sélectionnée comme interface par défaut car ayant le coût de lien le plus faible.
La figure 3 montre schématiquement un exemple de différentes routes possibles entre un hôte source (102) et un hôte destinataire (302). L'hôte destinataire (302) est connecté au premier routeur (104-1 ) par un lien (304) qui a un coût de lien de valeur « 2 ». Les éléments en commun avec la figure 1 conservent les mêmes références et ne sont pas décrits de nouveau. Dans l'exemple de la figure 3, il existe un lien (110) entre les deux routeurs (104-1 , 104-2) qui a un coût de valeur « 4 ». Bien que l'hôte source ait une interface par défaut sélectionnée selon la métrique de routage du réseau, l'utilisation systématique de celle-ci pour toutes ses communications peut ne pas être optimale sur un chemin de bout-en-bout emprunté par les données. En effet, l'hôte étant connecté sur différents liens du réseau grâce à ses différentes interfaces, l'utilisation de son interface par défaut pour certaines communications peut engendrer des « détours » en fonction de l'emplacement du nœud destination dans le réseau et donc engendrer des coûts supplémentaires. Afin que l'hôte source soit en mesure de sélectionner une interface pour une communication optimale vers un hôte destinataire, le procédé de l'invention permet de donner à l'hôte source une vision plus globale du chemin de bout-en-bout vers la destination en lui permettant de comparer le coût de chaque route possible vers l'hôte destinataire et de sélectionner la meilleure route.
La figure 4 montre les échanges de messages intervenant entre les différentes entités de la figure 3 pour la sélection d'une route. Dans une étape préliminaire, l'hôte source (H1 ) reçoit sur chacune de ses interfaces
(11 , I2) des messages d'annonce (RA1 , RA2) respectivement des routeurs connectés (R1, R2) contenant les valeurs correspondantes de coût du lien. L'hôte source sélectionne son interface par défaut selon le procédé de la figure 2b.
Lorsque l'hôte source (H1) souhaite émettre des données vers une destination (H2), si aucune entrée vers cette destination n'existe dans sa table de routage, il émet une requête (RS1, RS2) sur chacune de ses interfaces pour demander aux routeurs respectifs le coût du chemin de bout-en-bout vers la destination (H2).
Les routeurs répondent en envoyant chacun un message d'annonce (RA11, RA12) annonçant respectivement le coût du chemin le plus court à leur connaissance pour atteindre ladite destination.
De plus, les messages de réponse à la requête de coût de route contiennent de manière préférentielle :
- soit l'adresse IPv6 de la destination si la politique de routage mise en œuvre est de type routage basé sur l'adresse de l'hôte ou « host- based routing » ;
- soit le préfixe et sa taille correspondant à l'adresse destination si la politique de routage mise en œuvre est de type routage classique basé sur les préfixes ou « network-based routing ».
Les messages d'annonce de coût contiennent de manière préférentielle l'indication de coût de route ou « Path Cost » en anglais, selon le format représenté schématiquement ci-après : 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Type I Length | Transaction I D | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Reserved I Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+
I I I Destination | I Address or Prefix I
I I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Path Cost I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Lifetime I
La signification des champs est la suivante :
Code identifiant l'option. Entier non signé sur 8 bits.
Length Longueur de l'option. Entier non signé sur 8 bits.
Transaction ID Numéro identifiant l'échange de messages RS/RA entre hôte et routeur. Entier non signé sur 8 bits. L'option contenue dans un message RA envoyé en réponse à un message RS doit contenir le même numéro de transaction que celui contenu dans l'option du message RS.
Status Code Code qui donne des informations complémentaires à la réponse tel que « adresse destination demandée inaccessible », « transaction réussie ». Entier non signé sur 8 bits. Mis à zéro dans un message RS.
Reserved Champ non exploité, mis à zéro par l'émetteur et ignoré par le récepteur.
Prefix Length Entier non signé sur 8 bits. Dans un message RA, contient la longueur du préfixe du champ Destination Ad- dress/Prefix. Mis à zéro dans un message RS.
Destination Dans un message RS : adresse IPv6 de la destination Address or
pour laquelle le coût du chemin est demandé. Dans un Prefix
message RA : adresse IPv6 de la destination ou bien préfixe correspondant à cette destination selon la politique de routage mise en œuvre (« host-based routing » ou « network-based routing »).
Path Cost Coût du chemin de bout-en-bout depuis le routeur qui émet le message RA jusqu'à la destination. Entier non signé sur 32 bits. Mis à zéro dans un message RS.
Lifetime Durée de validité en secondes de l'information annoncée dans le RA. Mis à zéro dans un message RS.
Revenant à la figure 4, quand tous les messages de réponse de coût de route (RA11 , RA21 ) sont reçus par l'hôte source (H1 ), celui-ci exécute le procédé qui est décrit plus loin en référence à la figure 6 pour sélectionner l'interface correspondant à la route choisie pour l'envoi des données entre l'hôte source (H1 ) et l'hôte destinataire (H2).
La figure 5 montre les procédures exécutées par un routeur pour annoncer le coût d'une route vers une destination (D) requise par un hôte source.
A réception (502) d'un message de Sollicitation du Routeur (RS) envoyée par un hôte source, le procédé vérifie à l'étape (504) si l'option d'indication de coût de route est activée. Si l'option n'est pas activée (branche NON) le procédé attend la réception d'un nouveau message de sollicitation. Si l'option d'indication de coût de route est activée (branche OUI), le procédé poursuit à l'étape suivante (506) pour vérifier s'il existe une route enregistrée dans la table de routage du routeur pour la
destination requise. S'il n'existe pas de route enregistrée (branche NON), un message (RA) est envoyé à l'hôte source à l'étape (508) indiquant dans le champ « Status Code » qu'il n'existe pas de route. Le champ « Path Cost » est mis à zéro.
S'il existe une route enregistrée vers la destination requise
(branche OUI), le procédé passe à l'étape suivante (510) où un message de réponse (RA) est envoyé à l'hôte source indiquant la valeur du coût de la route dans le champ « Path Cost ». Puis le procédé s'arrête. La figure 6 montre les procédures exécutées par un hôte source pour sélectionner une route pour l'envoi de données vers un hôte destinataire.
Le procédé débute quand un hôte source doit envoyer des données vers un hôte destinataire (D). L'hôte source génère (étape 602) un message de sollicitation (RSi) de coût de route pour la destination requise depuis chacune de ses interfaces.
A réception (604) d'un message d'annonce (RA1 ou RA2 de la figure 4) sur une interface, le procédé vérifie (étape 606) si l'option de coût de route est activée dans le message. Si l'option n'est pas activée (branche NON), le procédé reprend au début. Si l'option est activée (branche OUI), le procédé passe à l'étape suivante (608) où il vérifie si un identifiant (ID) d'une autre interface est déjà enregistré dans la table de routage de l'hôte source pour la destination requise. Si aucune interface n'est sélectionnée (branche NON), le procédé alloue l'interface de réception du message pour la destination requise (étape 610) et procède à la mise à jour de la table de routage de l'hôte (étape 612) en mémorisant un identifiant pour l'interface allouée.
A l'étape 608, si une interface (ID) est déjà allouée (branche OUI), le procédé calcule (étape 614) le coût de route total pour transmettre les données via l'interface de réception du message d'annonce en prenant en compte le coût de lien du lien correspondant du routeur. Puis, le procédé
compare (étape 616) le coût de route total via l'interface de réception du message d'annonce (RA), au coût de route total via l'interface (ID) enregistrée.
Si le coût de route total calculé est inférieur au coût de route total via l'interface (ID) déjà enregistrée (branche OUI), le procédé sélectionne la nouvelle interface (étape 610) pour l'envoi de données vers la destination requise et met à jour sa table de routage (étape 612), sinon (branche NON), le procédé maintient l'interface (ID) allouée et s'arrête.
Ainsi sur l'exemple de la figure 3, l'hôte émetteur (102) qui doit envoyer des données à l'hôte destinataire (302) alors qu'il ne possède pas de route spécifique à destination de cet hôte dans sa table de routage, émet un message de sollicitation (RS) contenant l'option de coût de la route à destination de l'hôte (302), sur chacune de ses interfaces (103, 105). Chaque routeur lui répond par un message d'annonce (RA) contenant le coût du meilleur chemin dont il dispose pour atteindre l'hôte destinataire (302). Le premier routeur (104-1 ) répond avec un coût de lien de valeur « 2 » via le lien 304, tandis que le second routeur (104-2) répond avec un coût de lien de valeur totale « 6 » via les liens (110) et (304). L'hôte source a déjà connaissance du coût des premier et second liens (106) et (108) par les routeurs. Il calcule alors le coût total pour atteindre l'hôte destinataire. Dans l'exemple choisi, la route depuis la premier interface (103) via le premier routeur (104-1 ) revient à un coût de route total de valeur « 7 » et la route depuis la seconde interface (105) via le second routeur (104-2) revient à un coût de route total de valeur « 9 ». La première interface (103) est sélectionnée par l'hôte source pour émettre les données à destination de l'hôte destinataire (302). Cette information est mémorisée comme une nouvelle entrée dans la table de routage de l'hôte source.
Selon la politique de routage mise en place, soit l'identité de l'hôte destinataire est enregistrée s'il s'agit d'une politique de type « Host-based routing », soit l'identifiant de lien vers l'hôte destinataire est enregistré s'il
s'agit d'une politique de type « Network-based routing ».
L'homme de l'art appréciera que des variations peuvent être apportées sur la méthode telle que décrite de manière préférentielle et sur un exemple non limitatif, tout en maintenant les principes de l'invention. Ainsi, les exemples décrits sont basés sur une sélection de route selon une métrique/coût non précisé, et il est possible d'appliquer les mêmes principes sur différents métriques. De même, l'exemple choisi est basé sur le protocole IPv6, mais les mêmes principes restent applicables au protocole IPv4.
Dans une variante d'implémentation avec choix de routage multi- métrique, les routeurs possèdent différentes tables de routage, chacune d'elles étant associée à un métrique/coût différent, comme par exemple la bande passante, la latence, le taux de perte des paquets, le niveau de sécurité du lien, l'énergie de transmission d'un paquet sur le lien, pour n'en citer que quelques uns. Dans cette variante, le routage multi- métrique peut par exemple être réalisé en utilisant plusieurs instances ayant des métriques différentes, sur un même protocole de routage (par exemple OSPF, IS-IS) ou sur des protocoles de routage différents dans un même réseau.
Pour cette variante, dans l'étape d'annonce du coût du lien et de la sélection d'interface par défaut (figures 2a, 2b), les messages (RA) envoyés par les routeurs, incluent les coûts associés à plusieurs métriques ou à toutes les métriques de routage utilisées dans le réseau. Dans le cas ou plusieurs métriques sont annoncées dans un message (RA), le message contient pour chacune d'elle un identifiant de métrique et un coût de lien associé à cette métrique. Sur la base des messages reçus, le nœud hôte multi-interface peut ainsi configurer dans sa table de routage locale une route par défaut pour chacune des métriques de
routage.
Le format de l'option d'annonce de coût multi-métrique d'un message (RA) est illustré schématiquement ci-dessous, où les champs « Metric ID i» représentent l'identifiant de la métrique T considérée et les champs « Link Cost i » représentent le coût du lien associé à la métrique T.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Type I Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Reserved I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Metric ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Link Cost 1 I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I ... I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Metric ID i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Link Cost i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L'étape de découverte du coût des routes (figures 5 et 6) englobe la possibilité pour le nœud hôte multi-interfaces de préciser dans le message (RS) à destination de ses routeurs voisins la ou les métriques qu'il souhaite prendre en compte pour la détermination du coût de la route de bout-en-bout vers une destination donnée, en indiquant le/les identifiant(s) des métriques dans le message (RS). Les routeurs voisins répondent en indiquant dans leurs messages (RA) les identifiants des métriques associés aux coûts des routes vers la destination selon chacune des métriques demandées. Sur la base des messages reçus, le nœud hôte multi-interfaces peut configurer dans sa table de routage locale une route optimale vers une destination donnée pour une ou
plusieurs métriques de routage spécifiques.
Le format de l'option d'annonce de coût de route multi-métrique d'un message est illustré schématiquement ci-dessous : 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Type I Length | Transaction ID | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I Reserved I Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I I I Destination |
I Address or Prefix I i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Metric ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Path Cost 1 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Lifetime 1 I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Traffic Tag 1 I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i . . . I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Metric ID i |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Path Cost i I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I Lifetime i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ I Traffic Tag i I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les champs « Metric I D i» représentent l'identifiant de la métrique Ί' considérée et les champs « Path Cost i » représentent le coût de la route associé à la métrique Ί', les champs « Lifetime i » représentent la durée de validité en secondes de l'information annoncée dans le message (RA) et les champs « Traffic Tag i » représentent le marquage de trafic à appliquer aux paquets de données devant être routées selon la métrique T associée. Cette information permet au nœud hôte de savoir quel marquage appliquer à ses paquets de données pour bénéficier d'un routage selon une métrique particulière. Les standards I Pv4 et I Pv6
définissent des champs dédiés au marquage des paquets. Ceux-ci se situent dans l'en-tête IP des paquets sur les champs « Differentiated Services Code Point (DSCP) » pour IPv4 et « Traffic Class » et « Flow Label » pour IPv6.
L'homme de l'art appréciera qu'une autre solution de marquage de paquets peut également être envisagée en IPv6 uniquement, celle de l'utilisation d'une extension d'en-tête IP.
La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD- ROM), Compact Disk - Read/Write (CD-R/W) and DVD).