LA MOBILITE DES COMMUNICATIONS ET SUPPORT DE PETITS GROUPES

THÈSE présentée à l Université Louis Pasteur de Strasbourg Département Informatique LSIIT, CNRS UMR 7005 Pour obtenir le grade de Docteur de l Université Louis Pasteur Mention SCIENCES Spécialité INFORMATIQUE par Mouhamadou Lamine DIAGNE LA MOBILITE DES COMMUNICATIONS ET SUPPORT DE PETITS GROUPES Soutenue publiquement le 22 Septembre 2004 devant le jury composé de : M. Bernard COUSIN, Rapporteur externe Professeur IRISA/INRIA - Rennes M. Hervé GUYENNET, Examinateur Professeur Laboratoire Informatique Besançon M. Thomas NOEL, Co-encadrant Maître de Conférences HDR Université Louis Pasteur- Strasbourg M. Jean-Jacques PANSIOT, Directeur de thèse Professeur - Université Louis Pasteur - Strasbourg M. Pierre VINCENT, Rapporteur externe Professeur Institut Nationale des Télécommunications Evry M. Eric VIOLARD, Rapporteur interne Maître de Conférences HDR Université Louis Pasteur- Strasbourg

LA MOBILITE DES COMMUNICATIONS ET SUPPORT DE PETITS GOUPES Mouhamadou Lamine DIAGNE

Remerciements Je remercie Jean-Jacques Pansiot et Thomas Noel, mes directeurs de thèse, pour avoir encadré mes travaux de recherche, et m avoir soutenu jusqu à la fin. Ils n ont ménagé aucun effort pour que les travaux soient menés à bien. Je remercie également Messieurs Bernard Cousin, Hervé Guyennet, Pierre Vincent et Eric Violard, pour l intérêt qu ils ont porté à mon travail en acceptant de faire partie du jury. Un grand merci à tous les membres de l équipe de recherche Réseau du LSIIT et merci à ma mère, ma femme, à toute ma famille et à mes amis pour leur soutien.

Plan du mémoire Introduction... 6 Chapitre 1. Les travaux existants dans la redirection de communications...16 1. Redirection utilisant la couche application...16 1.1. Xmove...17 1.1.1. Caractéristiques de Xmove...17 1.1.2. Les étapes du déplacement de fenêtre...19 1.1.3. Conclusion...20 1.2. La téléphonie IP avec SIP...20 1.2.1. L organisation dans SIP...21 1.2.2. Initiation d un appel téléphonique...21 1.2.3. Déplacement de l utilisateur durant un appel...23 1.2.4. Conclusion...23 2. Redirection utilisant la couche transport...24 2.1. Migration TCP...24 2.1.1. Principe de la migration TCP...25 2.1.2. Migration d une connexion...26 2.1.3. Application : basculement d un serveur à un autre...26 2.1.4. Conclusion...28 3. Analyse des besoins des protocoles et applications dans la redirection de communications...28 3.1. Synthèses des différentes solutions proposée...28 3.2. Proposition d un service générique de redirection de communications...30 Chapitre 2. Nouvelle approche dans la redirection de communications...31 1. Le protocole IPv6...32 1.1. Vue globale de IPv6...32 1.1.1. L adressage...33 1.1.2. L entête IPv6...33 1.1.3. Les extensions d entête IPv6...34 1.2. Quelques nouvelles fonctionnalités d IPv6...36 1.3. Conclusion...37 2. La mobilité IPv6...37 2.1. Fonctionnement de la mobilité dans IPv6...38 2.2. Découverte des agents mère...39 2.3. Communication entre le nœud mobile et ses correspondants...39 2.3.1. Tunnel bidirectionnel...40 2.3.2. L optimisation du routage...41 2.4. Conclusion...42 3. Le protocole de découverte de service SLP...44 3.1. Vue globale sur SLP...45 3.2. Caractéristiques de SLP...46 2

3.2.1. Hiérarchie...46 3.2.2. "Scope" ou portée...46 3.3. Implémentation de SLP...46 3.3.1. Les messages dans SLP...47 3.3.2. Configuration des UAs avec un serveur DHCP...49 3.3.3. Sécurité dans SLP...50 3.4. Conclusion...50 4. Redirection de communications IPv6...50 4.1. Rappel du contexte...51 4.2. Procédures de la redirection d une communication...53 4.2.1. Description du service de redirection de communications...53 4.2.2. Description du protocole de redirection de communications...54 4.2.3. Identification des communications...55 4.2.4. Dialogue entre les nœuds concernés...57 4.2.5. Redirection de la communication...57 4.3. Algorithmes utilisés dans le protocole IPCR...59 4.3.1. Structures de données...60 4.3.2. Algorithme de découverte des communications...61 4.3.3. Algorithmes de redirection de communications...64 4.4. Les messages de la redirection de communication...69 4.5. Redirection sans modification de Corr1...71 4.5.1. Demande de redirection d une communication...71 4.5.2. Redirection des paquets de la communication...73 4.5.3. Envoi de paquets par Corr3...74 4.5.4. Les cas d échec de la redirection...76 4.6. Redirection par Corr1...77 4.6.1. Demande de redirection d une communication...79 4.6.2. Envoi de paquets par Corr3...80 4.7. Comparaison entre les deux solutions proposées...81 4.8. Interactions avec RTP/RTCP pour les applications multimédia...82 4.8.1. Qu est-ce que RTP/RTCP et comment fonctionne-t-il...82 4.8.2. Interactions entre IPCR et RTP/RTCP...83 4.9. La sécurité dans la redirection de communication...83 4.10. Conclusion...84 Chapitre 3. Le multipoint...90 1. La communication de groupe...91 2. Le multipoint classique...92 2.1. Le protocole IGMP...93 2.2. Mbone...93 2.3. Le protocole de routage multipoint PIM...94 2.3.1. PIM en mode dense (PIM-DM)...94 2.3.2. PIM en mode épars (PIM-SM)...95 2.4. Conclusion...95 3. Le multipoint explicite...96 3.1. Protocole créant des états sur les routeurs...97 3.1.1. REUNITE...97 3.1.2. Conclusion...101 3.2. Protocoles pour les petits groupes...101 3.2.1. Protocoles sans états sur les routeurs...102 3.2.2. Protocole avec états sur les routeurs...111 3

