Mobile Cloud, Cloud Mobile et Contrôle de la Mobilité (PDF)

Mobile Cloud, Cloud mobile et contrôle de la mobilité Dr. Bouamama Samah 2023/2024 1 Introduction Le mobile Cloud est une solution qui a pris un fort impact dans le cadre des réseaux de mobile. L’élément de base est le terminal mobile qui s...

Mobile Cloud, Cloud mobile et contrôle de la mobilité Dr. Bouamama Samah 2023/2024 1 Introduction Le mobile Cloud est une solution qui a pris un fort impact dans le cadre des réseaux de mobile. L’élément de base est le terminal mobile qui se déplace et qui demande des services à un Cloud qui lui est fixe. Le « mobile cloud » fait généralement référence à l’utilisation de services de cloud computing (stockage, calcul, etc.) via des appareils mobiles tels que des smartphones ou des tablettes.Il s’agit d’un modèle où les utilisateurs accèdent aux ressources cloud à partir de leurs appareils mobiles pour stocker, gérer et traiter des données. Les applications mobiles peuvent également utiliser des services cloud pour offrir des fonctionnalités telles que la sauvegarde automatique des données, la synchronisation entre appareils, le streaming de contenu, etc. Le « cloud mobile » peut faire référence à une infrastructure cloud conçue spécifiquement pour prendre en charge les besoins des applications mobiles. Cela peut inclure des services de cloud computing optimisés pour les applications mobiles, tels que des bases de données mobiles, des API de notification push, des services de gestion de l’identité, etc. L’objectif du « cloud mobile » est de fournir une infrastructure cloud adaptée aux besoins uniques des applications mobiles, notamment en termes de scalabilité, de latence faible et de gestion des utilisateurs mobiles. 2  Plan 1. Le mobile Cloud 2. Cloudmobile 3. Les contrôleurs de terminaux mobiles 4. Les protocole de la mobilité 5. Contrôle de la mobilité 1. IP mobile 2. Solutions pour la micro mobilité 6. Le Multihoming 7. Multihoming de niveau réseau 1. HIP (Host Identity Protocol) 2. SHIM6 (Level 3 Multihoming Shim Protocol for IPv6) 3. mCoa (Multiple Care of Addresses registration ) dans Mobile IPv6 8. Multihoming de niveau transport 1. SCTP Stream Control Transmission Protocole 2. CMT concurrent multipath transfer 3. MPTCP multi path top. 3 Réseau GSM 4 Le mobile Cloud La définition exacte du mobile Cloud Computing est très controversée puisqu’il n’y a pas de vraie définition et pas d’architecture claire. Deux principales orientations dominent le mobile Cloud : Une orientation application permettant à un équipement mobile avec des ressources limitées de prendre en charge des applications demandant des calculs intensifs ou une mémoire plus importante que celle du terminal ; Une orientation réseaux permettant de prendre en charge l’optimisation d’algorithme pour le contrôle des services mobiles. 5 Le mobile Cloud Orientation application: on peut citer diverses applications qui correspondent à ce cadre par exemple les applications de type mobile riche (Rich Mobile Application (RMA) ), les jeux mobile dans le Cloud ou mobile Cloud gaming ou encore MCaaS (Mobile Cloud as a service), la réalité augmentée ou encore les applications mobiles avec des calculs intensifs comme l’OCR (Optical Character Recognition) l’utilisation de langage naturel. 6 Le mobile Cloud Orientation réseau: on peut trouver par exemple les firewall pour des équipements mobiles, le contrôle des Handover ou encore la gestion des mouvement des terminaux mobiles. 7  Le mobile Cloud vs Cloud Mobile Le cloud mobile se concentre sur l'utilisation du cloud depuis des appareils mobiles (exp: stockage automatique de nos photos sur Google et l’accès depuis n’importe quel périphérique), Tandis que le mobile cloud se concentre sur la fourniture de services cloud à partir d'appareils mobiles (exp :WhatsApp, Netflix,…). En résumé, le "Cloud Mobile" met l'accent sur l'utilisation du cloud computing pour améliorer les applications mobiles, tandis que le "Mobile Cloud" met l'accent sur l'accès aux services cloud à partir d'appareils mobiles. 8 Le mobile Cloud Les architectures pour le Cloud mobile regroupent les différentes classifications que nous avons introduites: le Cloud Computing pour des terminaux mobiles, le Cloud Computing local, le Cloud Computing virtuel ou encore les Cloud. 9  Le mobile Cloud La première architecture : montre un terminal mobile de type smartphone qui se sert d’un Cloud centrale pour prendre en charge un certain nombre d’applications. Ces applications sont caractérisés par une puissance de calcul forte, un besoin de mémoire très important où l’utilisation de ressources spécifiques qu’ils ne peuvent pas être mise dans le smartphone comme un entrepôt de données de type Big Data. Architecture du mobile Cloud 10 Le mobile Cloud Les communications entre le smartphone et le Cloud doivent rester raisonnable pour que l’interface sans fil puisse les prendre en compte sans problème. En résumé, le terminal est une machine légère qui demande au Cloud d’effectuer les processus lourd. 11  Le mobile Cloud La seconde architecture : le Cloud n’est plus central mais local ou du moins pas trop loin de l’utilisateur. Les ressources peuvent se trouver dans les autres équipements mobiles qui sont connectés sur le Cloud. Les équipements mobiles peuvent éventuellement former par eux-mêmes un Cloud. En d’autres termes, les terminaux mobiles des voisins s’ils sont inactifs, peuvent parfaitement servir pour effectuer du calcul, du stockage, voire même du Une architecture de mobile could local réseau dans cet environnement. 12 Le mobile Cloud Ce Mobile Cloud se construit à partir de machines connectées et éventuellement d’un Datacenter local qui peut être fortement local avec des Micro Datacenter ou Nano Datacenter ou Pico Datacenter ou même des Femto Datacenter. Globalement le petit Datacenter peut se situer au niveau du DSLAM (Digital Subscriber Line Access Multiplexer) du routeur d’accès ou même de la Home Gateway. 13  Le client avec sa machine mobile souhaite se connecter Le mobile Cloud à tout ensemble de Cloud pour couvrir tous les services dont il a besoin. Comme un Cloud seul est en général insuffisant pour contenir tous les services nécessaires d’un utilisateur, il doit demander la connexion à plusieurs fournisseurs de Cloud pour obtenir les services dont il a besoin. Comme il peut être fastidieux et complexe de connaître toutes les solutions, une possibilité est de s’adresser à un intermédiaire qui lui-même a une connaissance de tous les Cloud. Troisième architecture du mobile Cet intermédiaire est capable à tout instant de chercher Cloud avec Cloud Virtuel le meilleur fournisseur de Cloud pour une application 14 donnée. Le mobile Cloud Le Cloud est virtuel puisqu’il est représenté par une machine virtuelle intermédiaire capable de mettre le client en relation avec le meilleur Cloud pour obtenir son application. Un autre Cloud donné à cette solution est le Sky et l’intermédiaire est un fournisseur de Sky. Une des difficultés pour le fournisseur de Sky est l’intermédiation avec des clients qui peuvent être très différents les uns des autres mais que l’utilisateur final défini de la même façon. 15  Le mobile Cloud la quatrième architecture : Cloud mobile concerne également l’utilisation d’un petit Cloud, un Cloudlet, mais qui se déplace avec le client. Dans les faits, ce n’est pas le Cloud qui se déplace mais c’est la connexion à différents Cloudlet qui donne l’impression que le Cloud se déplace avec le client. A chaque Handover, le terminal mobile se rattache à un nouveau Cloudlet et les machines virtuelles du client se déplacent vers le nouveau petit Datacenter. Un Cloudlet est un concept de petits Cloud situé dans une zone à très forte demande. le fournisseur de mobile Cloud assigne le Cloud le Quatrième architecture du mobile Cloud plus apte à répondre rapidement à la demande de service du client qui se déplace. 16 Le mobile Cloud Les limites du Cloud Computing Mobile (CCM) Les applications basées sur le Cloud ne donnent des meilleures performances qu’avec des réseaux à une grande vitesse de connectivité. L’inconvénient majeur de ces approches est que le Cloud (datacenter) est physiquement loin de l’utilisateur final ce qui créé plusieurs problèmes liés au réseau WAN utilisé pour la communication comme : la latence, les erreurs de transmission, la congestion,...etc. Le paramètre critique dans ce genre d’application est la latence parce qu'elle dépend de la distance entre le mobile et le Cloud. Les travaux dans les réseaux actuels visent à améliorer : la bande passante, la sécurité, la consommation d’énergie, etc; et les techniques utilisées impactent négativement la latence. Pour pallier à ce problème, on utilise les Cloudlets. 17  L’architecture des Cloudlets Peut-on obtenir les avantages du Cloud computing sans être limité par un réseau WAN ? Comme illustré dans la figure ci-dessous, cette architecture est composée de trois entités : Les plates-formes, la cloudlet (cloud local) et le cloud distant (datacenter). 18  L’architecture des Cloudlets La Cloudlet est définie par le terme « Datacenter in a box » qui se trouve dans des endroits désignés et qui est connecté au Cloud via Internet. E lle ressemble à un cluster d'ordinateurs multi-cœurs, avec une large bande passante LAN sans fil. Ainsi, les appareils mobiles sont physiquement proches de la Cloudlet et ils peuvent fonctionner comme des clients alors que tout le calcul et le traitement intense se passe via la Cloudlet. Le dispositif mobile serait relié à la Cloudlet par une connexion sans fil à un saut (One-hop communication) ce qui garantit un temps de réponse très rapide et une meilleure interactivité. Dans le cas où aucune Cloudlet proche n’est disponible, le mobile peut changer son mode à un autre qui invoque un Cloud distant ou dans le pire cas il va faire le traitement avec ses propres ressources. Les meilleures performances peuvent retourner une fois le mobile découvre une Cloudlet proche. 19  L’architecture des Cloudlets Quelques points de différences avec le Cloud classique 20  Résumé du mobile Cloud Les architectures de mobile Cloud sont fondées sur une hiérarchie de Cloud pour optimiser différents critères : Performance et fiabilité des applications pour les mobiles ; Performance des applications de contrôle pour les mobile ; Minimisation de la consommation d’énergie ( l’équipement terminal, Datacenter…) ; Disponibilité ; Haute-sécurité : M-commerce, m- Cloud Access, m-Payment. Les différentes architecture que nous avons décrites peuvent être mixées pour répondre à l’optimisation des critères décrit ci-dessus. On retrouve la hiérarchie de Datacenter allant du gros Datacenter au minuscule Datacenter (femto Datacenter). Les optimisations de ces environnements ne sont pas simple même si parfois l’architecture est relativement bien défini. Le futur est souvent synonyme de Cloud qui se forme facilement et qui se transforme tout aussi facilement et qui commence à devenir porteur sous le vocabulaire de Cloud mobile que nous allons aborder. 21 Cloud mobile Le Cloud mobile fait référence à un ensemble de petits Datacenter qui une fois connectés forment un Cloud. La difficulté provient de la mobilité des Cloudlet et de la diversité des mobilités, de telle sorte que les Cloudlet peuvent se solidariser et se désolidariser. Si l’ensemble des Cloudlet ou mini Datacenter se déplacent simultanément, il s’agit d’un réseau VANET (vehicular area network) qui va supporter le Cloud mobile. 22 Cloud mobile En revanche, si les mobiles qui transportent les mini Datacenter se déplace sans accord, le Cloud mobile a plus de difficulté à se former et à se mobiliser en fonction des déplacements. Un Cloud mobile où chaque véhicule à son propre femto Datacenter. 23 Cloud mobile Les communications entre Datacenter s’effectue par l’intermédiaire d’un réseau mesh ou ad hoc. Un réseau ad-hoc concerne le cas où les femto Datacenter sont dans le même équipement que la carte de communication avec les autres machines possédant des Datacenter. Dans le cas d’un réseau mesh , il y a un réseau spécifique qui fait la liaison entre les femto Datacenter. Ce réseau possède des nœuds avec deux carte de communication, l’une pour se connecter avec des clients et les femto Datacenter et l’autre avec les nœuds du réseau mesh. 24 Cloud mobile Dans le cas d’un réseau mesh le véhicule détient un boîtier qui est uniquement destiné à la communication entre véhicules. Les équipements du véhicule, (choses) objet ou tout autre équipement, sont connectés sur le boîtier mesh. Le boîtier à deux cartes de communication, une pour la connexion des équipements interne ou externe au véhicule (capteurs, caméras,…) et une deuxième carte pour la communication entre boîtiers. Dans le cas des réseaux ad-hoc, ils permettent de connecter les objets ou autre équipements directement entre eux. Cette solution n’est pas défendue par les opérateurs, car l’équipement de l’utilisateur doit intégrer des équipements de réseau pour réaliser la communication. De plus, ces équipements peuvent être perturbés par les applications utilisateurs qui tournent sur la même machine. 25  Cloud mobile Un exemple de Cloud mobile est décrit à la figure suivante où l’ensemble de véhicule va approximativement à la même vitesse, ce qui permet au Cloudlet de se connecter simplement à des vitesses acceptable pour réaliser un Cloud global. Dans les faits il y a deux Cloud mobiles en fonction de la direction des véhicules. 26 Cloud mobile Un Cloud mobile important peut se mettre en place lors d’un embouteillages comme celui décrit à la figure, lorsque des centaines de véhicules sont rassemblés, la puissance globale peut devenir consistante. Les véhicules doivent être connectés en réseau mesh avec des protocoles spécifiques, type OLSR, pour permettre le routage entre les véhicules. 27  Les contrôleurs de terminaux mobiles La mobilité est complexe à contrôler, car les décisions doivent essentiellement être prises en temps réel et le déplacement ne permet pas de s’adresser à des organes puissants comme les Datacenter qui sont situés trop loin de la périphérie sauf éventuellement à considérer de nouvelles technologies comme le C-RAN dans laquelle toute la boucle locale est à reconsidérer pour la remplacer par une étoile optique. Sauf exception, il faut déporter les décisions vers les extrémités et cette délocalisation s’effectue dans des contrôleurs locaux. Nous retrouvons la problématique du SDN à la périphérie. Le protocole OpenFlow peut jouer un rôle important entre le client et le contrôleur. 28 Les contrôleurs de terminaux mobiles Deux types de contrôleurs peuvent se rencontrer, les contrôleurs de bas niveau et les contrôleurs de haut niveau. Le bas niveau s’occupent des couches basses :Le réglage de la fréquence, de la puissance et des adaptations des couches physique et liaison, c’est-à-dire des niveau 1 et 2. Ces contrôleurs peuvent également gérer certains types de sécurisation comme détecter les points d’accès pirate. Les contrôleurs de haut niveau sont associés au contrôleur SDN. Ils sont capables de prendre en charge les propriétés décrites à la figure suivante. 29 Les contrôleurs de terminaux mobiles Mots de passe prêt à l’emploi et paiement en ligne Configuration zéro Authentification et zéro assistance des utilisateurs et technique des terminaux Gestion des log de Gestion de profil et l’accès et du trafic contrôle d’accès Propriétés des contrôleurs des équipements mobiles 30 Les contrôleurs de terminaux mobiles Ces propriétés contiennent l’authentification des utilisateurs par une technique quelconque avec la récupération d’un nombre maximal de caractéristiques de l’utilisateur et de ses applications. La raison de cette moisson d’informations et de permettre un contrôle de type SDN directement exercer par le contrôleur local ou de transmettre ces informations vers un contrôleur SDN centrale. Les caractéristiques de l’utilisateur sont souvent couplées avec une base d’informations qui est mise à jour régulièrement. 31 Les contrôleurs de terminaux mobiles La deuxième grande propriété est de déterminer le profil de l’utilisateur soit en récupérant les informations lors de l’authentification soit en associant l’utilisateur à un profil déjà connu. Ce profil permet de déterminer les applications qui peuvent être mise en route et donc permettre un contrôle d’accès en fonction des demandes de l’utilisateur. Exemple: dans le profil de l’utilisateur est indiqué si celui-ci a le droit d’accéder à Internet uniquement par HTTP ou non, s’il a le droit de faire de la VoIP, s’il peut envoyer un message électronique, s’il peut utiliser une imprimante locale, etc. 32  Les contrôleurs de terminaux mobiles La troisième propriété des contrôleurs concerne la gestion et le contrôle des flots utilisant le protocole de type OpenFlow ou un autre protocole plus classique. Le contrôleur doit également être capable de satisfaire à des demandes obligatoires des états comme garder en mémoire les logs des clients qui se connecte sur le contrôleur. 33 Les contrôleurs de terminaux mobiles Les deux derniers ensembles de propriétés concernent la gestion de la connexion d’une part en apportant les éléments nécessaires pour réaliser une zéro configuration : Le contrôleur est capable de se substituer au terminal mobile pour fournir des propriétés particulières. Exemple, le contrôleur peut intercepter les messages électroniques d’un utilisateur pour les envoyer par son propre SMTP sachant que le réseau sur lequel est connecté le Mobile n’accepte pas les messages de l’utilisateur qui visite l’entreprise. Un autre exemple est celui de l’utilisation d’une imprimante par un portable. Le contrôleur peut charger un driver virtuel et permettre au mobile de réaliser une impression local. Enfin, le contrôleur peut gérer des solutions pour permettre à l’utilisateur d’employer des mots de passe pour se connecter sur le point d’accès. 34 Les contrôleurs de terminaux mobiles Si l’on examine plus spécifiquement l’authentification, la méthode la plus classique est une fenêtre sur laquelle le client entre son login et son mot de passe en utilisant par exemple le standard IEEE 802.11 X. Une autre solution concerne l’accès par une authentification sur un autre site comme Google ou Facebook ou sur un serveur de paiement. Une fois l’authentification réalisée à l’extérieur, un protocole spécifique comme OAuth permet de faire remonter l’authentification au niveau du contrôleur. Une dernière solution peut être de demander à l’utilisateur de remplir une page de renseignements pour obtenir le droit d’accès. 35 Les contrôleurs de terminaux mobiles Il est à noter que dans les deux derniers cas de figure, le client doit être capable de se connecter au réseau sans authentification. Le point d’accès doit donc le laisser passer sur une autorisation spécifique et provisoire du contrôleur. Cette solution est souvent une option des systèmes d’authentification. Elle est cependant assez dangereuse car une fois authentifier sur un serveur externe, le client peut continuer à naviguer sans revenir à une authentification ferme sur le contrôleur local. 36  Les contrôleurs de terminaux mobiles La figure suivante présente les deux solutions pour des contrôleurs applicatifs, le premier est physique et le second virtuel. L’avantage du contrôleur virtuel est d’utiliser les ressources nécessaires à tout moment, c’est-à-dire beaucoup de ressources aux heures de pointe et quasiment aucune ressource lors des périodes creuses. 37 Les contrôleurs de terminaux mobiles La figure suivante décris les différents cas de figure pour obtenir une authentification d’accès sur l’Internet en passant par un point d’accès et un contrôleur de point d’accès. Les cas d’autorisation d’accès pour un contrôleur 38 Les contrôleurs de terminaux mobiles Le cas 1 correspond à un accès du client vers un site d’authentification externe. Il obtient une authentification provisoire pour franchir le point d’accès et aller se faire authentifier ou reconnaître sur un site externe qui peut être situé n’importe où dans l’Internet. Une fois cette authentification réalisée, elle est retransmise au contrôleur qui envoie l’ordre au point d’accès de laisser passer le client. 39  Les contrôleurs de terminaux mobiles le cas 2 est celui que permet une solution avec un contrôleur SDN. Le point d’accès externe à l’arrivée d’un Flot, envoie une demande au contrôleur SDN qui commence par authentifier le client sur un portail captif ou en utilisant une autre solution authentification. Une fois l’authentification réalisée, le contrôleur donne l’ordre au point d’accès en lui spécifiant le flot à laisser passer. le client peut alors accéder à l’Internet. 40  Les contrôleurs de terminaux mobiles Le cas 3 est celui d’un contrôleur physique local qui après authentification local permet la communication du client à l’Internet par le point d’accès. Le contrôleur IEEE 802.1x est facilement utilisable dans cette solution. 41 Les contrôleurs de terminaux mobiles Le cas 4 représente la solution où il faut accéder au contrôleur central qui après authentification et consultation du profil laisse entrer le client dans le réseau Internet. 42 Les protocoles de la mobilité la convergence fixe/ mobile permet à toute application installée sur un serveur d’être utilisé à partir d’un équipement fixe ou mobile. La première condition pour arriver à cette convergence est qu’un mobile puisse rester connecté sur le réseau en mobilité sans que cela interrompe le déroulement de l’application. Les changements intercellulaires (Handover) doivent se dérouler de façon transparente et sans coupure c’est-à-dire en gardant la même qualité de service si l’application le nécessite. 43  Les protocoles de la mobilité La Macromobilité, permet de gérer la mobilité des terminaux entre des domaines IP différents, et la Micromobilité, qui concerne le changement de points d’attachement dans un même domaine IP. Dans le premier cas, le principal protocole est IP mobile, dans le second, plusieurs protocoles sont en compétition. Le Multihoming , c’est-à-dire le cas où un terminal est connecté simultanément à plusieurs réseaux. 44 Contrôle de la mobilité 2 grands types de solutions de contrôle de la mobilité dans les réseaux IP en été mis en place en fonction du déplacement du mobile :le support de la macro mobilité et celui de la micro mobilité. Dans le premier cas, le mobile change de réseau IP tandis que, dans le second ils restent dans le même réseau, mais change d’antenne de rattachement. La macro mobilité et prise en charge par le protocole IP mobile. Pour La micro mobilité, de nombreux protocole on été défini. 45 IP mobile Le protocole IP est de plus en plus souvent présentée comme une solution pour résoudre les problèmes posés par les utilisateurs mobile. Le protocole IP mobile peut être utilisé sous IPv4, mais le manque d’adresse potentiel complique la gestion de la communication avec le mobile. IPv6 est préférable, du fait de son grand nombre d’adresses disponibles, qui permet d’attribuer des adresses temporaires aux stations en cours de déplacement. 46  IP mobile Le fonctionnement d’IP mobile est le suivant : Une station possède une adresse de base, avec un agent qui lui est attaché et qui a pour rôle de suivre la correspondance entre l’adresse de base et l’adresse temporaire. Lors d’un appel vers la station mobile, la demande est acheminée vers la base de données détenant l’adresse de base. Grâce à l’agent, il est possible d’effectuer la correspondance entre l’adresse de base et l’adresse provisoire et d’acheminer la demande de connexion vers le mobile. Cette solution est semblable à celle utilisé dans le réseau de mobiles. 47  IP mobile La technologie employé dans IP mobile est la suivante : Mobile Node, ou nœud mobile : terminal ou routeur qui change son point d’attachement d’un sous-réseau à un autre sous-réseau, Home Agent, ou agent home : routeur du sous-réseau sur lequel est enregistré le nœud mobile, Foreign agent ou agent Foreign : routeur du sous-réseau visité par le nœud mobile. 48 IP mobile L’environnement IP mobile est Formé de trois fonctions relativement disjointes : La découverte de l’agent (agent Discovery) : lorsque le mobile arrive dans un sous-réseau il recherche un agent susceptible de le prendre en charge, L’enregistrement : lorsqu’un mobile est hors de son domaine de base, il enregistre sa nouvelle adresse (Care of address ) auprès de son agent home. Suivant la technique utilisée, l’enregistrement peut s’effectuer soit directement auprès de l’argent home, soit par l’intermédiaire de l’argent foreign. Le tunneling : lorsqu’un mobile se trouve en dehors de son sous-réseau, les paquets doivent lui être délivrée par une technique de tunneling qui permet de relier l’argent à l’adresse care of address. 49 IP mobile IP Mobile pour IPv4 50 IP mobile IP Mobile pour IPv6 51 Solutions pour la micro mobilité Plusieurs protocoles on été proposés par l'IETF pour la gestion de la micro mobilité afin d’améliorer IP mobile. En effet, les solutions de micro mobilité visent principalement à réduire les messages de signalisation et la latence du Handover introduite par les mécanismes d’IP mobile. Généralement, on distingue deux catégories d’approches pour La micro mobilité : celle qui s’appuyer sur les tunnels et celle qui recourent à des tables de routage. 52 Solutions pour la micro-mobilité Les approches par tunnels utilisent un enregistrement local et hiérarchiques. Elles utilisent pour cela les protocoles IDMP (intra Domain mobility management protocol), HMIPv6 (Hierarchical MIPv6 ) et FMIPv6 (Fast MIPv6). HMIPv6 est un schéma hiérarchique qui différencie la mobilité locale de la mobilité global. Il a pour avantages l’amélioration des performances du handover, puisque les handovers locaux sont effectués localement, et de la vitesse de transfert, tout en minimisant la perte de paquets qui peut survenir pendant les transitions. HMIPv6 réduit considérablement la charge de signalisation de la gestion de la mobilité sur Internet puisque les messages de signalisation correspondant à des mouvements locaux ne traversent pas l’ensemble d’Internet, mais reste confinés sur le site. 53 Solutions pour la micro mobilité FMIPv6 a pour objectif de réduire le délai de latence du handover en comblant les lacunes de MIPv6 en matière de temps de détection du mouvement du mobile et l’enregistrement de la nouvelle adresse temporaire, mais aussi grâce à des handover par anticipation et par tunnel. 54 Solutions pour la micro mobilité Les approches fondée sur les tables de routage consistent à maintenir les routes spécifiques au host dans les routeurs pour transférer les messages. Cellular IP ou HAWAII (Handoof-Aware Wireless Access Internet Infrastructure) sont deux exemples de protocoles de micro mobilité utilisant des tables de routage. 55 Le multihoming Le multihoming consiste pour un terminal à se connecter à plusieurs réseaux simultanément afin de permettre d’optimiser les communications en prenant le meilleur réseau ou en permettant à une application de prendre plusieurs chemins et donc aux paquets d’un même message de prendre plusieurs chemins simultanément. À un peu plus long terme, un terminal sera connecté sur plusieurs réseaux et chaque application pourra choisir son ou ses réseaux de transport. Le terme multihoming renvoie aux multiples 《home》qu’un terminal peut avoir , chaque home pouvant donner au terminal sa propre adresse IP. Le terminal dois donc gérer les différentes adresses IP qu’il reçoit. 56 Le multihoming Le multihoming permet de disposer de plusieurs connexions simultanées à différents réseaux d’accès. Un terminal multihomé est définie comme un terminal qui peut être atteint via plusieurs adresses IP. On distingue trois cas de figure. 57  Le multihoming Une seule interface et plusieurs adresses IP: C'est le cas d'un terminal dans un site Multihomé. Chaque adresse IP du terminal appartient à un fournisseur d'accès différent. Cette configuration a pour objectif d'augmenter la fiabilité ou d'optimiser les performances en utilisant l'ingénierie du trafic ; Plusieurs interfaces, une adresse IP par interface: Le terminal possède plusieurs interfaces physiques et chaque interface a seulement une adresse IP. C’est le cas du terminal mobile multi-interface. Les interfaces peuvent avoir différentes technologies d’accès et être connectées à différents réseaux. Chaque interface obtient une adresse IP fournie par son propre réseau ; Plusieurs interfaces, une ou plusieurs adresses IP par interface: C’est le cas le plus général. Le terminal dispose de plusieurs interfaces physiques, dont chacune peut recevoir une ou plusieurs adresses IP attribuées par les réseaux attachés. 58 Le multihoming Il existe deux approches principales pour le multihoming: l’une utilisant le protocole de routage BGP (Border Gateway protocole); une utilisant le mécanisme de translation d’adresse (Network Address Translation). Ces solutions se font sur le routage du réseau et les techniques de gestion de l’adresse afin de fournir une grande facilité de connexion et une amélioration des performances. 59 Le multihoming Les premiers protocoles de multihoming se sont placés au niveau transport avec SCTP (Stream Control Transmition Protocol)et ses extensions. Au niveau réseau, SHIM6 (level 3 Multihoming Shim Protocole For IPv6) et HIP (Host Identity Protocol) sont les deux protocoles supportant le multihoming normalisés à l’IETF. 60  Le multihoming Une autre manière de concevoir des protocoles de multihoming pour le terminal mobile consiste à développer le protocole de transmission multi chemin à partir du protocole de transmission mono chemin. C’est le cas de l’enregistrement multiple des adresses lors de la mobilité, adresses que l’on appelle Care of Address (mCoA) et MPTCP (Multipath TCP). mCoA est une évolution de mobile IPv6, qui permet d’enregistrer plusieurs adresses temporaires (CoAs) sur un même terminal mobile. Cette solution définit un identifiant d’enregistrement qui a pour objectif de distinguer les CoA d’un même terminale. MPTCP est une extension récente de TCP pour prendre en charge la transmission de données par plusieurs chemins simultanément. Une connexion MPTCP est composée de plusieurs connexions TCP. 61  Le multihoming Les objectifs d’un protocole de multihoming pour un terminal mobile multi interface sont les suivants : Les chemins disponibles doivent être simultanément utilisés pour permettre une augmentation de la bande passante; L’algorithme de partage de charges qui distribue les données sur plusieurs chemins doit assurer que la bande passante total soit au moins égale à celle obtenue sur le meilleur chemin; L’utilisation de plusieurs chemins doit renforcer la fiabilité de la communication; Le protocole du multihoming doit supporter la mobilité en traitant des problèmes de Handovers horizontaux (inter-BS ) et verticaux (handover inter-RAT ); Les interfaces de différentes technologies d’accès doivent fournir aux utilisateurs une meilleure couverture radio. 62 Multihoming de niveau réseau 3 protocole prennent en charge le multihoming au niveau réseau : HIP(Host Identity Protocol) SHIM6(Level 3 multihoming SHIM Protocol for IPv6) MCoA (Multiple Care of Addresses registration). 63 Multihoming de niveau réseau Dans un réseau IP, l’adresse IP est utilisée à la fois comme l’identifiant du terminal et le localisateur du terminal. Nous avons déjà rencontré cette propriété dans le cas du protocole LISP. Cette double fonctionnalité de l’adresse IP pose des problèmes dans l’environnement Multihomé. En effet, chaque terminal possédant plusieurs adresse IP associées à ses interfaces, un terminal est représenté par plusieurs identifiants. Dans la mobilité , lorsque le terminal se déplace en dehors de la zone de couverture d’une technologie , il bascule vers l’interface d’une autre technologies. La communication et alors interrompue , car les couches supérieur pensent que les différents identifiants représentent différents terminaux. La transmission simultanée de données par plusieurs chemins est impossible puisque les chemins ne sont pas considéré comme appartenant aux mêmes terminal. 64 Multihoming de niveau réseau HIP et SHIM6 proposent de séparer les deux fonctions de l’adresse IP afin de supporter le multihoming. Une couches intermédiaire et ajouter entre la couche réseau et la couche transport. Cette couches permet de différencier l’identifiant et l’adresse du nœud. L’identifiant ne dépend plus du point d’attachement du nœud. Bien que le nœud ait plusieurs adresse, il est présentée par un identifiant unique aux couches supérieures. Lorsqu’une adresse du nœud n’est plus valable, l’identifiant est associé à une autre adresse. La couche intermédiaire s’occupe de la liaison entre l’identifiant et l’adresse. De ce fait, le changement de l’adresse devient transparent pour les couches supérieures, lesquelles s’associent seulement à l’identifiant. 65 Multihoming de niveau réseau HIP Host Identity Protocol HIP est une approche qui sépare totalement la fonction d’identifiant de la fonction de localisation de l’adresse IP. Il propose de nouveaux identifiants cryptographiques Host Identity (HIP) aux terminaux. Dans l’architecture de HIP, HI est l’identifiant du terminal présenté aux couches supérieure, tandis que l’adresse IP ne joue que le rôle de l’adresse topologique, comme indiqué dans la figure Application Application TCP TCP Architecture de HIP HIP IP IP Physique Physique 66 Multihoming de niveau réseau HIP Host Identity Protocol Une nouvelle couche nommée HIP est ajoutée entre les couches réseaux et transport. Cette couches HIP s’occupe de faire la correspondance entre HI et l’adresse IP active du terminal. Lorsqu’un terminal change d’adresse IP grâce à la mobilité ou au multihoming, HI reste fixe pour fournir le support de la mobilité et du multihoming. 67 Multihoming de niveau réseau HIP Host Identity Protocol HI est la clé publique d’une paire de clé asymétrique générée par le terminal. Pourtant, HI n’est pas directement utilisé dans le protocole à cause de sa longueur variable. Il existe deux formats de HI en utilisant les hachages cryptographiques sur la clé publique: Une représentation de HI à 32-bit, appelée LSI (Local Scope Identity)est utilisée pour IPv4. Une autre représentation de HI à 128 bits, appelée HIT ( Home Identity Tag ) est utilisée pour IPv6. 68 Multihoming de niveau réseau HIP Host Identity Protocol Avant de communiquer entre eux, les terminaux utilisent le protocole HIP Base Exchange pour établir l’association HIP. HIP Base Exchange est un protocole cryptographique qui permet aux terminaux de s’authentifier. Comme indiqué à la figure. Procédure d’échange de base de HIP 69 Multihoming de niveau réseau HIP Host Identity Protocol L’échange de base se compose de 4 messages qui contiennent les informations du contexte de communication, telles que: les HIT, la clé publique, les paramètres de sécurité IPSec, etc. I et R représentent respectivement l’initiateur et le répondeur à l’échange. Afin de protéger l’association contre des attaques de type déni de service (DoS), un puzzle est ajouté dans les messages R1 et I2. Comme HI remplace la fonction de l’identifiant de l’adresse IP, le HI et une des adresses IP disponibles d’un terminal devraient être publié dans le DNS (Domain Name System). 70 Multihoming de niveau réseau HIP Host Identity Protocol La figure suivante illustre la procédure d’échange de base en tenant compte du serveur DNS. Avant de commencer l’échange de base HIP, l’initiateur interroge le DNS en utilisant le nom DNS du répondeur pour obtenir HI et son adresse IP. après avoir reçu les informations nécessaires, l’initiateur exécute l’échange de base au moyen de 4 messages, I1, R1, I2, et R2. Echange de base de HIP avec DNS FQDN (Fully Qualified Domain Name) : est un nom de domaine qui spécifie l'emplacement complet d'un hôte ou d'une ressource dans la hiérarchie du système de noms de domaine (DNS) 71  Multihoming de niveau réseau SHIM6 (Level 3 Multihoming Shim Protocol for IPv6) Comme le protocole de multihoming au niveau réseau, SHIM 6 supporte également la séparation des rôles d’identification et de localisation de l’adresse IP. SHIM 6 propose d'utiliser une sous-couche intermédiaire SHIM située à l'intérieur de la couche IP. Contrairement à HIP, l’approche de SHIM6 n’introduit pas un nouvel espace de nommage pour les identifiants. Le terminal considère une de ses adresses IP comme son identifiant. nommé ULID (Upper Layer Identifier), celui-ci est visible par les couches supérieures. Une fois que l’ULID du terminal est choisi, il n’est donc pas modifiable tout au long de la session de communication. ce mécanisme assure un fonctionnement transparent de tous les protocoles des couches supérieures dans un environnement du multihoming car ces protocole voient toujours une adresse IPv6 stable. La sous-couche SHIM s'occupe d’effectuer la correspondance entre l' ULID et l’adresse active du terminal lors de la transmission. 72  Multihoming de niveau réseau SHIM6 (Level 3 Multihoming Shim Protocol for IPv6) Le terminal A dispose de 2 adresses, IP1A et IP2A, de même que le terminal B( IP1B, IP2B). Les adresses stables de source et de destination vues par les couches supérieures sont respectivement IP1A et IP1B Exemple de la correspondance dans SHIM6 73 Multihoming de niveau réseau SHIM6 (Level 3 Multihoming Shim Protocol for IPv6) Supposons que les adresses IP1A et IP1B ne soient plus valable pour les deux terminaux. Si le terminal A continue d’envoyer des paquets au terminal B, l’application du terminal A indique IP1A et IP1B comme adresse source et destination du paquet, car elle n’a pas conscience du changement des adresses. Lorsque la sous-couche SHIM du terminal A reçois ce paquet, elle convertit les ULID indiqués dans les adresses réelles des deux terminaux. Ensuite, le paquet est envoyé sur l’adresse IP2A du Terminal A vers l’adresse IP2B du terminal B. Lorsque la sous-couche SHIM du terminal B reçoit le paquet, elle traduit les adresses en ULID (IP1A pour la source et IP1B pour la destination) avant d’envoyer des données à la couche supérieure. Grâce à la correspondance entre l'ULID et l’adresse faite par la sous-couche SHIM, les changements d’adresses sont totalement transparents pour les protocoles des couches supérieures. 74 Multihoming de niveau réseau mCoA ( Multiple Care of Addresses registration) dans mobile IPv6 MIP6 (Mobile IPv6) est le protocole de gestion de la mobilité pour IPv6. Dans l’architecture de mobilité IP, chaque nœud mobile dispose d’une adresse statique HoA (Home Address) qui est attribué par son réseau mère. Lorsque le mobile entre dans un réseau d’accueil, il obtient une nouvelle adresse IP temporaire appelée CoA (Care of address). Il informe son agent mère (HA) se situant dans le réseau mère. HA stocke dans son cache ( Binding Cache) la correspondance entre CoA et HoA des nœuds mobiles. Ensuite, s’il existe un trafic destiné au HoA il est intercepté par HA et est redirigée vers l’adresse réelle du nœud mobile au moyen d’un tunnel IP. En conséquence la mobilité du nœud mobile devient transparente pour les nœuds correspondants. 75 Multihoming de niveau réseau mCoA ( Multiple Care of Addresses registration) dans mobile IPv6 76 Multihoming de niveau réseau mCoA ( Multiple Care of Addresses registration) dans mobile IPv6 Les limitations de mobile IPv6 viennent de ce que le client ne peux enregistrer qu’une seule adresse temporaire CoA avec son agent mère HA en effet, lorsque le nœud mobile se déplace vers un nouveau réseau, il obtient une nouvelle adresse CoA. Le nœud mobile doit informer son HA de ce changement pour que le HA mette à jour son cache. HA remplace alors l’ancienne CoA par la nouvelle. Par conséquent, à ce moment, il ne peut exister qu’une seule association entre CoA et HoA. 77  Multihoming de niveau réseau mCoA ( Multiple Care of Addresses registration) dans mobile IPv6 Pour supporter le multihoming, une extension permettant l’enregistrement de multiple CoA a été défini : un nœud mobile recevant plusieurs CoA associées aux interfaces peut enregistrer autant de correspondances entre ses CoA et son unique HoA à son HA. Pour cela un numéro d’identifiant de l’enregistrement( BID ) est utilisé. chaque enregistrement, qui est équivalent à une correspondance entre une CoA et une HoA, est identifiée par un unique BID. En utilisant un ou plusieurs messages de Binding Update, le nœud mobile informe son HA de ses correspondances HoA et des BID, HA conserve dans son cache toutes les correspondances enregistrées par le nœud mobile, comme illustré dans la figure suivante. 78  Multihoming de niveau réseau mCoA ( Multiple Care of Addresses registration) dans mobile IPv6 Pour les flux de données sortant, le nœud mobile gère le trafic selon son algorithme de distribution de flux. Pour les flux de données entrant, le nœud mobile définit les préférences du trafic et en informe HA. HA déduit ensuite le trafic destiné au nœud mobile via les différentes CoA selon les préférences indiquées. Enregistrement de plusieurs CoA dans Mobile IPv6 79 Multihoming de niveau Transport Dans les protocoles de transport classique TCP et UDP chaque terminal utilise une seule adresse pour une communication. Si l’adresse du terminal change, la connexion est interrompue. Avec l’évolution de la technologie d’accès, un terminal a souvent plusieurs adresse IP associée à ses interface. Les approches au niveau transport proposent que chaque terminal maintienne une liste des adresses IP. Une adresse peut être remplacé par une autre sans interrompre la communication. Les protocoles de multihoming au niveau transport sont des extensions de TCP telles que 1- MPTCP (Multipath TCP, Multihomed TCP, TCP-MH) 2- SCTP ( Stream Control Protocol). 80 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Est un protocole de transport défini par l'IETF et mise à jour en 2007. À l’origine ce protocole a été développé pour transporter la signalisation téléphonique sur le réseau IP. Étant un protocole de transport, SCTP est équivalent à d’autres protocoles de transport tels que TCP ou UDP. SCTP propose une fiabilité améliorée grâce à des mécanismes de contrôle de congestion, de détection de duplication de paquets et de retransmission. De plus, il supporte le nouveau service permettant de le distinguer des autres protocoles de transport Multistreaming et Multihoming. Contrairement à TCP, orienté octet. SCTP est un protocole orienté messages. 81 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Architecture de SCTP 82 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Lorsque le service transport de SCTP reçoit un message de données venant d'une application , il divise ce message en chunks. Il existe deux types de chunks , ceux contenant les données utilisateur et les chunks de contrôle. Pour être envoyé à la couche inférieure , les chunks sont encapsulés dans des paquets SCTP. Comme indiqué à la figure suivante , un paquet SCTP peut contenir plusieurs chunks de données ou de contrôle. Sa taille doit être inférieure au MTU. 83 Structure du paquet SCTP Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Source Port Destination Port Verification Tag Common Header SCTP Checksum PDU Chunk 1 Chunks Chunk N Chunks dans SCTP 84  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Les deux terminaux SCTP établissent une connexion SCTP. SCTP peut supporter le Multistreaming sur une même connexion. Au contraire de TCP, plusieurs flux peuvent-être simultanément utilisés pour la communication dans une connexion SCTP. Si une congestion se produit sur un des chemins, elle n’affecte que le flux qui y transit, et n’a aucune incidence sur les autres flux. Chaque flux SCTP numérote indépendamment ses chunks, en utilisant les numéros de séquence (SreamID) et Stream Sequence Number (SSN). Grâce au Multistreaming , la capacité de transport est fortement améliorée. Un des services les plus importants fourni par SCTP est le support Multihoming. Dans ce cas , chaque terminale SCTP possède une liste des adresses IP liées à ses interfaces. 85 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Type = Flags = UBE Length 0x00 Transmission Sequence Number (TSN) Stream Identifier (SID) Stream Seq. Num. (SSN) User supplied Payload Protocol Identifier User Data Data Chunk 86  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Type = 0x3 Flags = 0 Length = variable Cumulative TSN acknowledgement Advertised receiver window Num. Gap ACK blocks = N Num. duplicates = X Gap ACK blk #1 start TSN offset Gap ACK blk #1 end TSN offset........ Gap ACK blk #N start TSN offset Gap ACK blk #N end TSN offset Duplicate TSN 1 …….. Duplicate TSN X Le déplacement est relative au TSN (offset). SACK Chunk 87 GAP ACK blocks se sont des bloques reçus après cum TSN. Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Lors de la mise en place de la connexion, les terminaux SCTP s’échangent leur liste d’adresses. Parmi les adresses IP de la liste, le terminal choisit une adresse comme adresse primaire, les autres étant des adresses secondaires. Selon ce principe, une même connexion SCTP possède un chemin primaire et plusieurs chemins secondaires. Le chemin primaire est utilisé pour la transmission des données. En cas de panne du chemin primaire, SCTP utilise un de ses chemins secondaires pour poursuivre La communication. 88  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol SCTP se sert du mécanisme Heatbeat afin de vérifier si un chemin est actif. Le message Heatbeat est périodiquement envoyé à chaque adresse annoncée par l’autre terminale. L'absence consécutive d'acquittement Heatbeat-Ack venant du destinataire indique l’indisponibilité d’un chemin. Mécanisme Heatbeat 89 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Envoi périodique du message Heartbeat : Le terminal A envoie régulièrement (chaque THB secondes) un message appelé "Heartbeat" sur le chemin primaire entre les adresses IP IP1a et IP1b. Vérification de la disponibilité du chemin : Le but du message "Heartbeat" est de vérifier la disponibilité du chemin entre IP1a et IP1b. Ce message peut être une sorte de requête simple demandant un acquittement (acknowledgment) de la part du destinataire. Détecter la perte de connectivité : Si le terminal A n'obtient pas d'acquittement (ack) après plusieurs tentatives (essais sans acquittement), cela indique une perte de connectivité ou une indisponibilité du chemin primaire. Marquer le chemin primaire comme inactif : Après des essais sans acquittement, le chemin (IP1a, IP1b) est considéré comme inactif. Cela signifie que le mécanisme de détection a confirmé la perte de connectivité sur le chemin primaire. 90  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Marquer le chemin primaire comme inactif : Après des essais sans acquittement, le chemin (IP1a, IP1b) est considéré comme inactif. Cela signifie que le mécanisme de détection a confirmé la perte de connectivité sur le chemin primaire. Basculement vers un chemin secondaire actif : Lorsque le chemin primaire devient inactif, un mécanisme de basculement (failover) est déclenché. Un chemin secondaire actif, probablement une alternative préconfigurée ou dynamiquement sélectionnée, est utilisé pour acheminer les données. Transmission de données sur le chemin secondaire : Tant que le chemin primaire reste inactif, le terminal A utilise le chemin secondaire actif pour envoyer ses données. Cela garantit une continuité de la communication même en cas de perte momentanée du chemin primaire. Retour au chemin primaire actif : Lorsque le chemin primaire redevient actif (par exemple, après résolution du problème qui a causé la perte de connectivité), le système peut basculer de nouveau vers le chemin primaire pour optimiser les performances ou la bande passante. 91 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Dans chaque connexion SCTP, un seul chemin peut être utilisé pour la transmission de données, les autres étant considérés comme des chemins de secours. Le multihoming provient de la disponibilité d’utiliser simultanément plusieurs chemins. Des extensions de SCTP sont nécessaires pour que SCTP puisse supporter complètement le multihoming. 92 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Pour supporter la mobilité, SCTP propose une extension nommée mobile SCTP qui permet la reconfiguration dynamique d’adresse. Lorsqu'intervient un changement d’adresse IP suite à un déplacement du terminal, celui-ci envoie un message ASCONF (Address Configuration Change Chunk) pour demander d’ajouter la nouvelle adresse IP, de supprimer l’ancienne adresse et de changer éventuellement l’adresse primaire de connexion. 93 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol LS-SCTP Load Sharing SCTP est une autre extension de SCTP qui permet l’agrégation de bande passante dans SCTP. Les terminaux peuvent utiliser simultanément plusieurs chemins disponibles pour la transmission en assurant l’indépendance du contrôle de congestion de chaque chemin. 94 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol L’extension LS-SCTP se compose de deux nouveaux éléments : 1. Un nouveau paramètre dans les Chunks INIT et INIT- ACK qui indique si les terminaux supportent l’extension ; 2. Deux nouveaux types de Chunks :un chunks LS-Data (Load Sharing Data), utilisé pour envoyer des données, et un chunk d’acquittement LS-SACK (Load Sharing SACK) fournissant des acquittements sélectifs sur chaque chemin. 95 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol De chaque côté de la connexion, on trouve: Association Buffer (Tampon d'Association) : Il s'agit d'une file d'attente globale qui stocke les données de l'association SCTP. Une association SCTP représente une connexion entre deux points de terminaison. Le tampon d'association stocke temporairement les données à envoyer ou à recevoir au cours de la communication. Path Assignment Module (Module d'Attribution de Chemin) : Ce module est responsable du choix du chemin pour les chunks (unités de données SCTP) à travers lesquelles les données sont transmises. Dans SCTP, un chemin peut être compris comme une route spécifique entre deux points de terminaison, et le module d'attribution de chemin décide quel chemin emprunter pour envoyer ou recevoir des données. Architecture de LS-SCTP 96 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Path Monitor (Moniteur de Chemin) : Ce module surveille l'état du chemin. En SCTP, le contrôle de flux et le contrôle de congestion sont séparés. Le module de surveillance du chemin est probablement impliqué dans la détection des changements d'état du chemin, tels que des pertes de paquets ou des déconnexions. Cette information est utilisée pour prendre des décisions informées sur la gestion du trafic. Logical Buffer (Tampon Logique) : Les terminaux utilisent ce tampon pour gérer les données SCTP reçues de tous les chemins associés avant de les envoyer au terminal correspondant ou à l'application. Cela permet de rassembler les données de différents chemins dans une file d'attente logique pour les traiter de manière ordonnée. Cette approche contribue à assurer l'intégrité séquentielle des données malgré la multiplicité des chemins. Architecture de LS-SCTP 97  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol La fragmentation et le réassemblage de données sont réalisés dans la file d’attente de la connexion. Le contrôle de congestion est effectué par chemin. Chaque chemin a ses propres paramètres de contrôle de congestion tels que la taille de la fenêtre de congestion (cwnd), le seuil du slow-start (ssthresh), le temps d’aller-retour (RTT),…etc. 98  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Taille de la Fenêtre de Congestion (cwnd - Congestion Window) : La taille de la fenêtre de congestion représente le nombre maximum de chunk que l'émetteur peut envoyer avant de recevoir un accusé de réception (ACK) du destinataire. Il s'agit d'un mécanisme clé pour réguler la quantité de données en transit dans le réseau, contribuant ainsi à éviter la congestion. Seuil du Slow-Start (ssthresh - Slow-Start Threshold) : Le seuil du slow-start est une valeur qui détermine le moment où l'algorithme de congestion passe de la phase de slow-start à la phase de congestion évitée. Pendant la phase de slow-start, la taille de la fenêtre de congestion augmente de manière exponentielle jusqu'à atteindre le seuil du slow-start, moment à partir duquel elle augmente linéairement. 99  Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Temps d'Aller-Retour (RTT - Round-Trip Time) : Le temps d'aller-retour est la durée moyenne nécessaire à un paquet pour être envoyé de l'émetteur au destinataire et revenir. C'est une mesure importante utilisée dans les algorithmes de contrôle de congestion pour estimer la latence du réseau. Un RTT plus élevé peut indiquer un réseau plus lent, et cela peut influencer les ajustements de la fenêtre de congestion. 100 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Pour séparer le contrôle de flux du contrôle de congestion, LS-STCP utilise deux numéros de séquence différents: 1-ASN (Association Sequence Number) : ASN est le numéro de séquence associé à la connexion SCTP. Il est utilisé pour mettre en ordre tous les chunks reçus par la file d'attente de la connexion au récepteur. Cela garantit que les données sont livrées dans l'ordre correct à la couche supérieure. Exemple : Si les chunks arrivent avec les numéros de séquence 1, 3, 2, 4, ils seront réordonnés par l'ASN pour être livrés à la couche supérieure dans l'ordre correct : 1, 2, 3, 4. 102 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol 2- PSN (Path Sequence Number) : PSN est le numéro de séquence du chunk de données spécifique à chaque chemin. Il est utilisé pour assurer la fiabilité et le contrôle de congestion de chaque chemin. Chaque chemin a son propre PSN, indiquant l'ordre des chunks sur ce chemin en particulier. Exemple : Sur le chemin A, les chunks peuvent avoir les numéros de séquence 1, 2, 3, tandis que sur le chemin B, ils peuvent avoir les numéros de séquence 1, 2, 3. Chaque PSN est indépendant, ce qui permet de suivre la séquence sur chaque chemin. 103 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol 3- Module Path Assignment (Module d'Attribution de Chemin) : Le module Path Assignment est responsable de la répartition des données entre les chemins disponibles. Cette répartition est basée sur la disponibilité de la bande passante. Le module utilise le taux cwnd/RTT de chaque chemin pour déterminer la disponibilité relative, et distribue les chunks en conséquence. Exemple : Supposons que le chemin A a un taux cwnd/RTT de 100 chunks/seconde, tandis que le chemin B a un taux de 80 chunks/seconde. Le module Path Assignment distribuera les chunks en fonction de ces taux, donnant une priorité légèrement plus élevée au chemin A en raison de sa bande passante plus élevée. 104 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol 4- PID (Path Identifier) et PSN dans un Chunk : Une fois que le chemin est sélectionné, le chunk fournit un PID (Path Identifier) indiquant le chemin auquel il appartient, ainsi qu'un PSN pour indiquer l'ordre des chunks sur ce chemin particulier. Exemple : Un chunk sur le chemin A pourrait avoir un PID = 1 et un PSN = 3, indiquant qu'il est le troisième chunk sur le chemin A. Ces mécanismes contribuent à une gestion fine du contrôle de flux et du contrôle de congestion sur chaque chemin dans l'architecture LS-SCTP, tout en maintenant la fiabilité globale de la connexion SCTP. 105 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Il existe d’autres différences entre LS-SCTP et SCTP: Mécanisme de Retransmission sur un Autre Chemin : Dans LS-SCTP, lorsqu'il est nécessaire de retransmettre un chunk de données, cette retransmission est effectuée sur un autre chemin que celui utilisé pour la transmission précédente. Cela vise à augmenter la probabilité que le chunk retransmis atteigne le récepteur avec succès, même si le chemin initial était sujet à des problèmes tels que des pertes de paquets. Rôle du Module Path Monitor : Le module Path Monitor est responsable de la surveillance des chemins disponibles. Il met à jour la liste des chemins actifs en fonction des informations qu'il reçoit du réseau. Ces informations peuvent inclure des notifications sur la panne d'un chemin existant ou la disponibilité d'un nouveau chemin. 107 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Mise à Jour de la Liste des Chemins Actifs : Lorsque le module Path Monitor détecte une panne sur un chemin existant, il met à jour l'état de ce chemin à "inactif". Cependant, les chemins inactifs restent encore associés à la connexion SCTP. L'émetteur continue à les surveiller en utilisant le mécanisme de Heartbeat. Surveillance par Heartbeat : Les chemins inactifs restent associés à la connexion, et l'émetteur continue à les surveiller en envoyant périodiquement des messages Heartbeat. 108 Multihoming de niveau Transport SCTP Stream Control Transmission Protocol Activation d'un Chemin Inactif : Lorsqu'un chemin inactif redevient disponible, le module Path Monitor l'ajoute à la liste des chemins actifs. Dès lors, ce chemin peut être utilisé pour la transmission de données. Cette approche dynamique permet à LS-SCTP de s'adapter aux changements dans la disponibilité des chemins, en utilisant efficacement ceux qui sont actifs et en évitant ceux qui présentent des problèmes temporaires. 109 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) Le multihoming est supporté par SCTP de façon incomplète. La disponibilité de plusieurs chemins a uniquement pour but de réaliser une redondance. SCTP effectue la transmission via le chemin primaire. Les chemins secondaires sont utilisés seulement si le chemin primaire tombe en panne. Une extension de SCTP, appelée CMT (Concurrence Multipath Transfer), a été proposée pour la transmission via plusieurs chemins. 111 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) Dans CMT, il n’y a pas de distinction entre chemin primaire et secondaire. Tous les chemins sont équivalents et simultanément utilisés dans la transmission de données. CMT se sert du même système de numéro de séquence que SCTP. CMT utilise l’algorithme de round robin pour envoyer les données sur les chemins disponibles. La transmission de données à l’émetteur est contrôlés par la taille de la fenêtre de congestion de chaque chemin(CWND). CMT envoie les données sur un chemin dès que sa fenêtre de congestion est disponible. Lorsque plusieurs chemins sont utilisables pour la transmission, le chemin est sélectionné selon le modèle de round robin. CMT remplit la fenêtre de congestion de chaque chemin avant de passer à l’autre. 112 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) En contrepartie des bénéfices d’utilisation de la transmission Multichemin. CMT s'accompagne d’un phénomène de déséquencement qui dégrade les performances du fait que les chemins de CMT peuvent avoir des caractéristiques différentes en terme de bande passante et de délai. 113 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) CMT identifie 3 causes de déséquencement des données au niveau du récepteur : 1. Retransmissions rapides inutiles; 2. Mise à jour inexacte de la fenêtre de congestion; 3. Augmentation du trafic des acquittements. 114 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) 1. Retransmissions rapides inutiles : dans une transmission multichemin, des chemins peuvent avoir des bandes passantes et des délais différents. Il est possible que l’acquittement venant d’un chemin rapide indique la perte d’un paquet tandis que ce paquet reste encore sur un chemin plus lent et n'arrive à destination que plus tard. CMT utilise le même mécanisme de contrôle de congestion que TCP. Lorsque l'émetteur reçoit trois acquittements dupliqués notifiant la perte d’un paquet, il pense que ce paquet est perdu dans le réseau et déclenche la retransmission rapide du paquet. Or, cette retransmission est inutile puisque c’est le déséquencement qui est la cause de la duplication des acquittements. 115 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) Exemple Considérons un scénario où une application utilise la transmission multichemin (CMT) pour envoyer des données sur deux chemins différents, A et B, en raison des avantages de la bande passante accrue et de la redondance pour la fiabilité. Imaginons que ces deux chemins ont des caractéristiques différentes, notamment en termes de délai et de bande passante. Caractéristiques des Chemins : Chemin A : Bande passante plus élevée. Délai relativement court. Chemin B : Bande passante plus faible. Délai relativement long. Séquence d'Émission de Paquets : Supposons que l'application émet des paquets sur les deux chemins simultanément, comme illustré ci-dessous : Temps : 0 1 2 3 4 Chemin A : | Paquet 1 | | Paquet 2 | 116 Chemin B : | Paquet 3 | | Paquet 4 | Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) Exemple Séquence d'Arrivée des Paquets au Récepteur : En raison des différences de délai, les paquets peuvent arriver dans un ordre différent au niveau du récepteur. Temps : 0 1 2 3 4 Chemin A : | Paquet 1 |------------------| Paquet 2 |-----| Chemin B : |------------------| Paquet 3 |-----------------------| Paquet 4 | Récepteur : | Paquet 1 | Paquet 3 | Paquet 2 | Paquet 4 | Les paquets sont reçus dans un ordre différent de celui dans lequel ils ont été émis en raison des décalages de délai. 117 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) Exemple Acquittements et Retransmissions : Supposons que le récepteur génère des acquittements en fonction de la réception des paquets. Si, par exemple, le récepteur reçoit les paquets 1, 3, 2, et 4 dans cet ordre, cela pourrait entraîner des acquittements dupliqués, car les paquets ont été reçus dans un ordre différent de l'émission. Le mécanisme de retransmission rapide, activé par des acquittements dupliqués, peut alors déclencher des retransmissions inutiles, car les paquets ne sont pas réellement perdus, mais ont simplement suivi des chemins différents avec des délais différents. Cela peut conduire à une utilisation inefficace des ressources du réseau, car des retransmissions inutiles peuvent occuper la bande passante et augmenter la congestion. 118 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) 2. Mise à jour inexacte de la fenêtre de congestion : le mécanisme d’évolution de la fenêtre de congestion permet de ne l’augmenter que si un nouveau numéro d’acquittement accumulé (CUM ACK) est reçu par l’émetteur. Une fois que les acquittements avec le même CUM ACK sont arrivés, même s’ils contiennent de nouveaux gaps de données, l’émetteur ne modifie pas sa fenêtre de congestion. Comme le phénomène de déséquencement se produit régulièrement dans CMT, plusieurs acquittement avec le même acquittement sont envoyés à l’émetteur. Lorsque les gaps de données sont couverts par un nouvel acquittement, la fenêtre de congestion n'est augmentée qu’avec les nouvelles données acquittées dans l’acquittement le plus récent. Les données acquittées précédemment dans les gaps ne contribuent pas à la croissance de la fenêtre de congestion. Autrement dit, la mise à jour de la fenêtre de congestion ne répète pas exactement le volume de données transmis ; 120 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) Exemple Supposons que le récepteur génère des acquittements en fonction de la réception des paquets. Si les paquets sont reçus dans l'ordre 1, 3, 2, et 4, cela peut entraîner des acquittements répétés avec le même CUM ACK, car les paquets ont été reçus dans un ordre différent de l'émission. La fenêtre de congestion n'est augmentée qu'avec les nouvelles données acquittées dans le dernier acquittement, même si des acquittements répétés avec le même CUM ACK sont reçus. Temps : 0 1 2 3 4 Acquit. : | CUM ACK 1 | CUM ACK 1 | CUM ACK 1 | CUM ACK 2 | Fenêtre : | | | |* | La fenêtre de congestion (* marqué) est augmentée uniquement avec les nouvelles données acquittées dans le dernier acquittement (CUM ACK 2). 121 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) 3. Augmentation du trafic des acquittements: le principe des acquittements retardés de TCP est également utilisé dans SCTP. Au lieu d’envoyer un acquittement pour chaque paquet reçu, l’utilisation d’un acquittement regroupé pour plusieurs paquets réduit le trafic des acquittement. SCTP utilise ce mécanisme si les paquets arrivent au récepteur dans l’ordre. Les paquets déséquencés doivent être immédiatement acquittés. Toutefois, comme le déséquencement se produit fréquemment dans CMT, si le récepteur ne peux pas retarder l’envoi des acquittements, le trafic des acquittements est fortement augmenté, ce qui peut dégradé les performances du réseau. 123 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) CMT propose les solutions suivantes pour ces problèmes : 1- Pour éviter les retransmissions inutiles, CMT propose l’algorithme SFR (Split Frame Retransmit), qui permet à l’émetteur de bien interpréter les acquittements dupliqués, SFR définit une file d’attente virtuelle par destination dans la file d’attente de retransmission de l’émetteur. Avec l’information supplémentaire de chaque destination, telle que le plus grand TSN acquitté pour chaque destination, l’émetteur peut distinguer le déséquencement de la perte de données afin de déclencher correctement la transmission rapide. Un chunk avec le TSN T pour la destination M est considéré perdu si et seulement si : T est plus petit que le plus grand TSN acquitté de la destination M; 125 Commentaire L'émetteur maintient une file d'attente virtuelle par destination (chemin) dans la file d'attente de retransmission. Il reçoit des acquittements dupliqués indiquant la réception de certains paquets. Temps : 0 1 2 3 4 Acquit. : | ACK 1 | ACK 3 | ACK 2 | ACK 4 | En plus de l'information d'acquittement, l'émetteur connaît le plus grand TSN (Transmission Sequence Number) acquitté pour chaque destination. Destination A : Plus grand TSN acquitté = 2 Destination B : Plus grand TSN acquitté = 4 Dans cet exemple, il n'y a pas de TSN considéré comme perdu, car chaque TSN est effectivement plus grand que le plus grand TSN acquitté respectif. 126 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) 2- L’algorithme CUC (Cwnd Updates for CMT) est proposé pour mettre à jour correctement les fenêtres de congestion des chemins. A l'émetteur , chaque destination possède une variable nommée PSEUDO- CUMACK, que représente le plus petit TSN attendu. Lors de la réception d’un acquittement SACK, l'émetteur vérifie s'il existe un changement de PSEUDO- CUMACK de chaque destination. Une augmentation d'un PSEUDO -CUMACK déclenche la mise à jour de la fenêtre de congestion de la destination correspondante , même si le CUM ACK n’avance pas. La fenêtre de congestion de chaque destination augmente donc en parallèle des données acquittées, sans devoir attendre le nouveau CUM ACK ; 129  Commentaire PSEUDO-CUMACK (Destination A) = 1 PSEUDO-CUMACK (Destination B) = 3 Réception d'Acquittements : L'émetteur reçoit des acquittements SACK indiquant la réception des paquets. Temps : 0 1 2 3 4 Acquit. : | SACK A:1 | SACK B:3 | SACK A:2 | SACK B:4 | Les SACK indiquent que les paquets ont été reçus avec succès. Mise à Jour de PSEUDO-CUMACK : L'émetteur vérifie s'il existe un changement de PSEUDO-CUMACK pour chaque destination. Sur le chemin A, le PSEUDO-CUMACK augmente de 1 à 2 en raison de la réception du Paquet 2. Sur le chemin B, le PSEUDO-CUMACK augmente de 3 à 4 en raison de la réception du Paquet 4. Mise à Jour de la Fenêtre de Congestion : En raison de l'augmentation du PSEUDO-CUMACK, la fenêtre de congestion de chaque destination est mise à jour, même si le CUM ACK n'avance pas. Temps : 0 1 2 3 4 Cwnd A : | | |***********| | Cwnd B : |***********| | |***********| Les étoiles (*) représentent l'augmentation de la fenêtre de congestion en parallèle des données acquittées, sans attendre le nouveau CUM ACK. Ainsi, dans cet exemple, l'algorithme CUC permet une mise à jour parallèle des fenêtres de congestion des différentes destinationsen réagissant aux changements du PSEUDO-CUMACK, même si le CUM ACK n'avance pas. Cela contribue à améliorer la réactivité de la gestion de la congestion dans un environnement multichemin. 130 Multihoming de niveau Transport CMT (Concurrent Multipath Transfer) 3- CMT propose l'algorithme DAC (delayed ACK for CMT) afin de réduire le trafic d’acquittement. DAC permet au récepteur CMT de retarder l'acquittement , même si les paquets arrivent déséquencés. Comme l’envoi des acquittements est souvent reporté, l'émetteur dois analyser soigneusement chaque acquittement reçu afin de détecter la perte de données le plus rapidement possible. C’est pourquoi , dans chaque acquittement, le récepteur informe l’émetteur du nombre de paquets de données qu’il a reçu depuis le dernier acquittement envoyé. Cette proposition demande les modifications des deux côtés, émetteur comme récepteur. 131 Commentaire Acquittement Retardé avec Informations de Paquets Reçus : Le récepteur utilise l'algorithme DAC pour retarder l'envoi des acquittements. Lorsqu'il envoie un acquittement, il informe l'émetteur du nombre de paquets de données qu'il a reçu depuis le dernier acquit tement. Temps : 0 1 2 3 4 Acquit. : | DAC:1 | DAC:2 | DAC:2 | DAC:2 | Info : | 1 |2 | | | Les chiffres dans la colonne "Info" représentent le nombre de paquets de données reçus depuis le dernier acquittement. Analyse des Acquittements par l'Émetteur : L'émetteur analyse soigneusement chaque acquittement reçu pour détecter la perte de données. Dans cet exemple, l'émetteur note que le récepteur a reçu 2 paquets depuis le dernier acquittement. S'il ne reçoit pas d'acquittement après un certain délai, il peut en déduire qu'il y a une perte de données et déclencher une retransmission. Ainsi, l'algorithme DAC permet au récepteur de retarder l'envoi des acquittements, réduisant ainsi le trafic d'acquittement. Cependant, cela nécessite une analyse minutieuse de chaque acquittement par l'émetteur pour détecter la perte de données de manière proactive. 132 Multihoming de niveau Transport MPTCP (Multipath TCP) TCP est le protocole de transport le plus utilisé par les applications sur internet mais ce protocole ne supporte pas le multihoming. Malgré l’existence de différents chemins, chaque connexion TCP est limitée à ne se servir d’un seul chemin pour la transmission. L’utilisation simultanée de plusieurs chemins pour une même session de TCP pour améliorer le débit et fournir de meilleures performances tout en renforçant la fiabilité de la connexion. Le protocole Multipath TCP défini par l'IETF est une version modifiée de TCP qui supporte le multihoming et permet la transmission simultanée de données sur les différents chemins. Comme MPTCP est compatible avec TCP, il n’est pas besoin de modifier les applications existantes pour utiliser ses services. MPTCP est conçu pour regrouper plusieurs Flots TCP indépendants dans une seule connexion MPTCP en assurant la transparence pour les couches supérieures. 133 Conclusion Le mobile cloud Est un paradigme qui monte énormément avec le développement de terminaux mobiles souvent assez peu puissants par rapport à la demande de certaines applications. Le cloud mobile est un autre paradigme où des clients s'assemblent pour former un cloud. Cette solution n'est encore que très peu déployée et son arrivée va s'amplifier avec la mise en route de boitiers plus puissants dans les véhicules. Enfin, nous avons regardé les contrôleurs applicatifs de réseaux qui deviennent avec les points d'accès SDN de plus en plus fréquents et cette solution représente le futur qui devrait s'imposer. 134