FR2973977A1 - Procede et dispositif d'optimisation du routage d'un flux - Google Patents

Abstract

L'invention concerne un procédé d'optimisation du routage d'un flux échangé entre deux nœuds dans un réseau de télécommunications d'un opérateur. Ce procédé comporte une étape consistant à re-router ledit flux via au moins un serveur intermédiaire agencé entre lesdits nœuds apte à appliquer audit flux au moins un traitement prédéfini par l'opérateur.

Description

Procédé et dispositif d'optimisation du routage d'un flux DOMAINE TECHNIQUE L'invention se situe dans le domaine des réseaux de télécommunication et concerne plus particulièrement un procédé et un dispositif d'optimisation du routage d'un flux échangé entre deux noeuds dans le réseau d'un opérateur. L'invention s'applique particulièrement mais non exclusivement dans un domaine Proxy Mobile IPv6 (PMIPv6) et/ou Mobile IPv4/NEMOv4 et/ou Mobile IPv6/NEMOv6. ÉTAT DE LA TECHNIQUE ANTÉRIEURE Dans un réseau de télécommunication tel que l'Internet, un protocole de gestion de mobilité a pour but de gérer le déplacement des équipements mobiles et d'éviter que leurs communications ne soient perdues quand ils changent de point d'accès au réseau. En effet, sans protocole de gestion de mobilité, l'adresse IPv6 (l'identifiant Internet) d'un client est susceptible de changer à chaque (re)-connexion au réseau; une communication étant définie explicitement par une interface logicielle, appelée socket en anglais, figée entre deux adresses IPv6, toute communication sera donc perdue si une des adresses change. L'IETF (Internet Engineering Task Force) spécifie le protocole de gestion de mobilité PMIPv6 (pour Proxy Mobile IPv6) selon lequel toute la gestion de la mobilité des clients se fait uniquement par le réseau. La gestion est donc transparente pour les clients. D'autres protocoles tels que MIPv6 (pour Mobile IPv6) nécessitent une participation active des clients consistant par exemple à échanger des messages de signalisation avec les entités composant le protocole de gestion de mobilité. Dans le reste de ce document, nous utiliserons le terme noeud pour désigner un équipement d'un client qui se connecte au réseau tel que par exemple un ordinateur portable, un téléphone, ou tout équipement susceptible de communiquer via le réseau. La figure 1 illustre schématiquement une architecture permettant de gérer la mobilité des noeuds 4 et 6 dans un réseau utilisant le protocole PMIPv6. Dans cette architecture, quand les noeuds 4 et 6 se connectent au réseau, ils se retrouvent associés, respectivement, à un routeur IP d'accès appelé MAG 8 (pour Mobile Access Gateway en anglais) et à un routeur IP d'accès appelé MAG 10. Les MAG 8 et 10 et tous les autres MAGs auxquels les noeuds 4 et 6 se connecteront pendant une session, émulerons toujours le même accès (même adresse IP, même message de signalisation, etc.) afin de rendre transparent toute changement d'association au niveau IP. A cet effet, chaque MAG 8 et 10 enregistre la position du noeud qui lui est associé par l'envoi d'un message PBU (pour proxy binding update, en anglais) à une entité centrale appelée LMA (pour Local Mobility Anchor, an anglais) 12. Cette entité centrale transmet en retour un message PBA (pour proxy binding acknowledgment, en anglais) au MAG 8 (respectivement 10) pour valider la prise en charge de ce noeud et lui assigner une adresse IPv6 qui restera valide tant que la session de communication restera active. Toutes les communications de et vers ce noeud transitent alors par un tunnel bidirectionnel respectivement 14, 16 que le LMA 12 et le MAG 8 (respectivement 10) établissent entre eux. Du fait que dans cette architecture toutes communications dans le domaine PMIPv6 transitent par le LMA 12, il peut arriver que le(s) flux entre deux noeuds proches subissent un détour important en passant par un LMA distant. Il est donc souhaitable d'optimiser le routage du trafic entre les noeuds. Le document "Localized Routing for Proxy Mobile IPv6, draft-ietf-netext-pmip-lr-01 Octobre 2010" décrit un ensemble de procédures permettant l'optimisation du routage en établissant un tunnel direct entre les MAGs des noeuds. Avec ce type d'approche, les flux échangés entres les noeuds ne passent plus par le LMA 12. Il devient alors difficile de fournir aux noeuds des services personnalisés à fortes valeurs ajoutées tel que la qualité de service ou de mettre en place des services propres à l'opérateur qui nécessite l'accès au flux (ex. interception légale, inspection de trafic et vérification de sa conformité au contrat, etc.) car ces services de traitements sont localisés dans le LMA. De ce fait, l'opérateur perd globalement en flexibilité. Le document "Internet Protocol, DARPA Internet Program Protocol Specification." RFC791. Septembre 1981 décrit la méthode de « source routing » qui est une technique développée dans la spécification d'IPv4, ainsi que dans la spécification d'IPv6 à travers le routing header (de type 0) décrit dans le document "Internet Protocol, Version 6 (IPv6) Specification." RFC2460, Décembre 1998. Cette méthode permet à un noeud source de définir partiellement ou totalement une séquence de routeurs qu'un flux doit traverser pour atteindre un noeud destination. Un inconvénient majeur de cette méthode provient du fait que les flux échangés ne sont pas sécurisés dans la mesure où la définition de la séquence de routeurs n'est pas contrôlée par l'opérateur. Un but de l'invention est de pallier les inconvénients de l'art antérieur décrit ci-dessus. EXPOSÉ DE L'INVENTION Les buts de l'invention sont atteints au moyen d'un mécanisme permettant de forcer le passage d'un flux de données par un ou plusieurs serveurs intermédiaire(s) quand une procédure d'optimisation de routage est déclenchée, notamment, dans un réseau utilisant le protocole Proxy Mobile IPv6 et/ou le protocole Mobile IPv4/NEMOv4 et/ou le protocole Mobile IPv6/NEMOv6.

Ceci est obtenu par un procédé d'optimisation du routage d'un flux échangé entre deux noeuds dans un réseau de télécommunications d'un opérateur comportant une étape consistant à re-router ledit flux via un ou plusieurs serveurs intermédiaires configurés pour appliquer audit flux au moins un traitement prédéfini par l'opérateur.

Le procédé selon l'invention permet à l'opérateur d'avoir une maîtrise sur les trafics. Il peut ainsi choisir de dérouter un trafic dans une zone du réseau moins surchargée et/ou y appliquer des traitements spécifiques (ex. filtrage, écoute, réservation de ressources, tarification). Selon un mode préféré de réalisation, ledit traitement prédéfini comporte au moins l'une des fonctions suivantes: - filtrer les contenus du flux, - appliquer une tarification aux différentes composantes du flux, - mesurer la bande passante consommée, - fournir une qualité de service différenciée en fonction du client ou du type de flux. - Analyser les contenus des flux (par exemple pour des écoutes légales). Le procédé selon l'invention comporte une phase de sélection, par l'opérateur, des traitements à appliquer au flux et d'un ou de plusieurs serveurs intermédiaires aptes à appliquer lesdits traitements, et une phase de configuration du routage optimisé pour ce flux en fonction des traitements prédéfinis. Un serveur intermédiaire peut être un simple routeur, un MAG, un serveur, un proxy, ou toute autre entité susceptible de détourner un trafic et/ou d'appliquer un traitement spécifique à un flux. Notons que le flux peut-être re-routé à travers plusieurs serveurs intermédiaires en cascade.

Dans ce cas, l'un de ces serveurs peut être un LMA.

Dans le procédé selon l'invention, la configuration du routage consiste à créer sur chaque serveur intermédiaire les entrées et sorties d'au moins un tunnel en envoyant à chaque serveur intermédiaire un message de signalisation comportant des informations sur les adresses IP des noeuds, le ou les préfixes des noeuds source et destination, les identifiants desdits noeuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant En outre, lors d'une connexion au réseau, chaque noeud se connecte à un routeur d'accès relié à une entité centrale adaptée pour définir, pour chaque routeur d'accès, une table de routage optimisée en fonction des traitements prédéfinis par l'opérateur dans chaque serveur intermédiaire. Dans une première variante, le procédé selon l'invention s'applique dans un réseau de type IP à des routeurs d'accès fixes. Dans une deuxième variante, le procédé 20 selon l'invention s'applique dans un réseau de type IP à des routeurs d'accès mobiles. Dans les deux variantes, l'entité centrale crée les entrées et sorties des tunnels sur chaque serveur intermédiaire en envoyant à chaque serveur 25 intermédiaire un message de signalisation comportant des informations sur les adresses IP des noeuds, le ou les préfixes des noeuds source et destination, les identifiants desdits noeuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP 30 du serveur suivant. Ladite entité centrale retransmet ledit message de signalisation si aucune réponse n'est reçue pendant un temps d'attente prédéfini. Le procédé selon l'invention est mis en oeuvre par un dispositif comportant des moyens pour re- router ledit flux via un ou plusieurs serveurs intermédiaires configurés pour appliquer audit flux au moins un traitement prédéfini par l'opérateur, et dans lequel chaque serveur intermédiaire comporte au moins un module réalisant au moins l'un des fonctions suivantes données à titre d'exemple non limitatif: - filtrage des contenus du flux, - application d'une tarification aux différentes composantes du flux, - mesure de la bande passante consommée, - fourniture d'une qualité de service différenciée en fonction du client ou du type de flux. - Analyser les contenus des flux (p.ex. écoute légale). Ce dispositif comporte en outre une entité centrale apte à créer sur chaque serveur intermédiaire les entrées et sorties d'au moins un tunnel en envoyant à chaque serveur intermédiaire un message de signalisation comportant des informations sur les adresses IP des noeuds, le ou les préfixes des noeuds source et destination, les identifiants desdits noeuds source et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant. Les étapes du procédé selon l'invention sont réalisées par les instructions d'un programme d'ordinateur enregistré sur un support de stockage lorsqu'il est exécuté sur un ordinateur.

BRÈVE DESCRIPTION DES DESSINS D'autres caractéristiques et avantages de l'invention ressortiront de la description qui va suivre, prise à titre d'exemple non limitatif, en référence aux figures annexées dans lesquelles : - la figure 1, décrite précédemment, illustre schématiquement une architecture permettant de gérer la mobilité de deux noeuds dans un réseau utilisant le protocole PMIPv6, - la figure 2 représente illustre une première variante de réalisation de l'invention dans un domaine PMIPv6, - la figure 3 illustre schématiquement une deuxième variante de réalisation de l'invention dans un domaine PMIPv6, - la figure 4 illustre schématiquement une troisième variante de réalisation de l'invention dans un domaine PMIPv6, - la figure 5 illustre schématiquement une quatrième variante de réalisation de l'invention dans un domaine Mobile IPv4/NEMOv4 ou Mobile IPv6/NEMOv6, - la figure 6 illustre la procédure de configuration du routage, selon l'invention, d'un flux échangé, via deux serveurs intermédiaires entre deux noeuds, - la figure 7 représente la mise à jour de tunnels établis entre les noeuds lors de la procédure de configuration du routage de la figure 6, - la figure 8 illustre schématiquement un mode de réalisation de l'invention dans le cas où les noeuds qui échangent le flux de données sont attachés des LMA différents - la figure 9 illustre les échanges de messages entre les différents éléments de la figure 8 pour réaliser un routage optimisé, - la figure 10 illustre schématiquement le format d'un message LRI, - la figure 11 illustre un exemple d'organisation des options, selon l'invention, pour déterminer comment créer ses deux tunnels, - la figure 12 illustre schématiquement le format d'un message LRA, la figure 13 illustre les étapes pour l'optimisation de routage entre deux routeurs mobiles NEMOv6. EXPOSE DETAILLE DE MODES DE REALISATION PARTICULIERS L'invention sera décrite, par références aux figures 2-8 pour optimiser le routage d'un flux de données multimédia échangé, via un réseau utilisant le protocole PMIPv6, entre un noeud source et un noeud destination. Dans la suite de cette description, les éléments communs aux différentes figures seront désignés par des références identiques. La figure 2 illustre une première variante de réalisation de l'invention dans un domaine PMIPv6 dans laquelle deux noeuds topologiquement proche, soit un noeud source 4 et un noeud destination 6 sont associés, respectivement, à un MAG 8 et à un MAG 10 lors d'une session IP. Dans ce cas, un premier tunnel 20 est établi entre le MAG 8 du noeud source 4 et un serveur intermédiaire 22 et un deuxième tunnel 24 établi entre ce serveur intermédiaire 22 et le MAG 10 du noeud destination 6. Le serveur intermédiaire 22 est configuré pour appliquer aux flux échangés entre les noeuds 4 et 6 un ensemble de services prédéfinis dictés par des exigences, par exemple légales et/ou économiques, ou autres. Ainsi par exemple, le serveur intermédiaire 22 comporte un premier module 25 qui est destiné à appliquer un certain niveau de qualité de service, un deuxième module 26 destiné à appliquer un filtrage du trafic afin de bloquer tout contenu répréhensible, et un troisième module 27 destiné à dupliquer le flux afin de procéder à une écoute de communications vocales par exemple. La figure 3 illustre schématiquement une deuxième variante de réalisation de l'invention dans un domaine PMIPv6 dans laquelle les premier, deuxième et troisième modules 25, 26, 27 ne sont pas hébergés sur le même serveur intermédiaire. Dans ce cas, le premier module 25 est hébergé sur un premier serveur intermédiaire 30, le deuxième module 26 est hébergé sur un deuxième serveur intermédiaire 31, et le troisième module 27 est hébergé sur un troisième serveur intermédiaire 32. Pour que chaque module puisse appliquer son traitement sur le flux, quatre tunnels 33, 34, 35 et 36 sont établis sur le chemin que doit parcourir ce flux respectivement entre le MAG 8 et le premier serveur intermédiaire 30, le premier serveur intermédiaire 30 et le deuxième serveur intermédiaire 31, le deuxième serveur intermédiaire 31 et le troisième serveur intermédiaire 32, le troisième serveur intermédiaire 32 et le MAG 10. Notons que dans cette variante, l'un au moins des serveurs intermédiaires 30, 31 et 32 peut être un LMA. Bien entendu, le flux peut être re-routé vers un ou plusieurs serveurs intermédiaires pouvant fournir un même service ou plusieurs services différents. La figure 4 illustre schématiquement une troisième variante de réalisation de l'invention dans un domaine PMIPv6 dans laquelle les noeuds se connectent à travers des femtocells ou routeurs résidentiels Wi-Fi. Une femtocell est un point d'accès fournissant une connectivité cellulaire d'une portée très limité (un appartement, un étage de bureau, etc.) et qui envoi le trafic à l'opérateur propriétaire de la femtocell à travers une connexion Internet. Le chemin emprunté par les données entre une femtocell et l'opérateur cellulaire propriétaire peut traverser une série de réseaux appartenant à d'autres opérateurs. Dans une autre variante de réalisation de l'invention illustrée par la figure 4, on considère une femtocell comme une combinaison d'un point d'accès cellulaire et d'un MAG. Dans ce cas, un routage optimisé entre deux femtocells peut dans certaines situations ne pas passer par le réseau de l'opérateur.

Dans ce scénario, l'opérateur propriétaire des femtocells installe un serveur intermédiaire dans le réseau d'un autre opérateur proche des noeuds. Le trafic entre deux noeuds peut alors être re-routé par ce serveur intermédiaire.

Ainsi en référence à la figure 4, deux noeuds 4 et 6 attaché respectivement à deux femtocell 40 et 42 d'un opérateur A échangent un flux multimédia. Afin d'optimiser le routage du flux échangé entre ces noeuds, le flux est re-routé de la femtocell 40 à travers un premier tunnel 46 vers un serveur intermédiaire 44 hébergé dans le réseau d'un opérateur B, puis transmis du serveur intermédiaire 44 vers la deuxième femtocell 42 à travers un deuxième tunnel 48. Ainsi, le flux ne passe pas par le LMA 12, l'opérateur A peut alors lui appliquer les traitements programmés dans le serveur intermédiaire 44. La figure 5 illustre schématiquement une quatrième variante de réalisation de l'invention dans un domaine Mobile IPv4/NEMOv4 ou Mobile IPv6/NEMOv6 dans laquelle les noeuds 4 et 6 se connectent à travers un serveur intermédiaire 58 utilisé comme point de passage pour le trafic direct entre deux routeurs mobiles 52 et 54. Rappelons qu'un routeur mobile est un équipement doté de plusieurs interfaces réseaux qui se déplace avec un ensemble d'autres équipements et gère la mobilité de cet ensemble d'équipements. Ces derniers ne sont pas affectés par les événements de mobilité. C'est le cas par exemple d'un routeur mobile installé sur un train qui se connecte à Internet avec une interface LTE (Long Term Evolution), et qui offre accès au réseau aux équipements des passagers par son interface WiFi ; les équipements des passager n'implémentant pas de protocole de mobilité. En référence à la figure 5, un HA (pour Home Agent) 56 remplit pour les routeurs 52, 54 la fonction du LMA 12 pour les MAG 8 et 10. Partant de cette analogie, le trafic entre les deux Routeurs Mobiles 52 et 54 peut être re-routé à travers un ou plusieurs serveurs intermédiaires et éviter ainsi le passage par le Home Agent 56. Ceci peut offrir au flux une route plus courte que le passage par le HA 56. En outre, même si ce n'est pas le chemin le plus court, c'est-à-dire, le chemin direct entre les routeurs 52 et 54, le passage par le serveurs intermédiaires 58 à l'avantage d'offrir à l'opérateur du réseau la possibilité d'augmenter les services offerts en appliquant au flux les traitements programmés dans ce serveur intermédiaire 56. Dans les différentes variantes de réalisation de l'invention, l'application de la procédure d'optimisation selon l'invention comporte les trois phases suivantes . - Détection de la nécessité d'optimiser le routage pour un flux de données, - Sélection des services à appliquer au flux et des serveurs associés par lesquels il faut faire transiter le flux pour réaliser un routage optimisé, - Configuration du routage optimisé pour ce flux. Une détection de la nécessité d'optimiser le routage résulte, par exemple, du fait qu'un LMA ou un HA d'un noeud destinataire reçoit un premier paquet de donnée indiquant l'établissement d'une communication. L'opérateur peut également configurer le routage optimisé seulement si le ou les noeuds ne seront pas mobiles pendant un certain temps en utilisant un algorithme de prédiction.

L'operateur peut aussi décider de permettre le routage optimisé seulement pour un certain type de trafic, en encore seulement après un certain laps de temps.

Notons que quel que soit l'élément déclencheur du processus d'optimisation du routage, l'opérateur peut modifier ou désactiver un chemin optimisé à tout moment. L'opérateur doit indiquer à la configuration du LMA ou de manière dynamique une liste de serveurs intermédiaires, leurs adresses IPv6 et les services fournies par chacun d'eux. Ces serveurs doivent être authentifiés par le LMA. La liste des services à appliquer à un flux, et donc la liste de serveurs intermédiaires à traverser peut dépendre du choix de l'opérateur et/ou des options souscrites par chaque client. La phase de configuration du routage optimisé sera maintenant décrite en référence aux figues 6-9.

La première étape de cette phase consiste à créer les entrées et sorties des tunnels sur chaque serveur intermédiaire avec comme paramètres des informations sur les adresses IPv6 des noeuds. Pour cela, le LMA ou le HA va initier la création d'un tunnel en envoyant à chaque serveur intermédiaire un message de signalisation « localized routing initiation » ou LRI. Un message LRI indiquera le ou les préfixes des noeuds source et destination, leurs identifiants ainsi que l'adresse IPv6 du serveur précédent et l'adresse IPv6 du serveur suivant (MAG ou serveur intermédiaire), et éventuellement les préfix des noeuds servis par des routeurs mobiles. Chaque serveur intermédiaire retourne un message de validation « localized routing acknowledgment » ou LRA. La figure 6 illustre la procédure de configuration du routage d'un flux échangé, via deux serveurs intermédiaires 60, 62, entre le noeud source 4 et le noeud source 6 associés respectivement au premier MAG 8 et au deuxième MAG 10 lors d'une session dans un réseau comportant le LMA 12.

Les étapes 62 à 68 illustrent les échanges des données avant l'optimisation du routage. A l'étape 62, le noeud source 4 transmet le flux au MAG 8 auquel il est associé pendant la session. A l'étape 64, le MAG 8 transmet le flux au LMA 12. Ce dernier transmet ledit flux au MAG 10 qui l'envoie au noeud destination 6. Les étapes 70 à 84 illustrent la phase de configuration du routage optimisé selon l'invention. A l'étape 70, le LMA 12 transmet au serveur intermédiaire 60 un message LRI SI60 lui indiquant le ou les préfixes des noeuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 8 et l'adresse IPv6 du serveur intermédiaire 62. A l'étape 72, le serveur intermédiaire 60 envoie au LMA 12 un message d'accusé réception LRA SI60. A l'étape 74, le LMA 12 transmet au serveur intermédiaire 62 un message LRI SI62 lui indiquant le ou les préfixes des noeuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 10 et l'adresse IPv6 serveur intermédiaire 60.

A l'étape 76, le serveur intermédiaire 60 envoie au LMA 12 un message d'accusé réception LRA SI62. Une fois les points d'entrées et de sorties des tunnels établis sur les serveurs intermédiaires 60, 62, le LMA 12 crée les points de sorties et d'entrées des tunnels sur les MAGs 8 et 10. Un point d'entrée/sortie va être créé sur le premier MAG 8 vers le premier serveur intermédiaire 60 et sur le deuxième MAG 10 vers le deuxième serveur intermédiaire 62 selon les étapes qui suivent. A l'étape 78, le LMA 12 transmet au MAG 8 un message LRI MAG8 lui indiquant le ou les préfixes des noeuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du serveur intermédiaire 60. A l'étape 80, le MAG 8 envoie au LMA 12 un message d'accusé réception LRA MAG8. A l'étape 82, le LMA 12 transmet au MAG 10 un message LRI MAG10 lui indiquant le ou les préfixes des noeuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du serveur intermédiaire 62. A l'étape 84, le MAG 10 envoie au LMA 12 un message d'accusé réception LRA MAG10. Les étapes 90 à 98 illustrent les échanges des données après l'optimisation du routage. A l'étape 90, le noeud source 4 transmet le flux au MAG 8. Ce dernier transfère, à l'étape 92, le flux reçu au serveur intermédiaire 60 via le tunnel configuré lors de la phase précédente.

A l'étape 94, le serveur intermédiaire 60 envoie le flux reçu au serveur intermédiaire 62. Ce dernier transfère, à l'étape 96, le flux reçu au MAG 10 via le tunnel configuré lors de la phase précédente. A l'étape 98, le MAG 10 envoie le flux au noeud destination 6.

Notons que la séquence d'envoi des messages LRI peut se faire selon un cadencement différent sans sortir du cadre de l'invention. En effet, le LMA 12 peut être configuré, par exemple, pour envoyer les messages LRI aux MAGs 8 et 10 avant de les envoyer aux serveurs intermédiaires 60, 62, ou encore de tout envoyer en parallèle. Toutefois, la séquence présentée dans la figure 6 consistant à configurer les serveurs intermédiaires 60, 62, puis les MAGs 8, 10 est préférée car elle permet de s'assurer de la disponibilité et de la bonne configuration de l'ensemble des serveurs intermédiaires formant le chemin de routage optimisé avant de configurer les MAGs pour que le flux de donnée empreinte ce chemin de routage optimisé. Notons également que tant que les MAGs 8 et 10 ne sont pas configurés avec l'information de routage optimisé contenue dans les messages LRI, le flux de donnée continue à être routé par le LMA 12, évitant ainsi toute interruption potentielle de service pendant la phase de configuration des serveurs intermédiaires 60, 62. Dans un cas particulier de mise en oeuvre de l'invention, lorsque le noeud source 4 se déplace du MAG 8 vers un nouveau MAG 100, c'est-à-dire, lors d'un changement d'association du noeud 4 dû à un déplacement dans le réseau par exemple, le nouveau MAG 100 enregistre la position du noeud au LMA 12, et à la réception du message de signalisation PBU (pour proxy binding update, en anglais), la mise à jour des tunnels suit la procédure décrite par la figure 7. Sur cette figure 7, les étapes 90 à 98, sont celles décrites par référence à la figure 6. A l'étape 102, le nouveau MAG 100 transmet un PBU (pour proxy binding update, en anglais) au LMA 12 pour enregistrer la nouvelle position du noeud 6. A l'étape 104, le LMA renvoie un message LRI SI62 au deuxième serveur intermédiaire 62 avec adresse IPv6 du MAG 100 auquel le noeud 6 est maintenant connecté afin que le serveur intermédiaire 62 mette à jour sa configuration de routage de telle manière que le traffic adressé au noeud 6 soit maintenant tunnelé vers le MAG 100 (plutôt que MAG8 comme initialement). A l'étape 106, le deuxième serveur intermédiaire 62 envoie au LMA 12 un message d'accusé réception LRA SI62. A l'étape 108, le LMA 12 transmet en retour 20 un message PBA (pour proxy binding acknowledgment, en anglais) au nouveau MAG 100. A l'étape 110, le LMA 12 envoie au nouveau MAG 100 un message LRI MAG100 lui indiquant le ou les préfixes des noeuds 4 et 6, leurs identifiants ainsi que 25 l'adresse IPv6 du serveur intermédiaire 62, ceci afin que le nouveau MAG 100 mette en place le routage optimisé via le serveur intermédiaire 62. A l'étape 112, le nouveau MAG 100 envoie au LMA 12 un message d'accusé réception LRA MAG100.

Après la mise à jour des tunnels décrite par les étapes 102 à 112, le nouveau MAG 100 remplace le MAG 8 dans les étapes 90 à 98 du routage optimisé. La figure 8 illustre schématiquement un mode de réalisation de l'invention dans le cas où les noeuds 4 et 6 qui échangent le flux de données sont attachés respectivement à un premier LMA 120 et à un deuxième LMA 122 différent du premier LMA 120 appartenant à deux domaines PMIPv6 distincts.

Lors d'une session d'échange de données multimédia, le MAG 8 auquel est attaché le noeud 4 transmet le flux de données, via un premier tunnel 124, à un premier serveur intermédiaire 126 contrôlé par le premier LMA 120. Le serveur intermédiaire 126 transmet le flux reçu, via un deuxième tunnel 128, à un deuxième serveur intermédiaire 130 contrôlé par le deuxième LMA 122. Le deuxième serveur intermédiaire 130 transmet le flux reçu, via un troisième tunnel 132, au MAG 10 auquel est attaché noeud 6.

La procédure d'optimisation du routage peut être initiée par un des deux LMAs 120 ou 122. Ces deux LMAs échangent des informations spécifiques afin de connaître à l'avance les points d'entrées et de sorties du tunnel 128 reliant les serveurs intermédiaires 126 et 130 géré par respectivemet ces deux LMA 120 et 122. La figure 9 illustre les échanges de messages entre les différents éléments de la figure 8 pour réaliser un routage optimisé. Les étapes 140 à 148 illustrent les 30 échanges des données avant l'optimisation du routage.

A l'étape 140, le noeud source 4 transmet le flux au MAG 8 auquel il est associé pendant la session. A l'étape 142, le MAG 8 transmet le flux au premier LMA 120. Ce dernier transmet, à l'étape 144, ledit flux au deuxième LMA 122. A l'étape 146, le deuxième LMA 122 transmet le flux au MAG 10 auquel est associé le noeud destination 6. A l'étape 148, le MAG 10 transmet le flux au noeud destination 6. Les étapes 150 à 172 illustrent la phase de configuration du routage optimisé selon l'invention. A l'étape 150, le premier LMA 120 transmet au deuxième LMA 122 un message RO init véhiculant des informations relatives au serveur intermédiaire 126. A l'étape 152, le deuxième LMA 122 transmet au premier LMA 120 un message RO init ack d'accusé réception véhiculant des informations relatives au serveur intermédiaire 130.

A l'étape 154, le LMA 120 transmet au serveur intermédiaire 126 un message LRI SI126 lui indiquant le ou les préfixes des noeuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 10 et l'adresse IPv6 du serveur intermédiaire 130. A l'étape 156, le serveur intermédiaire 126 envoie au LMA 120 un message d'accusé réception LRA SI126. A l'étape 158, le LMA 122 transmet au serveur intermédiaire 130 un message LRI SI130 lui indiquant le ou les préfixes des noeuds source 4 et destination 6, leurs identifiants ainsi que l'adresse IPv6 du MAG 10 et l'adresse IPv6 du serveur intermédiaire 126. A l'étape 160, le serveur intermédiaire 130 envoie au LMA 122 un message d'accusé réception LRA SI130. A l'étape 162, le LMA 120 envoie un message LRI MAG8 au MAG 8. A l'étape 164, le MAG 8 envoie au LMA 120 un message d'accusé réception LRA MAG8. A l'étape 166, le LMA 122 envoie un message LRI MAG10 au MAG 10. A l'étape 168, le MAG 10 envoie au LMA 122 un message d'accusé réception LRA MAG10.

A l'étape 170, le premier LMA 120 transmet au deuxième LMA 122 un message RO ack confirmant la mise en place de la première branche du routage optimisé via le MAG 8 et le serveur intermédiaire 126 gérés par le premier LMA 120.

A l'étape 172, le deuxième LMA 122 transmet au premier LMA 120 un message RO ack confirmant la mise en place de la seconde branche du routage optimisé via le serveur intermédiaire 130 et le MAG 10 gérés par le deuxième LMA 122.

Les étapes 180 à 188 illustrent les étapes du routage optimisé après la configuration du routage effectuée par les étapes 150 à 172. A l'étape 180, le noeud source 4 transmet le flux au MAG 8. Ce dernier transmet (étape 182) le flux reçu au serveur intermédiaire 126 qui le transmet à son tour (étape 184) au serveur intermédiaire 130.

A l'étape 186, le serveur intermédiaire 130 transmet le flux au MAG 10 qui le transmet à son tour (étape 188) au noeud destination 6. Notons qu'un système d'authentification des serveurs intermédiaires entre les deux domaines PMIPv6 permet de garantir l'authentification et la protection des données échangées. La figure 10 illustre schématiquement le format d'un message LRI.

Ce message comporte : - Numéro de séquence (16 bits) : C'est un nombre qui s'incrémente linéairement et qui permet d'identifier un message. - un bit R (1 bit) : Quand il est à 0, il identifie le message comme étant un LRI. - un bit S (1 bit) : Quand il est à 1, il demande la désactivation du routage optimisé locale. un bit I (1 bit) : Quand il est à 1, il indique que ce message est destiné à un serveur intermédiaire. - Une suite de bits Reserved (13 bits): Champs réservé. Il doit être mis à 0. - Une suite de bits Lifetime (16 bits) : Le temps en seconde de la durée de vie du tunnel. Quand tous les bits sont à 1, la durée est infinie. - Mobility options : Suite d'options de taille variable. Le LMA indique toutes les informations utiles pour détecter le flux des clients. Les informations qui doivent être incluses sont : L'identifiant du client 1 (MN1-ID), un ou plusieurs préfix (MN1-HNP) attribués au client 1, l'identifiant du client 2 (MN2-ID), un ou plusieurs préfix attribués au client 2 (MN2-HNP) et l'adresse IPv6 du MAG ou du serveur intermédiaire de l'autre côté du tunnel. Le format de l'option avec l'adresse IPv6 peut se baser sur le format du paquet « MAG IPv6 address ». Quand ce message est destiné à un serveur intermédiaire (bit I à 1), deux adresses IPv6 (de MAG ou SI) associé aux MNIDs des deux clients sont fournies pour les deux tunnels afin d'établir correctement les routes dans les tables de routages. Les options MN-ID et MN-HNP sont définies dans la RFC5213. À la réception d'un message LRI, un serveur intermédiaire vérifie dans un premier temps que le bit I est mis à 1. Dans le cas contraire, le message est ignoré. Le serveur intermédiaire récupère ensuite les options de mobilités et établir les tunnels vers les MAGs et/ou les SIs (serveurs intermédiaires). Il est important que les options soient organisées de telles sortes que le SI puisse déterminer comment créer ses deux tunnels. En effet, il y a un sens de communication en fonction d'où se trouvent les clients et le SI doit correctement mettre à jour sa table de routage. La figure 11 illustre un exemple où les options sont organisées selon un ordre précis. Le SI, peut dans ce cas interprétés séquentiellement les options. Dans ce cas, pour mettre à jour sa table de routage pour le noeud MN1-ID, le SI considère le préfixe MN1-HNP et transfère les données vers l'adresse IPv6 du SI ou MAG. De même pour l'autre sens de communication (MN2-ID, etc.).

La figure 12 illustre schématiquement le format d'un message LRA. Ce message comporte : - un Numéro de séquence (16 bits) : C'est 5 un nombre qui s'incrémente linéairement et qui permet d'identifier un message. - un bit R (1 bit) : Quand il est à 1, il indique que c'est un LRA. - un bit U (1 bit) : Doit être mis à 0. 10 - un bit I (1 bit) : Quand il est à 1, indique qu'il est envoyé par un serveur intermédiaire. une série de bits Reserved (5 bits): Champs réservé. Il doit être mis à 0. - une série de bits Status (8 bits) : Quand 15 il est à 0, ce champ indique un succès. Quand le bit I est à 0 (LRA envoyé par un MAG), et que la valeur du statut vaut 129, il indique que le client n'est plus associé au MAG. Quand le bit I est à 1 (LRA envoyé par un serveur intermédiaire), et que la valeur du statut 20 vaut 129, il indique que l'opération a échoué. - une série de bits Lifetime (16 bits) : Le temps en seconde de la durée de vie du tunnel. Quand tous les bits sont à 1, la durée est infinie. Par défaut, la valeur indiqué dans le LRI. 25 - Mobility options : Dans tout les cas, est retourné le contenu du même champ provenant du message LRI. En plus des paramètres de base présentés ci-dessus, les paquets LRI peuvent comporter des 30 paramètres pour indiquer aux serveurs intermédiaires et aux MAG le type de traitement à appliquer à un ou plusieurs flux de données. Les serveurs intermédiaires peuvent ainsi assurer de multiples fonctionnalités/services. Les LMA sont configurables pour indiquer dynamiquement aux serveurs intermédiaires (lors de la phase de configuration du routage optimisé par envoi des messages LRI) quel service il doit spécifiquement activer pour un flux donné. Le flux étant aussi indiqué dans le message LRI.

Le procédé selon l'invention peut être appliqué à d'autres protocoles de gestion de la mobilité. Ainsi, dans le cas des protocoles Mobile IPv4 [ref] et Mobile IPv6 [ref], et en particulier de leurs extensions respectives NEMOv4 [ref] et NEMOv6 [ref] pour le support des routeurs mobiles, il est aussi important de réduire les chemins parcourus par les données entre deux Routeurs Mobiles afin de ne pas traverser le Home Agent systématiquement. Aucune extension spécifique au protocole NEMOv6 n'a été définie pour permettre un routage optimal (par exemple, via un tunnel direct) entre 2 routeurs mobile IPv6. En ce qui concerne le protocole NEMOv4, une extension connue, intitulée « HAARO » [ref], propose de faire de l'optimisation de routage entre des routeurs mobiles IPv4. Ce mécanisme offre des routes directes (sous la forme de tunnels) entre deux routeurs mobiles associés à un même Home Agent (HA). Cette solution se base sur l'échange de messages Registration Request et Reply directement entre les deux routeurs mobiles, afin d'échanger les informations nécessaires à l'établissement d'un tunnel direct (pour le routage optimisé) entre eux. Cette solution a toutefois deux inconvénients majeurs : d'une part la mise en place du routage optimisé doit être initiée par l'un des deux routeurs mobiles, aucun mécanisme n'étant prévu pour permettre un déclanchement à l'initiative de l'operateur du réseau (via une entité centralisé). D'autre part, seul un tunnel direct entre les deux routeurs mobiles peut être établi, ne permettant donc pas de rediriger le trafic optimisé vers un ou plusieurs serveurs intermédiaires sous le contrôle d'un operateur. Afin de résoudre ces problèmes, la solution décrite précédemment en détail dans le cadre d'un domaine PMIPv6 peut s'appliquer pour optimiser le routage entre routeurs mobiles permettant ainsi à une entité réseau sous le contrôle de l'operateur, ici le Home Agent (de manière analogue au LMA), de configurer un chemin de routage optimisé passant par des serveurs intermédiaires pour router le trafic entre deux routeurs mobiles (de manière analogue aux MAGs). Le Home Agent est alors considéré comme point de contrôle, et est configuré par l'opérateur du réseau mobile afin de définir le chemin optimisé (passant par des serveurs intermédiaires) que les flux de données doivent prendre entre deux routeurs mobiles. Ce chemin peut inclure un ou plusieurs Serveur Intermédiaire(s) pour la mise en oeuvre de services selon les besoins de l'opérateur.

La figure 13 illustre les étapes pour l'optimisation de routage entre deux routeurs mobiles NEMOv6. L'échange de messages est similaire à celui qui est décrit par référence à la figure 6 en remplaçant le LMA 12 par le HA 190 (Home Agent), les noeuds source 4 et destination 6 respectivement par les noeuds fixes LFN 200 et 202 (pour (Local Fixed Nodes), qui peuvent être des équipements portables des passagers d'un véhicule mobile connectés respectivement aux routeurs mobiles MR 204 et 206. Dans l'exemple de la figure 13, deux serveurs intermédiaires 208 et 210 sont définis par l'opérateur. Dans ce contexte, pour configurer le routage optimisé, le Home Agent 190 envoie des messages « LRI SI » vers les Serveurs Intermédiaires et des messages « LRI MR » vers les Routeurs Mobiles. Une fois ces messages envoyés et acquittés, le trafic de données entre les deux routeurs mobiles 204 et 206 ne passera plus par le HA 190, mais par le chemin optimisé traversant les Serveurs Intermédiaires 208 et 210.

Pour réaliser cela, les messages LRI SI et LRI MR comportent des informations et instructions relatives aux adresses des Clients LFN 200 et 202 connectés respectivement aux routeurs mobiles 204 et 206. Ces informations peuvent être groupées sous forme d'un « prefix » couvrant plusieurs adresses IPv6 valides sous un même Routeur Mobile (on parle alors de préfix de réseau mobile, ou MR-MNP « Mobile Network Prefix of a Mobile Routeur »). Cette information MR-MNP peut, par exemple, être transportée dans les messages LRI en utilisant une option ayant le même format que l'option MN-HNP la figure 10.

Dans un scénario où les deux routeurs mobiles 204 et 206 sont associés à des Home Agents différents, les deux Home Agents (HA) communiqueront entre eux afin de permettre l'établissement du routage optimisé via des serveurs intermédiaires. Enfin, le même principe peut aussi être utilisé pour optimiser le routage (via des serveurs intermédiaires) entre deux terminaux mobiles utilisant les protocoles Mobile IPv4 et Mobile IPv6. Dans ce cas, ces noeuds n'ayant pas véritablement de préfix mais uniquement des adresses IP dites « home », ces adresses sont transportées dans les messages LRI (en lieu des préfix MN-HNP ou MR-MNP).

Claims (2)

1. REVENDICATIONS1. Procédé d'optimisation du routage d'un flux échangé entre deux noeuds (4, 6) dans un réseau de télécommunications d'un opérateur caractérisé par une étape consistant à re-router ledit flux via au moins un serveur intermédiaire (22, 25, 26, 27, 44, 58), agencé entre lesdits noeuds, et apte à appliquer audit flux au moins un traitement prédéfini par l'opérateur.
2. 2. Procédé selon la revendication 1 dans lequel ledit traitement prédéfini comporte au moins l'une des fonctions suivantes . - filtrer les contenus du flux, - appliquer une tarification aux différentes composantes du flux, - mesurer la bande passante consommée, - fournir une qualité de service différenciée en fonction du client ou du type de flux. 6. Procédé selon la revendication 2 comportant une phase de sélection, par l'opérateur, des traitements à appliquer au flux et d'un ou de plusieurs serveurs intermédiaires (22, 25, 26, 27, 44, 58) aptes à appliquer lesdits traitements, et une phase de configuration du routage optimisé pour ce flux en fonction des traitements prédéfinis. 7. Procédé selon la revendication 3 dans lequel la configuration du routage consiste à créer, entre les noeuds (4, 6, 200, 202), au moins un tunnel (20, 24, 33,34, 35, 36, 46, 48) passant par un ou plusieurs serveurs intermédiaires (22, 25, 26, 27, 44, 58, 208, 210). 5. Procédé selon la revendication 4 dans lequel lors d'une connexion au réseau, chaque noeud se connecte à un routeur d'accès (8, 10, 52, 54, 60, 62, 126, 130, 204, 206) relié à une entité centrale (12, 56, 122, 190) adaptée pour définir, pour chaque routeur d'accès (8, 10, 52, 54, 204, 206), une table de routage optimisée en fonction des traitements prédéfinis par l'opérateur dans chaque serveur intermédiaire. 6. Procédé selon la revendication 5 dans lequel lesdits routeurs d'accès sont des routeurs fixes (8, 10). 7. Procédé selon la revendication 5 dans lequel lesdits routeurs d'accès sont des routeurs mobiles (52, 54, 204, 206). 8. Procédé selon l'une des revendications 6 ou 7 dans lequel le réseau de télécommunication est un réseau de type IP. 9. Procédé selon la revendication 8 dans lequel l'entité centrale crée les entrées et sorties des tunnels sur chaque serveur intermédiaire (22, 25, 26, 27, 44, 58, 208, 210) en envoyant à chacun desdits serveurs intermédiaires un message de signalisation comportant des informations sur les adresses IP des noeuds (4, 6, 200, 202), le ou les préfixes des noeudssource et destination, les identifiants desdits noeuds source (4, 6, 200, 202) et destination ainsi que l'adresse IP du serveur précédent et l'adresse IP du serveur suivant. 10. Procédé selon la revendication 9 dans lequel l'entité centrale retransmet ledit message de signalisation si aucune réponse n'est reçue pendant un temps d'attente prédéfini. 10 11. Procédé selon l'une des revendications 4 à 10 comportant en outre une étape de mise à jour des tunnels à la suite d'un changement d'association d'un noeud à un nouveau MAG dans laquelle le nouveau MAG 15 auquel le noeud est associé enregistre la position dudit noeud au LMA (12) à la réception du message de signalisation PBU (pour proxy binding update, en anglais). 20 12. Procédé selon la revendication 1 dans lequel les noeuds (4) et (6) sont attachés respectivement à un premier LMA (120) et à un deuxième LMA (122) différent du premier LMA (120) appartenant à deux domaines PMIPv6 distincts, et, lors d'une session d'échange de données 25 multimédia, le MAG (8) auquel est attaché le noeud (4) transmet le flux de données, via un premier tunnel (124), à un premier serveur intermédiaire (126) contrôlé par le premier LMA (120), le serveur intermédiaire (126) transmet le flux reçu, via un 30 deuxième tunnel (128), à un deuxième serveur intermédiaire (130) contrôlé par le deuxième LMA (122), le deuxième serveur intermédiaire (130) transmet le5flux reçu, via un troisième tunnel (132), au MAG (10) auquel est attaché noeud (6). 13. Dispositif d'optimisation du routage d'un flux échangé entre deux noeuds (4, 6, 200, 202) dans un réseau de télécommunications d'un opérateur caractérisé en ce qu'il comporte des moyens pour re-router ledit flux via un ou plusieurs serveurs intermédiaires (22, 25, 26, 27, 44, 58, 208, 210) configurés pour appliquer audit flux au moins un traitement prédéfini par l'opérateur.