3.3. Synthèse sur les Xcast...113 4. Conclusion...115 Chapitre 4. La communication de groupe dans IPCR...118 1. La mobilité IPv6 Hiérarchique (HMIPv6)...119 1.1. Vue globale sur HMIPv6...119 1.2. Déplacement dans un nouveau domaine...121 1.3. Déplacement dans un même domaine...122 1.4. Conclusion...122 2. La communication de groupe avec IPCR-SG...122 2.1. Vue globale sur IPCR-SG...123 2.2. Les mécanismes utilisés...127 3. Conclusion...129 Chapitre 5. Evaluation d IPCR-SG...130 1. Comparaison d IPCR-SG avec les Xcast...130 2. Simulations...136 2.1. Topologies utilisées...136 2.2. Résultats des simulations...136 2.2.1. Temps d adhésion et de réception des paquets...137 2.2.2. Utilisation des routeurs...141 2.3. Conclusion...145 Conclusion...148 Références bibliographiques...152 4

5

Introduction Le but de nos travaux de thèse fut d étudier la mobilité des communications de façon à proposer un système générique qui soit indépendant des applications. Ainsi, notre proposition est basée sur un protocole qui peut être subdivisé en deux parties dont la première offre un service de redirection de communications et la deuxième définit un mécanisme de communication dans les petits groupes. Avec l'avènement de nouvelles technologies dans l'informatique conciliée à l'évolution d Internet qui a pris maintenant une ampleur insoupçonnée, la mobilité dans les réseaux devient un aspect important à prendre en compte. En effet, les utilisateurs avec ou sans leurs machines sont de plus en plus mobiles et ont tendance à vouloir accéder à leurs outils de travail habituels où qu'ils puissent se trouver soit à partir de leurs machines mobiles soit à partir d'une autre qui peut être fixe. On peut définir trois types de mobilité : la mobilité de l'environnement utilisateur, la mobilité du terminal et la mobilité des services : - La mobilité de l'environnement utilisateur : l'utilisateur peut s'identifier et se connecter à différents endroits et retrouver ainsi son environnement de travail habituel. C'est le cas de l'utilisateur qui se déplace sans sa machine et qui se connecte à partir d'une tierce machine. - La mobilité du terminal : il devient possible à un terminal d'accéder à Internet depuis n'importe quel point et ce, même pendant son déplacement. Ce cas est celui de l'utilisateur qui se déplace avec sa machine portable et qui voudrait rester connecté au réseau. - La mobilité des services : ce type de mobilité associe les services à un utilisateur et non à une interface particulière. Un concept qui peut être vu comme un cas particulier de la mobilité des services est la mobilité des communications qui est l objet d étude de cette thèse. Il s'agit, en général, de la capacité à rediriger des communications d'une machine vers une autre. Nous supposons que la machine vers laquelle nous voulons rediriger la communication est capable de la recevoir. 6

Dans notre étude, pour la redirection de communications, nous ne nous intéressons qu aux communications point-à-point. Dans une communication multipoint, la redirection peut être implicite car elle correspond à un retrait d une station et à l adhésion d une autre. Par exemple, supposons que nous soyons en train de recevoir une transmission vidéo sur notre machine et nous voulons la rediriger vers une salle de travail sur une machine connectée à un vidéo-projecteur. Ce mécanisme consiste à avoir toujours la même communication mais au lieu de la recevoir sur la machine initiale, la communication sera re-routée sur une autre machine. Une possibilité serait d effectuer la redirection en intervenant au niveau de l application. Alors la première communication est interrompue et une autre destinée à la nouvelle machine sera établie. On constate que cet ensemble d'opérations, si on réussit à l'effectuer, est fastidieux et coûte trop de temps. Une alternative est d'utiliser le réseau pour demander à la station émettrice d effectuer la redirection de cette communication. En effet, si cette station supporte la redirection, la communication entre cette dernière et la station choisie se déroulera normalement. Ce procédé nous fera gagner du temps car il ne sera plus nécessaire d interrompre la communication pour en établir une seconde. Un autre avantage de cette alternative est qu il nous sera possible de rediriger cette communication non seulement à partir de la première machine réceptrice mais aussi à partir de la machine où nous voudrions la recevoir et même d une machine tierce qui n a rien à voir avec cette communication. Ce concept de redirection de communications est assez proche des mécanismes qui existent déjà dans les télécommunications téléphoniques où on a la capacité de rediriger : Un appel destiné à un poste vers un autre poste par exemple en notre absence Une communication téléphonique en cours comme une personne qui pas se une communication à un collaborateur. Dans les deux cas précédents on se rend compte que le correspondant n a pas à interrompre sa communication pour passer un deuxième appel. Corr1 Communication initiale Communication déplacée Corr2 Corr3 Figure 1. Aperçu de la redirection d une communication 7

