Mécanisme de découverte et remontée d’informations

Le troisième aspect que nous analysons est la méthode de découverte de topologie, et de remontée d’informations. Comme expliqué dans la section 3.6, l’approche Open- Flow/OFDP présente plusieurs limites. L’une des principales limites est le passage à l’échelle. Ce problème est causé principalement par le mode de communication (un-à-

un) considéré par le mécanisme OFDP. En effet, le contrôleur échange avec chaque nœud

afin de découvrir la topologie du réseau, comme expliqué dans la section 3.3.

Afin de pallier ce problème, nous proposons de considérer un mode de commu- nication un-à-plusieurs dans lequel, les nœuds d’acheminement forment des groupes

(Clusters), chaque groupe se voit désigner un chef de groupe (Cluster Head, CH ). Par

conséquent, le contrôleur va échanger seulement avec les responsables des groupes, au lieu d’échanger avec chaque nœud séparément. Comme illustré par la figure 3.14, le nœud N1 est désigné comme CH du groupe composé des nœuds N2, N4, N5 et N3. De cette manière, le contrôleur échange seulement avec le nœud N1 (CH), au lieu d’échanger avec tous les nœuds du réseau.

Cela va réduire significativement l’overhead réseau généré par le processus de découverte de topologie, entre le plan de contrôle et le plan de donnée. Cependant, la formation des groupes et la sélection des CH doivent être effectuées de manière efficace, afin d’éviter de générer un trafic supplémentaire au niveau du plan de données.

En plus de son efficacité dans la réduction du sur-débit réseau, cette approche repré- sente un autre avantage majeur. Il s’agit de la découverte des nœuds non-OpenFlow ou hors couverture réseau. En effet, au lieu de déclencher la découverte par le contrôleur

(l’envoi de paquet LLDP), ce qui nécessite l’établissement de session OpenFlow avec

chaque nœud (comme expliqué dans la section 3.3), nous proposons dans notre approche que la découverte soit déclenchée par les nœuds d’acheminement et transmise au contrô- leur via les responsables de chaque groupe (CH). Comme illustré par la figure 3.14, le nœud N3 ne supporte pas les fonctionnalités OpenFlow. Par conséquent, il ne figure pas dans la représentation de la topologie du réseau (suivant l’approche OpenFlow/OFDP). Grâce à l’approche basée Cluster, le nœud peut être découvert par ses voisins sans for- cément être compatible OpenFlow, ou avoir une connectivité avec le contrôleur.

Il est perceptible que la formation des groupes constitue un élément crucial de cette approche. Cette procédure doit être effectuée minutieusement afin d’éviter de générer un grand overhead réseau. Deux étapes principales : Le choix des responsables des groupes

Figure 3.14: Mécanisme de découverte basé sur un mode un-à-plusieurs

et le choix des membres de chaque groupe.

Afin d’éviter la génération d’un overhead supplémentaire et avoir une solution stable, deux principaux pré-requis :

— R1 : les liens entre les contrôleurs et les CH doivent être stables et de bonne qualité. En d’autres termes, il faut que les CH désignés ne changent pas fréquem- ment.

— R2 : les liens entre les CH et les membres des groupes doivent être également stables. Cela signifie que chaque véhicule doit appartenir à un groupe donné (sous la responsabilité d’un CH donné) le plus longtemps possible.

Le premier choix consiste à considérer chaque entité BS/RSU comme un CH et les véhicules roulant dans leurs zone de couverture respectives représentent les membres de chaque groupe. Ce choix répond pleinement au premier pré-requis, étant donné que ces entités disposent généralement d’une connectivité stable et de bonne qualité avec les contrôleurs SDN. Cependant, il ne répond pas au deuxième pré-requis. En effet, avec la mobilité des véhicules, ces derniers changent fréquemment d’entité BS/RSU et par conséquent de CH/groupe, surtout dans des conditions de forte mobilité.

Le deuxième choix consiste à désigner les véhicules comme CH. La sélection des CH peut être effectuée en fonction des profils de mobilité des véhicules de telle sorte que les membres du groupe (véhicules) restent attachés au même groupe (responsable du groupe) le plus longtemps possible. Ce choix répond au deuxième pré-requis étant donné que le CH est mobile, les véhicules auront moins tendance à changer de CH comparativement au premier choix (BS/RSU comme CH). De plus, ce choix permet de garantir la stabilité des liens entre les véhicules et le CH même dans des zones sans couverture du réseau.

3.7. Vers un service de découverte de topologie adapté au contexte SDVN99

Cependant, ce choix ne répond pas totalement au premier pré-requis, étant donné que les CH peuvent changer fréquemment. De plus, le lien entre le contrôleur et les CH (dont une partie est sans fil) est exposé aux dégradations dues à la mobilité, interférences, etc. Basé sur cette analyse, nous proposons dans notre approche, l’utilisation des entités BS/RSU comme les principaux candidats de CH avec la considération des véhicules dans les situations suivantes :

— Forte mobilité : Dans des situations où les véhicules roulent à de grandes vitesses (auto-route, ligne droite avec très peu de véhicules), l’utilisation de l’entité RSU comme CH résulte en la formation de groupes non stables. En effet, les véhicules restent sous la couverture d’une entité RSU pendant une très courte durée. Dans ce cas, la considération d’un véhicule ayant le même profil de mobilité que ses véhicules avoisinants (membres de groupe) comme CH maximise les chances d’avoir un groupe stable.

— Manque de couverture réseau : Dans des zones où la couverture du réseau est indisponible, l’adoption d’un véhicule comme CH est le seul choix qui se présente. La figure 3.15 schématise les situations où les entités RSU/BS et/ou véhicules sont considérés comme CH. les entités RSU/BS localisées dans des interactions peuvent être sélectionnées comme CH étant donné que les véhicules roulent lentement dans ces zones. Cependant, dans des zones avec une forte mobilité, il est plus adapté de sélectionner des véhicules comme CH.

Figure 3.15: Sélection de CH en fonction de la mobilité

Le CH sélectionné se charge de construire une vue de la topologie locale de son groupe et la remonter au contrôleur. Il maintient une sorte de table de voisinage listant les liens V2V et V2I dans le cas où le CH désigné est une entité RSU/BS et seulement les liens V2V dans le cas où le CH sélectionné est un véhicule. En effet, nous proposons que les entités RSU/BS soient à l’initiative d’annoncer aux contrôleurs les changements relatifs au liens V2I. Cela permet de tirer profit de la partie filaire reliant ces entités aux contrôleurs et de minimiser le sur-débit réseau concernant le support sans-fil. De plus, ces entités sont supposées exécuter les mécanismes d’estimation de durée de vie et de

qualité des liens afin de filtrer ceux jugés de mauvaise qualité.

D’autre part, nous proposons que les attributs des noeuds statiques ne soient remontés qu’une seule fois durant la découverte initiale du noeud. Cependant les attributs dyna- miques sont remontés d’une manière événementielle une fois s’il y a un changement et cela à travers les CH désignés.