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.
Commentaires