Dans ce qui suit, nous appellerons Corr1 et Corr2 les deux correspondants initiaux, Corr3 l équipement qui viendra se substituer à Corr2 pour la communication qui a été redirigée et Initiator l initiateur de la redirection de la communication (i.e. la station qui fait la demande de redirection de la communication au profit de Corr3) qui peut être représenté par Corr2, Corr3 ou une machine tierce. Ainsi, nous recherchons un système générique indépendant des applications. Il est certain que toute application ne sera pas adaptée à utiliser la redirection de communications. Par exemple, nous n allons pas rediriger une communication concernant un transfert de fichier car il n est pas concevable d avoir une partie du fichier sur une machine et l autre sur une deuxième. En général, les communications à rediriger seront celles qui n ont pas de persistance, dont l utilité se justifie à l instant présent : elles ne seront pas exploitées ultérieurement. Ces communications se font principalement avec l utilisateur comme dans le cas d une vidéoconférence, de la téléphonie IP, des applications interactives. La redirection de communications peut s effectuer pour différentes raisons. En supposant encore une fois qu une personne soit en train de recevoir une communication, l utilisation de la redirection pour acheminer cette communication sur une autre machine pourrait se faire pour les raisons suivantes: - Cette machine est plus adéquate à recevoir la communication. - La personne elle-même se déplace. - Pour passer la communication à une tierce personne. De plus, l utilisation de la redirection de communications peut être adéquate pour les fournisseurs de services. En effet, avec des clients qui sont de plus en plus nombreux, assurer un degré de fiabilité et de disponibilité suffisant est un grand défi que doivent relever les fournisseurs de service. Pour atteindre ce but, aujourd hui, les fournisseurs de services ont fait appel à la redondance sous une forme ou une autre et à la duplication des serveurs de telle sorte que des services disponibles et fiables soient proposés sur le Web. Pour que ce système fonctionne correctement, un commutateur, placé entre le client et les serveurs, est utilisé. La figure 2 illustre la communication entre le client et les serveurs. Ainsi, pour communiquer avec un serveur, le client passe par le commutateur qui redirige les paquets vers le serveur adéquat. Au cas où il se pose un problème de congestion ou de panne de serveur ou de service indisponible, le commutateur peut rediriger les requêtes du client vers un autre serveur de manière transparente à l application de ce client. En résumé, l ensemble des serveurs est vu par le client comme une seule et même machine. L utilisation d un commutateur est assez adéquate aux connexions Web qui représentent en général des connexions relativement courtes. Cette solution ne s appliquerait pas convenablement à une transmission multimédia en continu dont la durée peut être plus longue. Ce genre de communication nécessite, si un serveur est surchargé ou si le service 8

demandé est indisponible, que la communication avec un client en cours soit rapidement basculée sur un autre serveur. Ainsi, on peut faire appel à la redirection de communication pour permettre au client d utiliser un autre serveur et ceci de manière transparente à l application. Serveur A Serveur B Commutateur Client Figure 2. Communication gérée par un commutateur Rediriger une communication suppose qu une des stations ne recevra plus la communication. Cependant, on pourrait vouloir conserver la communication et faire participer une autre station. Ceci introduit la notion de communication de groupe. La communication de groupe est un concept qui permet à plusieurs stations, formant un groupe, de partager la même communication. Ainsi, quand une information est envoyée alors tous les utilisateurs appartenant au groupe vont la recevoir. Ce concept de communication de groupe ou communication multipoint se développe de plus en plus et il rencontre une forte demande des utilisateurs. En effet, ce concept est souvent utilisé entre autres en vidéoconférence, dans les applications collaboratives. Notre contribution dans ce domaine est de permettre la transformation d une communication point à point en une communication de petit groupe sans avoir à interrompre la première. Par exemple, supposons qu il y ait une vidéoconférence entre deux stations utilisant une communication point à point. Si une troisième station et éventuellement d autres veulent participer à cette vidéoconférence, alors comme cette communication est en point à point, la seule possibilité est de l interrompre et d initier une autre vidéoconférence utilisant un groupe multipoint auquel ces stations vont adhérer. Avec notre proposition, il n y a pas cette interruption durant la vidéoconférence car nous sommes capables de permettre à d autres stations de prendre part à la vidéoconférence sans avoir à changer la technique de communication c est à dire sans avoir à passer d une communication point à point à une communication multipoint. Seuls les mécanismes de communication point à point seront utilisés ainsi la communication point à point initiale est conservée. Il est important de noter 9

que ce service est limité à une communication de groupe avec un petit nombre de membres. Notre objectif n est pas de trouver une technique remplaçant le multipoint traditionnel mais seulement d éviter l interruption de la communication initiale entre les correspondants et le passage d une communication point à point en multipoint. Notre mémoire se compose de deux grandes parties qui représentent les deux domaines dans lesquels nous avons porté notre étude à savoir la redirection de communication et la communication de petit groupe. Dans la première partie qui porte sur la redirection de communication, nous présentons d abord des travaux qui tentent de résoudre la gestion de la redirection des communications. Par la suite, nous présentons l approche que nous avons proposée et pour cela nous commençons par décrire les protocoles que nous avons utilisés. Pour finir, nous faisons une comparaison entre notre proposition et les différents travaux que nous avons présentés. La deuxième partie est consacrée à la communication de groupe. Ainsi, nous étudions différentes méthodes proposées pour mettre en place une communication de groupe allant du modèle multipoint classique à celui destiné aux petits groupes. A la suite de la présentation des travaux existants, nous décrivons les mécanismes que nous avons proposés pour la transformation d une communication point à point en une communication de petit groupe. Puis, nous présentons les résultats de l évaluation qui a été faite. 10

11

Partie 1 La redirection de communications 12

13

Introduction Une communication est identifiée comme étant un flux d informations entre deux ou plusieurs applications en général situées sur des machines différentes. Ainsi, la redirection d une communication d une certaine station consiste à re-router le flux d informations destiné à une application de cette station vers «la même application» située sur une autre machine. De ce fait, l application de la station initiale ne recevra plus ce flux d informations mais ce sera à l application située sur la nouvelle station de le recevoir à sa place. Pour illustrer la redirection de communication, nous supposons, comme dans l introduction, que nous soyons en train de recevoir une transmission vidéo sur notre machine et nous voulons la rediriger vers une salle de travail sur une machine connectée à un vidéo - projecteur. Ce mécanisme consiste à avoir toujours la même communication mais au lieu de la recevoir sur la machine initiale, la communication sera re-routée sur une autre machine. Cette redirection de communications peut s effectuer pour différents motifs. Ainsi, nous pourrions être amenés à rediriger une communication vers une machine par ce que : - Cette machine est plus adéquate pour recevoir la communication. - L utilisateur lui-même se déplace. - L utilisateur veut passer la communication à une autre personne. Le problème de la redirection de communications peut être abordé de différentes manières, c est à dire peut être pris en charge à différents niveaux des couches OSI. Et en fonction du niveau où on se situe, la redirection d une communication peut être plus ou moins transparente par rapport aux applications utilisées. C est ainsi que nous voyons certains travaux essayant d apporter des solutions en se basant sur la couche application et d autres qui utilisent la couche transport. Dans cette partie, nous étudions les travaux existants dans ce domaine et puis nous décrivons la nouvelle approche que nous avons proposée pour apporter une solution à la redirection des communications. 14

