Cette seconde vidéo, proposée par l'Institut Polytechnique de Paris pour la Task-Force IPv6 et l'Arcep présente le protocole SRv6 et plus particulièrement BIERv6 (Bit Index Explicit Replication IPv6 encapsulation).
Kevin Jiokeng, maitre de conférences en informatique, spécialité réseau, présente le protocole Segment Routing et B.I.E.R sur les supports de cours créés avec Thomas Clausen, également professeur à l'école polytechnique.
L'introduction du protocole SRv6 par Polytechnique Paris est faite dans cette vidéo : https://www.dailymotion.com/video/x8qhull
La stratégie de déploiement SRv6 est expliquée par Jean-Charles Bisecco dans la vidéo suivante : https://www.dailymotion.com/video/x8qhuza
Licence Creative Commons BY-SA 4.0 Institut Polytechnique de Paris
Kevin Jiokeng, maitre de conférences en informatique, spécialité réseau, présente le protocole Segment Routing et B.I.E.R sur les supports de cours créés avec Thomas Clausen, également professeur à l'école polytechnique.
L'introduction du protocole SRv6 par Polytechnique Paris est faite dans cette vidéo : https://www.dailymotion.com/video/x8qhull
La stratégie de déploiement SRv6 est expliquée par Jean-Charles Bisecco dans la vidéo suivante : https://www.dailymotion.com/video/x8qhuza
Licence Creative Commons BY-SA 4.0 Institut Polytechnique de Paris
Category
🤖
TechnologieTranscription
00:00 Bonjour, content de vous retrouver pour cette deuxième et dernière vidéo de notre courte
00:06 série sur le fonctionnement de SAV6 et BINV6.
00:10 Après avoir parlé dans la dernière vidéo du fonctionnement du segment routing, nous
00:16 allons prendre un petit rafraîchissement et aborder dans celle-ci le fonctionnement
00:21 de BIR, c'est-à-dire Bit Indexed Explicit Replication.
00:26 Puisque BIR est un mécanisme traitant du multicast dans un réseau, nous allons dans
00:33 cette vidéo d'abord rappeler le fonctionnement des approches traditionnelles pour faire du
00:38 multicast et identifier ensemble les inconvénients de celles-ci.
00:42 Ensuite, nous allons présenter le principe de fonctionnement de BIR et comment est-ce
00:49 qu'il améliore et simplifie la gestion du multicast dans les réseaux.
00:53 Alors, sans plus tarder, allons dans le vif du sujet.
00:57 Déjà, c'est quoi le multicast et comment fonctionne-t-il habituellement ?
01:03 Si dans un réseau, un nœud veut envoyer un paquet vers plusieurs destinations à la
01:09 fois, par exemple les nœuds 1, 3, 6 et 7, on parle de multicast.
01:16 Dans ces scénarios, l'approche à adopter va être spécifique puisque il est inutile
01:23 et non optimal pour la source d'envoyer une copie du paquet à chaque destination,
01:28 c'est-à-dire à chaque nœud cible.
01:30 Ceci résulterait en effet en une surutilisation inutile de certains des liens sur le chemin,
01:38 notamment les plus proches de la source.
01:41 En général, si un nœud donné souhaite recevoir du trafic multicast pour un groupe
01:46 spécifique et à partir d'une source spécifique, il enverra typiquement à son routeur le plus
01:53 proche un message "Join" pour rejoindre le groupe multicast concerné.
01:59 À la réception de ce message, le routeur va enregistrer dans sa table multicast l'information
02:07 qui stipule que, pour ce groupe multicast, il faut envoyer la donnée sur l'interface
02:14 à partir de laquelle le message "Join" a été reçu.
02:17 Il va également consulter sa table de computation, FIB pour Forwarding Information Base en anglais,
02:27 pour ensuite envoyer un message "Join" en direction de la source pour le même groupe
02:32 multicast.
02:33 Celui-ci enregistrera également l'information dans sa table et enverra le message plus loin
02:41 vers la source.
02:42 Ce phénomène se déroulera donc ainsi jusqu'à la réception du message par la source qui
02:49 enregistrera elle aussi l'information concernant le groupe concerné et l'interface vers laquelle
02:56 il faudrait envoyer le paquet.
02:58 Ce phénomène se déroulera donc ainsi indépendamment pour chaque nœud souhaitant rejoindre le
03:06 groupe.
03:07 Remarquons bien ici que le multicast est un moyen de demander à un routeur de faire
03:13 deux ou plusieurs copies d'un paquet et de l'envoyer vers les interfaces concernées.
03:20 Mais en fait, la notion de flux est problématique car elle signifie potentiellement que pour
03:27 chaque couple source numéro de groupe, c'est-à-dire pour chaque flux, un routeur doit maintenir
03:35 et mettre à jour un état.
03:38 Cela signifie également que les flux doivent être configurés avant de pouvoir être utilisés
03:45 et que cette configuration est effectuée par les clients.
03:49 Cela peut limiter certaines options comme la possibilité de procéder à des retransmissions
03:55 efficaces vers un seul ou vers tous.
03:58 Les approches classiques pour le multicast ont donc cette grosse limite que les routeurs
04:05 doivent conserver des informations d'état pour chaque flux, c'est-à-dire qui s'est
04:10 enregistré pour quel groupe, de quelle source et via quelle interface.
04:16 Pourtant, le multicast est important.
04:20 Pourquoi ? Pour la distribution de contenu, c'est-à-dire les films par examen.
04:26 Il permet de réduire l'utilisation des liens en n'envoyant qu'une seule copie d'un film
04:32 par examen et non plusieurs.
04:34 S'il y a plusieurs personnes qui veulent le regarder au même moment.
04:39 C'est-à-dire, par exemple, que le lien entre 0 et 8 ne devrait transporter qu'une seule
04:46 copie du film Black Panther par exemple et non trois simplement parce qu'il y a trois
04:51 caches VOD en dessous.
04:53 Cela est particulièrement utile si le lien est coûteux à utiliser ou lent, etc.
05:01 Pour donc apporter une solution aux limites des autres solutions multicast, BIER, pour
05:08 Bit Index Explicit Replication, va adopter une toute nouvelle approche.
05:13 Encore une fois, rappelons que la notion de multicast consiste à demander aux routeurs
05:19 de générer des répliques de paquets.
05:21 Les idées clés de BIER sont donc les suivantes.
05:25 Tout d'abord, la notion de flux est abandonnée.
05:29 La demande de réplication est désormais faite par la source et non par la destination.
05:35 La seule dynamique dans l'état maintenu doit être due aux mises à jour du protocole
05:42 de routage déployé dans le réseau.
05:45 L'idée est donc la suivante.
05:48 Le routeur d'entrée d'un domaine BIER insère une chaîne de bits dans le paquet.
05:55 La chaîne de bits en question peut être transportée dans une entête d'extension
06:00 IPv6 ou même utiliser les 64 bits inférieurs d'une adresse IPv6.
06:07 Cela n'est absolument pas important d'un point de vue fonctionnel, bien que cela le
06:13 soit bien sûr pour un déploiement réel.
06:16 Chaque bit correspond statiquement à une adresse IP.
06:21 Cette correspondance peut facilement être partagée entre les routeurs dans un domaine
06:27 BIER, par exemple sous la forme d'un TLV dans un IGP.
06:33 Si une destination doit recevoir une copie du message, le bit est mis à 1, en rouge
06:40 dans notre illustration.
06:41 Si une destination ne doit pas recevoir la copie d'un message, le bit est mis à 0,
06:50 en blanc dans notre illustration.
06:52 Un routeur compatible BIER sera interprété correctement à la chaîne de bits.
06:57 Un routeur non compatible BIER laissera tomber ou transmettra le paquet en unicast comme
07:04 d'habitude.
07:05 L'interprétation de la chaîne de bits implique deux choses.
07:09 Tout d'abord, le routeur doit créer une copie du paquet par interface, autre que celle
07:18 sur laquelle le paquet a été reçu.
07:21 Ensuite, pour une copie de paquet assignée à une interface, il doit effacer les bits
07:27 correspondants aux destinations sur toutes les autres interfaces.
07:32 Rappelons que nous avons cette information sur les nœuds atteignables via chaque interface
07:39 à travers la table de commutation, ou FIB pour Forwarding Information Base, qui est construite
07:47 par l'IGP.
07:49 En dupliquant un paquet, le routeur va donc effacer les bits pour les destinations qui
07:56 ne sont pas atteignables via l'interface considérée.
07:59 En mettant le paquet sur l'autre interface, il fera de même, c'est-à-dire recherche
08:08 dans la FIB et effacement des bits correspondants aux destinations qui ne sont pas atteignables
08:16 via l'interface.
08:17 Il peut alors envoyer les paquets modifiés sur chacune de ces interfaces-là.
08:24 Si le paquet arrive à un routeur qui est lui-même la seule et unique destination, celui-ci
08:32 va « consommer » le paquet et le processus s'arrête à ce niveau pour cette chaîne
08:38 de forwarding.
08:39 Sinon, c'est-à-dire dans les autres cas, le processus est répété au niveau de chaque
08:46 routeur jusqu'à réception du paquet par chacune des destinations.
08:51 C'est-à-dire que chaque routeur à la réception d'un paquet va tour à tour identifier à
08:59 l'aide de sa FIB les destinations qui sont atteignables à travers ces interfaces, dupliquer
09:07 les paquets, mettre à jour la liste des destinations dans l'entête et envoyer le paquet.
09:14 Avec cette approche, BIER allège considérablement la gestion des flux multicast dans les réseaux.
09:23 BIER nécessite juste que chaque routeur ait une table de forwarding, c'est-à-dire une
09:30 connaissance des plus courts chemins vers les destinations et les interfaces par lesquelles
09:36 les joindre.
09:37 Rappelons encore que ceci est déjà fourni comme résultat du protocole de routage s'exécutant
09:44 sur le réseau.
09:45 La deuxième chose que BIER nécessite, c'est une correspondance statique entre les emplacements
09:53 de la chaîne de BIER et les adresses des destinations.
09:57 La façon dont cette correspondance doit être mise en place n'est pas définie par BIER,
10:04 mais cela doit se faire à l'avance en attribuant par exemple, simplement, à tous les nœuds
10:10 du réseau un numéro, mais cela peut avoir des limitations pour la gestion des changements
10:17 dans le réseau, en cas de suppression ou d'ajout d'un nœud dans le réseau.
10:23 Quoi qu'il en soit, BIER permet à la source d'un paquet de spécifier l'ensemble des
10:31 destinations et ces destinations recevront le paquet sans que les routeurs n'aient
10:36 à maintenir un état pour les flux.
10:39 Pour conclure nos deux vidéos sur SAV6 et BIERV6, ces deux mécanismes nous montrent
10:47 comment il est encore possible de faire évoluer la couche réseau en réalisant des opérations
10:53 semblables même à de la programmation et ceci en mettant à profit des fonctionnalités
11:00 déjà prévues dans IPv6, notamment l'entête d'extension IPv6 et en exploitant aussi l'espace
11:09 d'adressage généreux d'IPv6.
11:12 Ces deux solutions ont en commun le fait que chaque paquet transporte avec lui les instructions
11:19 indiquant aux routeurs et aux points de traitement comment le traiter, ce qui induit bien sûr
11:26 comme inconvénient que l'on peut noter une occupation supplémentaire des liens, mais
11:32 au profit du grand avantage de la réduction, voire suppression, de la gestion complexe
11:39 des étapes à les routeurs.
11:41 On pourrait imaginer des travaux supplémentaires à la recherche d'un compromis entre les
11:46 deux.
11:47 Notons enfin que rien de ce dont nous avons discuté ici n'a à voir avec l'utilisateur.
11:54 Il s'agit plutôt de comment mettre sur pied ou optimiser des réseaux de datacenters ou
12:00 des infrastructures pour big data ou problématiques similaires, incluant notamment le machine
12:06 learning à large échelle.
12:08 Nous voici donc parvenus au thème de cette courte série de vidéos sur le fonctionnement
12:14 de SAV6 et BIV6.
12:17 Merci de nous avoir suivis.
12:19 Nous espérons qu'elles vous ont éclairés sur le fonctionnement de ces mécanismes et
12:24 comment cela pourrait être utile dans les besoins de votre entreprise.
12:28 Nous n'avons pas abordé de questions précises sur l'état actuel du déploiement de ces
12:34 solutions, ainsi que les stratégies pour leur déploiement dans votre entreprise.
12:39 Cela constitue un tout autre sujet.
12:43 Une fois de plus, merci et à bientôt.
12:46 Merci.
12:47 Au revoir.
12:47 Merci.