Multicast protocoles de routage Bernard Rapacchi Bernard Tuy.

Présentation au sujet: "Multicast protocoles de routage Bernard Rapacchi Bernard Tuy."— Transcription de la présentation:

1 Multicast protocoles de routage Bernard Rapacchi Bernard Tuy

2 U R E C 2 Envoi de paquets äUne adresse multicast ne peut être que destinataire äles sources ont toujours une adresse unicast äle niveau Liaison de données n'utilise pas ARP : ä mécanisme de correspondance (pour les @ IEEE-802) ä @IP multicast -> @Ethernet multicast äEtre membre d'un groupe est indépendant d'envoyer à ce groupe ä une source n’est pas obligatoirement membre du groupe auquel elles envoie un flux multicast

3 U R E C 3 Envoi de paquets ApplicationUDP IP Ethernet inchangé mapping0x 01 00 5E ______________________________ 23 bits de droite de l'@ IP destination 24eme bit = 0

4 U R E C 4 Réception de paquets äPar défaut, le coupleur Ethernet d'une station écoute ä son adresse Ethernet (fixée PROM) ä et l'adresse de broadcast (FF...FF) äLes autres adresses Ethernet doivent être explicitement programmées dans le driver du coupleur äPour le multicast, il faut écouter au minimum : ä équivalent Ethernet de 224.0.0.1 (tous les hôtes multicast du LAN) ä équivalent Ethernet du répertoire des sessions MBone ä annonçant la liste des groupes multicast actifs

5 U R E C 5 IGMP : généralités äProtocole d'interaction entre ä le(s) routeur(s) multicast du LAN ä et les hôtes multicast du LAN äPermet à un hôte de s'abonner (désabonner) à un groupe äet dire au routeur : ä “envoyez-moi une copie des paquets de cette adresse de groupe” ädeux versions existent, IGMPv1 et v2 äIGMP version 3 en cours d’élaboration (IETF/ IDMR)

6 U R E C 6 IGMP: un seul routeur äle routeur envoie toutes les 60 secondes ä une sollicitation aveugle à l’@ 224.0.0.1 (query ) ä “à quel(s) groupe(s) voulez vous vous abonner ?” ä et attend les réponses äle(s) hôte(s) renvoie(nt) un “IGMP report” ä qui indique l’adresse du ou des groupes qui l’intéressent äsi le routeur ne reçoit aucune réponse pour un groupe donné ä il arrête la réémission des paquets multicast de ce groupe ä le groupe est réputé sans abonné local

7 U R E C 7 IGMP: un seul routeur (2) äquand l’ hôte reçoit la sollicitation (query) ä il fixe un délai aléatoire avant de répondre ä pour éviter que toutes les réponses arrivent au même moment ä quand un hôte a répondu, les autres n’ont plus besoin de répondre äle routeur arme une temporisation sur les abonnements aux groupes multicast avant de solliciter à nouveau tous les hôtes

8 U R E C 8 IGMP : s’abonner à un groupe Hôte 1Hôte 2Hôte 3 224.2.0.1 224.5.5.5 224.2.0.1 224.5.5.5 Envoi périodique IGMP Query à 224.0.0.1 224.2.0.1

9 U R E C 9 IGMP : s’abonner à un groupe Hôte 1Hôte 2Hôte 3 224.2.0.1 224.5.5.5 224.2.0.1 224.5.5.5 Envoi Report pour 224.2.0.1 224.2.0.1

10 U R E C 10 IGMP : s’abonner à un groupe Hôte 1Hôte 2Hôte 3 224.2.0.1 224.5.5.5 224.2.0.1 224.5.5.5 224.5.5.5 Envoi Report pour 224.5.5.5 224.2.0.1 224.5.5.5

11 U R E C 11 IGMP : plusieurs routeurs äUn routeur est élu entre tous les routeurs ä c’est le Dominant Router (DR) ou Designated Router ä il est seul à émettre les IGMP Queries ä en v1, le mécanisme d’élection est fonction du routage multicast et n’appartient pas à IGMP ä en version 2, le DR est le routeur dont l’@IP est la plus petite äle DR n’est pas forcément le routeur qui transmet les paquets multicast

12 U R E C 12 IGMP : version 2 äElection du DR ä @IP la plus petite ätimers programmables änouveaux type de paquets envoyés par l’hôte : ä de désabonnement : leave ä au reçu d’un leave, le routeur envoie ä un query spécifique au groupe ä => réduction du temps de latence pour arrêter la diffusion d’un groupe qui n’a plus d’abonné äIGMP v2 doit obligatoirement supporter la version 1

13 U R E C 13 IGMP : quitter un groupe Host 1Host 2Host 3 224.2.0.1 Envoi Leave pour 224.2.0.1 à 224.0.0.2 224.2.0.1224.5.5.5

14 U R E C 14 IGMP : quitter un groupe Host 1Host 2Host 3 224.2.0.1 Envoi IGMP Query spécifique pour 224.2.0.1 224.2.0.1224.5.5.5

15 U R E C 15 IGMP : quitter un groupe Host 1Host 2Host 3 224.2.0.1 Envoi Report pour 224.2.0.1 224.2.0.1224.5.5.5

16 U R E C 16 IGMP : quitter un groupe Host 1Host 2Host 3 224.2.0.1 Envoi Leave pour 224.5.5.5 à 224.0.0.2 224.2.0.1224.5.5.5

17 U R E C 17 IGMP : quitter un groupe Host 1Host 2Host 3 224.2.0.1 Envoi IGMP Query pour 244.5.5.5 224.2.0.1