15

Chapitre 1. Les travaux existants en redirection de communication Dans ce chapitre, nous allons présenter des travaux existants dans le domaine de la redirection des communications. Nous verrons que cette redirection de communications peut être prise en charge à différents niveaux (i.e. couches application, transport, réseau). En fonction de la couche utilisée, la solution apportée peut ou pas être transparente à l application et, va nécessiter ou pas des applications particulières. Ainsi, si la redirection n est pas transparente à l application, tout programmeur voulant proposer ce service devra en général prendre en compte cet aspect pour développer son application ; ce qui pourrait engendrer beaucoup de contraintes dans l utilisation des applications. Si au contraire, la redirection des communications est transparente aux applications, il ne sera pas nécessaire de la prendre en compte dans le développement de nouvelles applications et il serait même possible d utiliser celles qui existent déjà. Pour le moment, les travaux existants utilisent soit la couche application soit la couche transport. Dans la première section nous présentons les travaux existants qui utilisent la couche application pour aborder la redirection des communications. Il s agit du système X window Xmove [SOL 1995] et de la téléphonie IP avec SIP (Session Iniatiation Protocol : Protocole d initiation de session) [RFC3261]. Dans la section suivante, nous décrivons la migration TCP (TCP Migrate) [SNO 2000] qui utilise la couche transport pour prendre en charge la redirection de communications. Enfin, dans la section 3, nous faisons une analyse des besoins des protocoles et applications dans le cadre de la redirection de communications. Ceci nous permet de recenser ce qu il est nécessaire de prendre en compte pour proposer un système générique. 1. Redirection utilisant la couche application Dans cette section, nous présentons des travaux qui ont été effectués dans le domaine de la redirection de communications et qui utilisent la couche application pour atteindre leur but. Les travaux que nous décrivons sont Xmove et ceux réalisés dans la téléphonie IP avec le protocole SIP. 16

1.1. Xmove Xmove [SOL 1995] est un système X window fournissant un modèle client-serveur dans lequel des clients peuvent se connecter à un serveur contrôlant l affichage sur une plateforme distante. Ainsi, il est possible de déplacer l affichage de l interface X11 d une application à partir d un terminal vers un autre. Cet outil permet alors à l interface graphique d une application exécutée sur une station donnée d être affichée sur un autre terminal de la même station ou d une autre. Le but est d éviter à l utilisateur de réinitialiser son interface utilisateur quand il se déplace vers un autre terminal. Ainsi, il lui suffira de déplacer l interface graphique de l application sur laquelle il travaillait. Xmove est utilisé comme un pseudoserveur qui se trouve être un programme occupant une position intermédiaire entre le client et le serveur : il joue le rôle de client pour le serveur et celui de serveur pour le client. Cette position intermédiaire lui permet de capturer, d interpréter, de changer si nécessaire puis de rediriger des messages du protocole X échangés entre le client et le serveur. Serveur X N 1 Serveur X N 1 Serveur X N 2 Messages X Application = client pseudoserveur Application = client pseudoserveur Figure 3. Déplacement de fenêtres avec Xmove 1.1.1. Caractéristiques de Xmove Xmove, comme nous l avons dit précédemment, a été implémenté sous forme de pseudoserveur. Ce choix a été fait pour éviter d effectuer certains changements au niveau du serveur et du client. Ainsi, un certain nombre de buts à atteindre ont été fixés: Le serveur ou Xlib 1 n a pas besoin d être modifié et les clients n ont pas à être recodés. 1 Xlib est une librairie utilisée par les applications comme interface avec X window 17

Le nouveau serveur n a pas besoin d être spécifié au démarrage du client : il doit être sélectionnable juste avant le déplacement. Les paramètres contrôlés par le modèle d interface utilisateur graphique doivent fonctionner sur le nouveau serveur Les configurations courantes d affichage telles que le monochrome et la couleur 8 bits doivent être supportés. Notons que l utilisation d un pseudoserveur n est pas la seule manière d implémenter le déplacement de fenêtre. En effet il est possible de l implémenter au niveau du client, du serveur ou de Xlib : Client : si cette fonction est placée au niveau du client, celui-ci serait capable de se déplacer par lui-même. Cela éviterait la redirection des messages de bas niveau et permettrait un contrôle maximum du client dans son environnement : seul le client est capable de s ajuster de manière optimale avec un nouveau serveur ayant de moindres ressources. De plus, il est capable de découvrir chez le nouveau serveur de nouvelles caractéristiques n existant pas au niveau du précédent. Seulement, cette implémentation suppose que le client devra créer de nouveau une connexion avec le nouveau serveur, créer ses fenêtres comme l utilisateur les avait laissées sur le précédent serveur. Une raison qui pourrait pousser à ne pas choisir cette solution es t que les programmeurs devraient individuellement implémenter cette fonction dans chacune de leurs applications ce qui est loin d être une priorité pour la plupart d entre eux. Serveur : dans ce cas, cette fonction serait implémentée comme une extension du serveur afin de rediriger les messages du client vers le nouveau serveur. Cette approche est assez proche du pseudoserveur et le serveur jouerait le rôle d intermédiaire et convertirait de manière adéquate les informations et pourrait même compenser certaines fonctionnalités n existant pas dans le nouveau serveur. Mais il se pose le problème de compatibilité entre des plate-formes très différentes. De même, beaucoup de serveurs sont propriétaires rendant les modifications non distribuables. Xlib : dans cette proposition, c est la librairie Xlib qui devrait être modifiée afin de pouvoir stocker l état du client et de le recréer sur un nouveau serveur. Cette approche ne nécessite pas un intermédiaire entre le client et le serveur puisque Xlib serait capable de couper la connexion et d en établir une nouvelle. Mais cela suppose cependant que le client n utilise pas directement la connexion par exemple en faisant appel à la fonction select(). Le choix du pseudoserveur a été fait pour que le déplacement d interfaces graphiques puisse être utilisé avec le plus grand nombre d applications. Ainsi, un pseudoserveur reste en écoute des éventuels clients comme le ferait tout serveur X. Quand il reçoit une connexion d un client, il ouvre une nouvelle connexion sur le serveur et de ce fait joue le rôle d intermédiaire. Comme il reçoit tous les messages du protocole, le pseudoserveur est en mesure d enregistrer et/ou de modifier les informations nécessaires pour implémenter le 18

déplacement de fenêtres. Ceci permet de ne pas modifier les applications existantes. Par contre, le pseudoserveur crée une surcharge supplémentaire dans l échange et le traitement des messages. Ainsi, le fait d implémenter le déplacement de fenêtres sans modifier le client suppose que le pseudoserveur doit prendre en compte les éventuels changements d environnement. De ce fait, toute information dépendant du serveur doit être convertie conformément aux attentes du client et aussi celles du serveur. Les informations dépendant du serveur contiennent des identificateurs de ressources, de couleurs et sont choisis par ce serveur. Un nouveau serveur peut choisir des identificateurs différents, alors tous les messages entre le client et le serveur doivent être vérifiés et éventuellement modifiés conformément aux nouveaux choix. 1.1.2. Les étapes du déplacement de fenêtre Dans une communication normale entre un client et son serveur, xmove joue le rôle d intermédiaire en envoyant les messages de l un à l autre et vice versa. De plus, il stocke les informations sur l état du client qu il ne pourra pas obtenir du serveur. Pour déplacer un client, un programme, xmovectrl, est utilisé. Celui-ci se charge de la communication avec xmove à travers un protocole de contrôle distinct. xmovectrl peut fournir un ensemble de services qui sont : Lister tous les clients qui sont actuellement sous le contrôle de xmove. Déplacer la connexion d un ou de plusieurs clients vers un nouveau serveur. Déplacer les connexions de tous les clients sous le contrôle de xmove vers un nouveau serveur. Ainsi, pour déplacer la connexion d un client vers un nouveau serveur, xmove obtient les informations d état qui n étaient pas stockées à partir de l ancien serveur et se charge de tout recréer sur le nouveau serveur. Xmove établit une connexion avec le nouveau serveur et puis au niveau de ce dernier, il crée les ressources nécessaires telles que les cartes de couleurs, les fontes, les fenêtres. Ces créations de ressources permettent d avoir un affichage correct de l interface graphique ainsi déplacée. Pendant la connexion au niveau du nouveau serveur, xmove peut chercher un autre xmove sur la nouvelle machine. Si un autre xmove a été trouvé alors un chemin pour la communication est mis en place et utilise deux xmoves. Ainsi, les messages du protocole vont utiliser le chemin client-xmove1-xmove2-serveur et vice versa. Le deuxième xmove n est utilisé que pour faire passer les messages sans traitement à effectuer et améliorer ainsi l interface utilisateur avec xmove. Tous les traitements décrits ci-dessus seront effectués au niveau du premier xmove. En faisant passer tous les clients par un deuxième xmove sur la machine du serveur, on peut avoir un enregistrement complet de tous les clients qui ont été redirigés vers le serveur. 19

Cet enregistrement contient des informations telles que le nom du client, la machine où celuici est exécuté. 1.1.3. Conclusion Dans cette section, nous avons étudié xmove, un pseudoserveur, utilisé pour déplacer l interface graphique d une application d un terminal X vers un autre : c est-à-dire que l interface graphique de l application, représentée par une ou plusieurs fenêtres X, qui s affichait sur un écran va l être sur un autre écran. Ainsi, l application qui représente notre client peut changer de serveur et en utiliser un autre se trouvant sur la même machine ou sur une autre. Donc ce sont les messages du protocole X échangés entre le client et le serveur qui seront redirigés. Il s agit alors du transfert de données X qui est fortement lié aux caractéristiques de l écran. Il faut noter aussi qu on ne peut faire appel à xmove que sur les stations sur lesquelles sont installés des systèmes d exploitation utilisant des serveurs X. Le concept développé dans xmove est différent de la redirection de communication que nous voulons prendre en charge. En effet, il ne s agit pas pour nous de déplacer des interfaces graphiques mais de rediriger une ou plusieurs communications d une machine vers une autre. C est la raison pour laquelle, nous présentons dans la section suivante les mécanismes qui sont utilisés dans la téléphonie dans Internet qui est aussi appelée téléphonie IP. Nous y présentons le protocole SIP [RFC3261] qui se présente actuellement comme un standard dans le domaine de la téléphonie dans Internet. 1.2. La téléphonie IP avec SIP Sur Internet, il est possible d envoyer des données telles que du courrier, des images de même qu il est possible d envoyer du son. C est avec le développement des travaux effectués sur la voix sur IP (VoIP : Voice over IP) qu est née la téléphonie IP qui n est rien d autre que la possibilité de téléphoner en utilisant comme support le réseau Internet. Des travaux continuent à être effectués dans ce domaine pour apporter des améliorations dans la communication et permettre aux utilisateurs de bénéficier des mêmes services que dans la téléphonie avec le réseau de télécommunication commuté. C est ainsi que nous avons vu apparaître le protocole d initiation de session (SIP : Session Initiation Protocole) [RFC3261] qui est devenu, pour la signalisation, le standard dans la téléphonie IP. SIP est un protocole de niveau applicatif permettant d établir, modifier et terminer des sessions multimédia et plus particulièrement des sessions téléphoniques. Il fonctionne de manière indépendante par rapport aux couches inférieures (i.e. couche transport, couche réseau). Avec SIP, l utilisateur dispose d une palette de services et nous nous intéressons ici au transfert d appels. En effet, l utilisateur a la possibilité de se connecter sur une machine et recevoir normalement les appels qui lui sont destinés. Ainsi, SIP est capable de localiser les utilisateurs et éventuellement de leur adresser des invitations (i.e. demandes de communication) de la part d autres utilisateurs. 20