18 U R E C 18 Les Protocoles de routage multicast äOn distingue deux types de protocoles en fonction du mode de transmission des paquets multicast utilisé : ä Mode dense (inondation) ä DVMRP, PIM DM et MOSPF ä suppose que les abonnés aux groupes multicast sont nombreux ä Mode épars ä PIM SM et CBT ä faible population abonnée

19 U R E C 19 DVMRP : généralités ä“mrouted” sous Unix äAgit en mode dense :flooding + pruning ä on inonde (flooding ) tout l'arbre multicast ä ceux qui ne sont pas intéressés le disent ä ils sont élagués de l’arbre (pruning ) äPour éviter les boucles => algorithme RPF ä Reverse Path Forwarding

20 U R E C 20 Reverse Path Forwarding (RPF) äun routeur transmet un paquet multicast ä si le datagramme est reçu sur l’interface utilisée pour envoyer un paquet unicast vers la source (reverse ) äTest RPF : ä Oui : paquet retransmis, on inonde ä Non : paquet est mis à la poubelle äun paquet est retransmis vers toutes les interfaces du routeur SAUF l’interface RPF d’entrée

21 U R E C 21 Reverse Path Forwarding (RPF) D multicast Source A B C E

22 U R E C 22 Reverse Path Forwarding (RPF) Source A B C D E unicast multicast Paquets multicast non retransmis

23 U R E C 23 Routage DVMRP äDVMRP utilise son propre routage unicast ä variante de RIP ä pour déterminer le critère RPF et ä décider de retransmettre un datagramme multicast äLe routage Unicast est nécessaire pour localiser les Sources multicast äles paramètres du protocole ä le nombre de sauts (hops), les métriques et les seuils (Threshold ) ä le seuil indique si un datagramme multicast peut être réémis en le comparant à son TTL. äobligation d’utiliser des tunnels ä certains routeurs ne font pas du multicast

24 U R E C 24 Routage DVMRP äéchange de tables de routage entre routeurs DVMRP ä Destination / Masque / Métrique äLes destinations sont les @ sources multicast äL’optique est de toujours construire un arbre minimal à partir de la source

25 U R E C 25 Echange des tables de routage (théorie) Source A B C D E (S,1)

26 U R E C 26 Echange des tables de routage (théorie) Source A B C D E (S,2)

27 U R E C 27 Poison Reverse äLe routeur B va décider ä que le routeur A voisin est en “amont” vers la source S ä il envoie à A une information de routage versS dont la métrique est dite empoisonnée äConséquence : ä B attend le flux multicast de A pour la source S ä A ne doit pas compter sur B pour ce même flux äLe RFC 1112 prévoit d' envoyer : ä @IP Source, m = infini (16), + un flag à 1 äDans mrouted : ä Source, m = vraie métrique vers S + infini (32)

28 U R E C 28 Poison Reverse Source A B C D E (S,infini) (S,2)

29 U R E C 29 PIM : généralités äIndépendant du protocole de routage äDVMRP ä prend les décisions de RPF ä a son propre protocole de routage äPIM repose sur le protocole de routage unicast sous-jacent ä pour les décisions RPF ä et les poison reverse routes äPIM peut fonctionner selon deux modes : ä dense mode : faible overhead pour les groupes denses d’abonnés ä sparse mode : peu d’abonnés

30 U R E C 30 PIM : Dense Mode äRessemble à DVMRP ä sauf pour le routage ämécanismes de flooding et pruning et de graft (greffe), ä Pruning sur les voisins non RPF äArbres construits par rapport aux sources émettrices avec utilisation de RPF äUtilisation de déclaration (assert ) pour élire un transmetteur sur un LAN à plusieurs routeurs

31 U R E C 31 PIM : Sparse mode äMode d’abonnement explicite (Join ) : ä La source s’enregistre auprès d'un Point de Rendez-vous RP ä Le RP est la racine de l'arbre de diffusion multicast ä c'est une adresse bien connue de tous ä Pour s'abonner le destinataire envoit un Join au RP ä Il peut y avoir plusieurs RP pour différents groupes ä Pas d'inondation äLe flux multicast parcourt un arbre partagé ä les routeurs feuilles peuvent de se joindre à l’arbre ä les paquets ne vont que là où c'est utile

32 U R E C 32 Organisation du routage multicast : principes äsur un campus : ä Participer au FMBone ä minimiser les flux multicast pour éviter les flux inutiles ä Topologie arborescente et sur chaque Routeur : ä n’accepter aucune route DVMRP sur l’interface RPF ip dvmrp accept-filter 15 access-list 15 deny any ä ne retransmettre qu’une route par défaut DVMRP sur les autres interfaces ip dvmrp default-information only ä configurer une route multicast statique par défaut qui pointe vers l’interface RPF ip mroute 0.0.0.0 0.0.0.0 TunnelX ä préférer PIM aux tunnels quand cela est possible ä informer / former les utilisateurs potentiels

33 U R E C 33 Organisation du routage multicast : principes ädans un laboratoire : ä mettre en place un seul routeur multicast ä quand le besoin existe ! ä PIM si possible (type du routeur, niveau d'IOS,...) ä même configuration de routeur

34 U R E C 34 Solution 2 : développer PIM dense Renater DVMRP MBone DVMRP interne DVMRP interne PIM DVMRP interne PIM/GRE MBone

35 U R E C 35 Solution 3 : développer PIM dispersé Renater DVMRP MBone DVMRP interne PIM DVMRP interne PIM/GRE MBone DVMRP interne

36 U R E C 36 Bibliographie äftp://ftpeng.cisco.com/ipmulticast.html ähttp://electre.inria.fr ähttp://www.univ- rennes1.fr/CRU/Multimedia/annonce_multimedia.html