1.2.1. L organisation dans SIP Dans un réseau de téléphonie SIP, les numéros sont remplacés par des adresses Internet du type utilisateur@machine où «utilisateur» est un nom d utilisateur ou un numéro de téléphone et «machine» est soit un nom de domaine ou une adresse réseau numérique. L utilisateur est représenté par un agent (User Agent : l agent utilisateur) qui est constitué d une application «client» pour initier des appels en envoyant des invitations et d une application «serveur» qui contacte l utilisateur à l arrivée d une requête et reto urne une réponse. De plus, pour être en mesure de localiser les utilisateurs et d établir les communications, SIP utilise un système qui s apparente au mécanisme de résolution de nom de machine dans Internet avec le serveur de noms (DNS : Domaine Name Server). Ainsi SIP utilise des serveurs tels que : Le serveur mandataire (proxy server) : c est un programme intermédiaire qui joue le rôle de serveur et de client afin d effectuer des requêtes pour le compte d autres clients. Il peut interpréter et si nécessaire réécrire une requête avant de la rediriger. Le serveur de redirection (redirect server) : c est un serveur qui accepte une requête SIP d un client et comme le fait le serveur mandataire, il cherche les informations sur la localisation de l utilisateur à joindre. La différence avec le serveur mandataire est qu après avoir reçu les informations sur la localisation de l utilisateur à joindre, il ne redirige pas la requête vers celui-ci mais se contente tout simplement de retourner ces renseignements au client. Serveur de localisation : ce serveur offre le service de localisation. Celui-ci est utilisé par un serveur mandataire ou de redirection pour obtenir des informations sur la localisation d un utilisateur qu on veut joindre. Cette organisation permet à SIP de localiser les utilisateurs, de leur envoyer des éventuelles invitations téléphoniques et d établir des communications. Quand un client désire envoyer une requête, il doit l envoyer soit au serveur mandataire localement configuré comme dans le cas des navigateurs de pages Web soit à l adresse et au port correspondant à la requête. 1.2.2. Initiation d un appel téléphonique Pour établir une communication téléphonique, l utilisateur initiant l appel (i.e. l appelant) doit envoyer d abord une requête à celui qu il veut joindre (i.e. l appelé). Mais ceci n est pas suffisant pour la mise en place de la communication car il faut, après avoir reçu la requête, que l appelé accepte l invitation. La requête d invitation doit contenir une description de la session écrite par exemple dans le format SDP (Session Description Protocol : Protocole de description de session) [RFC2327] pour fournir à l appelé assez d informations. L initiation de cet appel peut être faite par utilisation soit d un serveur mandataire (figure 4) soit d un serveur de redirection (figure 5) : 21

Utilisation d un serveur mandataire : l appelant envoi l invitation au serveur mandataire qui, par la suite, contacte le serveur de localisation pour avoir des précisions sur la localisation de l utilisateur à appeler. A la réception de la réponse du serveur de localisation, le serveur mandataire envoie une invitation vers l adresse obtenue. L agent utilisateur (sa partie serveur) alerte l utilisateur et retourne une indication de succès au mandataire qui renvoie le résultat à l appelant. La réception de ce message est confirmée par un accusé de réception qui est redirigé vers l appelé. Il est aussi possible que l accusé de réception soit envoyé directement à l appelé sans passer par le serveur mandataire. Utilisation d un serveur de redirection : ce cas est assez proche du précédent vu qu ici le serveur de redirection prend la place du serveur mandataire pour obtenir les informations sur la localisation de l utilisateur à appeler. Mais contrairement au serveur mandataire, le serveur de redirection n envoie pas d invitation mais transmet les informations obtenues à l appelant qui se charge lui -même d envoyer l invitation. Avec ce mécanisme, un utilisateur peut se déplacer d un poste à un autre et pouvoir recevoir ses appels. Ses positions peuvent être enregistrées de manière dynamique et le serveur de localisation pourra communiquer sa position courante si nécessaire soit au serveur mandataire ou de redirection. dpt-info.u-strasbg.fr Service de localisation ushs.u-strasbg.fr cz@ushs.u-strasbg.fr 1: invitation diagne@dpt-info 7: OK diagne@lab 3: 2: diagne Bureau 4: invitation 6: OK 5: sonnerie Labo 8: ACK 9: ACK Figure 4. Exemple de serveur mandataire [RFC3261] 22

ushs.u-strasbg.fr cz@ushs.u-strasbg.fr 1: invitation diagne@dpt-info 4: déplacé diagne@lab 5: ACK dpt-info.u-strasbg.fr Service de localisation diagne@lab 3: 2: diagne Bureau 7: sonnerie 6: invitation diagne@lab.dpt-info.u-strasbg.fr 8: OK 9: ACK Labo Figure 5. Exemple de serveur de redirection [RFC3261] 1.2.3. Déplacement de l utilisateur durant un appel Avec SIP, nous avons vu qu un utilisateur peut initier un appel téléphonique. Supposons qu un utilisateur ait un appel en cours et qu il veuille se déplacer et continuer à recevoir cette communication sur une autre machine. Cet utilisateur doit se connecter sur la nouvelle machine avec son identificateur et envoyer une nouvelle invitation à son interlocuteur. Il s agit du message RE-INVITE de SIP qui va spécifier la nouvelle adresse de l utilisateur. Ce message RE-INVITE permet de changer les paramètres d un appel en cours et l utilisateur peut ainsi changer son adresse. 1.2.4. Conclusion SIP, rappelons le, est un protocole de la couche application qui permet d initier, de modifier et de terminer des sessions multimédia en particulier des sessions téléphoniques. Il permet de disposer de certains services dont le transfert d appels. Mais notons que ceci se passe en général à l établisseme nt de la communication avec un utilisateur qui s est déjà enregistré pour que sa nouvelle position soit disponible au niveau du serveur de localisation. De même, durant un appel, l utilisateur peut se déplacer et recevoir cet appel sur une nouvelle machine. Pour qu un appel en cours soit reçu sur une nouvelle machine, il est nécessaire que 23

l utilisateur se déplace et s y connecte. Ce qui voudrait dire qu il ne serait pas possible de rediriger l appel vers n importe quelle station. Ce service fourni est un peu différent de la notion de redirection de communications que nous voulons définir. En effet, il s agit pour nous de rediriger une ou plusieurs communications existantes vers une nouvelle station sans nécessiter le déplacement de l utilisateur. Cette station pouvant être placée n importe où sur l Internet. De plus, SIP étant situé au niveau de la couche application, les applications existantes ne peuvent pas être utilisées. Pour satisfaire cette transparence par rapport aux applications, il faudrait prendre en charge la redirection des communications dans les couches inférieures (i.e. couche transport, couche réseau). C est la raison pour laquelle, nous présentons dans la section suivante la migration TCP qui propose d utiliser la couche transport. 2. Redirection utilisant la couche transport 2.1. Migration TCP Pour envoyer des informations, une station utilise un port au niveau de la couche transport. Les paquets à transmettre seront destinés à une certaine station (ou un ensemble de stations) et à un numéro de port défini. Ainsi, l émetteur et le destinataire sont identifiés par leur adresse IP et le numéro de port. En général, une station est capable d utiliser un numéro de port unique pour envoyer des paquets à différents correspondants sans que cela nuise à l a bonne marche de la transmission. Seulement, cela serait impossible dans une communication avec connexion. En effet, ce genre de communication met en relation un couple de stations et chaque station étant identifiée par son adresse IP et son numéro de port. Ainsi, l échange de données ne peut avoir lieu qu entre les deux machines et la communication s interrompt si l une des valeurs change. C est ce type de communication que nous avons avec le protocole TCP standard et non avec UDP qui est sans connexion. Ainsi, pour rediriger une communication avec connexion, il faut faire en sorte que le changement de l adresse IP et/ou du port du correspondant soit transparent à l application. c est dans ce sens qu ont été faits les travaux sur la migration TCP [SNO 2000] (TCP Migrate). En effet, la migration TCP permet de déplacer une connexion TCP active vers une autre adresse IP et/ou port TCP de manière transparente à l application. Cette fonction est prise en compte au niveau de la couche transport. Pour éviter l interruption de communication, des options TCP ont été définies permettant ainsi à des machines d établir des connexions capables d être déplacées. Une station fixe ou mobile peut avoir plusieurs interfaces réseaux ou une seule interface dont l adresse change à cause de la mobilité. D un autre côté, un service tel qu un serveur Web peut être dupliqué sur plusieurs stations dans Internet. Les applications, en général, ouvrent une connexion en se servant d un nom résolu par le système de nom de domaine (DNS : Domain Name Service) et si pour une raison ou une autre l adresse IP associée au nom change alors les communications en cours ne peuvent continuer. Les options de la migration TCP ont été définies pour supporter le changement d adresse dû à la mobilité 24

de la station ou à la migration d un serveur vers un autre serveur à cause d une défaillance ou de la surcharge du premier serveur. La migration TCP ne nécessite pas la modification du format de l entête TCP ou celui du paquet transmis. La mise en place d une telle communication se fait avec l utilisation d un mécanisme de cryptographie avec un échange de clés pendant l établissement de la connexion initiale. Il faut noter que l initiateur de la migration est l un des correspondants ou même un nœud tiers déte nant les clés de sécurité. 2.1.1. Principe de la migration TCP Le but de la migration TCP est de pouvoir déplacer une connexion TCP active sans pour autant affecter l application. Ceci a été réalisé avec l introduction de deux nouvelles options : Option migration TCP permise (TCP Migrate-Permitted option) : cette option est utilisée pendant l établissement de la communication initiale. Cette option qui n est envoyée que dans un segment SYN, permet de rendre déplaçable la connexion. Elle contient, dans la version sécurisée de la migration, une clé qui ne sera connue que par les nœuds autorisés à déplacer la connexion. Option migration TCP (TCP Migrate option) : elle est utilisée par une station pour demander la migration d une connexion TCP et l initiateur de ce déplacement est l un des correspondants ou une station tierce disposant de la clé de sécurité. Cette option contient les informations référençant la connexion à déplacer et un champ dont la valeur est calculée en se basant essentiellement sur la clé. Ces options facilitent l association d une connexion TCP avec une nouvelle paire (adresse IP, port TCP) qui n a pas besoin d être connue au début. En bref, les options de la migration TCP permettent aux correspondants de synchroniser deux connexions TCP différentes de telle sorte que le contexte soit identique. L établissement de la deuxième connexion termine la première et transfère le TCB (Tcp Control Block) original, qui contient l état de la connexion, à l exception de l association (adresse IP, port TCP) et de l état de contrôle de congestion. Ces deux connexions apparaissent comme étant des connexions TCP standards à l exception des paquets de signalisation envoyés à l établissement de la connexion et à la demande de migration ; les segments de données sont envoyés sans aucune information supplémentaire. Deux points essentiels dans la migration d une connexion TCP sont la capacité de la connexion d être déplaçable et la demande de la migration de celle-ci. Ainsi pour qu une connexion TCP soit déplaçable, dans la migration TCP, il y a échange d une clé à l établissement de cette connexion. Les correspondants doivent au début commencer par échanger des segments SYN contenant une option migration TCP permise. Cette négociation permettra éventuellement de déplacer la connexion. Seul l un des correspondants ou une autre station disposant de la clé de sécurité pourra initier la migration de la connexion. 25

2.1.2. Migration d une connexion A tout moment après l établissement de la connexion initiale, une station peut tenter de la déplacer et établir une nouvelle connexion. Pour réussir une telle opération il faut tout d abord que la connexion soit déplaçable donc établie comme décrit dans la section précédente et que la station initiatrice de la migration dispose de la clé de sécurité. Si cette station n est pas le correspondant cédant la connexion, elle devra commencer tout d abord par extraire sur celui-ci le TCB avec l état approprié. Pour demander la migration, la station aura à envoyer un segment SYN contenant cette fois une option migration TCP au correspondant ne quittant pas la connexion. Si la requête contient les informations appropriées sur la connexion et respecte la sécurité mise en place alors le correspondant termine la connexion et initialise la seconde avec un TCB identique à la précédente. La nouvelle connexion est associée au même socket (application) que la première. 2.1.3. Application : basculement d un serveur à un autre Une application de la migration TCP est le basculement d un serveur à un autre [SNO 2001]. Ceci consiste à déplacer une connexion d un client sur un serveur vers un autre serveur qui pourrait se trouver n importe où dans l Internet. La raison de ce déplacement de connexion pourrait être la panne ou la surcharge du premier serveur. Ainsi, il faudrait qu un autre serveur puisse prendre le relais et continuer la communication au bon endroit. Serveur A Serveur B Synchronisation Connexion initiale Connexion finale Client Figure 6. Déplacement de connexion sans commutateur Le déplacement de connexion proposé est composé de deux parties : Un protocole de synchronisation de session entre les serveurs. Un mécanisme de reprise de connexion basé sur la migration TCP. 26

Ces deux parties combinées permettent d avoir un basculement de connexion rapide, robuste et transparent à l application du client et largement indépendant des applications des serveurs. L architecture ainsi proposée implique une participation active des couches transport des machines participant dans la communication et ainsi les applications existantes n ont pas besoin d être modifiées pour bénéficier de cette nouvelle fonctionnalité. 2.1.3.1. Protocole de synchronisation de session Le basculement d une connexion a lieu en général quand le client ne reçoit pas de réponse du serveur courant. Ceci peut survenir lorsqu un serveur est soit surchargé, soit en panne ou le chemin vers le client est congestionné. Le système de basculement a donc besoin de détecter ce dysfonctionnement et de sélectionner un serveur pour déplacer de manière appropriée la connexion. Ainsi, il est placé sur chaque serveur un agent, surveillant d état (health monitor), qui veille sur l état et la charge des serveurs. Chaque connexion est associée avec un ensemble de serveurs dans le système. Cet ensemble de serveurs est appelé groupe de support. Le groupe de support est collectivement responsable du fonctionnement correct de la connexion. L enregistreur de séquences analyse la requête d objet initiale et, pour cette connexion, informe les autres membres du groupe de support sur les données actuellement transmises au client et les informations sur l état de la couche transport. Cette annonce se fera périodiquement par la suite. Quand le surveillant d état détermine qu une connexion doit être déplacée alors chacun des autres serveurs du groupe de support de la connexion devient un serveur candidat. Le nouveau serveur est choisi de manière décentralisée par le client. Le nouveau serveur pouvant être le serveur le plus proche ou le serveur ayant contacté le premier le client. 2.1.3.2. Mécanisme de reprise de connexion Une fois qu une connexion a été désignée comme devant être déplacée et que le nouveau serveur a été choisi, l application du client doit continuer à s exécuter correctement et sans interruption. Ceci est possible si la transmission de données reprend exactement à l endroit où cela s était arrêté avec l ancien serveur. Pour cela, l état de la couche transport doit être déplacé et l état de la couche application synchronisé et la transmission reprise de manière appropriée. L approche qui a été retenue est l utilisation d un mécanisme indépendant aux applications qui n est rien d autre que le mécanisme de migration de connexion de niveau transport. L avantage de cette approche est que les applications existantes peuvent en bénéficier sans modification et que les nouvelles applications n ont pas à incor porer leurs propres mécanismes pour arriver au même but. Ainsi avec la migration TCP, un serveur initie le déplacement d une connexion en contactant le client sur la même connexion. S il reçoit un accusé de réception de niveau transport du client alors il sait qu il est le serveur candidat sélectionné par le client. Ayant reçu du client cet accusé de réception contenant les informations sur les données attendues et ayant été préalablement informé par le protocole de 27

synchronisation de session du groupe de support sur le contenu de la communication, la transmission peut être reprise à l endroit requis. 2.1.4. Conclusion Dans cette section nous avons étudié un mécanisme de déplacement de connexion TCP, la migration TCP. Elle offre la possibilité de déplacer une connexion TCP d une station vers une autre de manière transparente à la couche application. En effet presque tous les traitements ont lieu au niveau de la couche transport avec l ajout de deux options. La première option qui est utilisée à l établissement de la connexion permet de rendre déplaçable celle-ci. L autre option est utilisée au moment où l on décide de déplacer la connexion et elle permet de demander sa migration. Ceci fait apparaître la connexion mise en place comme une connexion TCP standard puisque aucune information supplémentaire n est ajoutée dans les segments de données. Nous avons aussi étudié précédemment une application qui pourrait être faite de la migration TCP qui consiste à déplacer une connexion TCP d un serveur à un autre si le client ne recevait plus de réponse du premier serveur dû à une surcharge ou une panne de ce serveur ou à une congestion sur la route vers le client. Ce mécanisme pourrait être utilisé pour permettre à l utilisateur de rediriger une communication utilisant le protocole TCP. Cependant, dans nos travaux, nous nous intéressons essentiellement aux transmissions UDP car, comme nous l avons précisé dans l introduction, nous visons principalement les applications sans persistance telle que la vidéoconférence. Ce type d application fait le plus souvent appel au protocole UDP. 3. Analyse des besoins des protocoles et applications dans la redirection de communications Dans cette section, nous faisons une synthèse des solutions proposées dans le domaine de la redirection des communications que nous avons décrites précédemment. Puis, nous nous efforçons de recenser les différents points qu il faudrait prendre en compte pour pouvoir proposer un protocole qui soit le plus générique possible. 3.1. Synthèses des différentes solutions proposée Dans ce chapitre, nous avons étudié des travaux qui représentent des propositions dans le domaine de la redirection de communications. Ils sont présentés dans la table 1. Les caractéristiques que nous avons relevées sont : La couche utilisée : il s agit de la couche au niveau de laquelle les fonctions de redirection ont été implémentées. L utilisation de la couche application implique, dans la plupart des cas, la modification des applications existantes pour qu elles prennent en compte ces fonctions (excepté avec Xmove : voir plus loin). La prise en charge de ces fonctionnalités dans les couches 28