Multicast protocoles de routage

1. Multicast protocoles de routage Bernard Tuy

2. Plan • Protocoles impliqués • Généralités préliminaires • Les équipements nécessaires • La diffusion de groupes sur le LAN • la diffusion multicast au-delà du LAN • Interactions PIM-DVMRP

3. Les protocoles de routage multicast • IGMP / CGMP • PIM SM / DM / SDM • DVMRP / MOSPF • mBGP / MASK • MSDP • Auto-RP / BSR • UDLR • …

4. Généralités préliminaires

5. Définitions • Multicast = Multipoint • Applications "habituelles" entre une source et un destinataire • applications Unicast(ou point à point) • "Nouveau" type d'applications entre une source et plusieurs destinataires => applications Multicast • Les participants à une application multicast constituent un groupe multicast • Le groupe multicast a une adresse multicast de classe D • 224.0.0.0 -> 239.255.255.255 • le groupe multicast n'est pas limité au réseau local routage vers les adresses des destinataires abonnes au groupe multicast : routage multicast

6. Modes de transmission • Unicast : vers un seul destinataire • Broadcast : vers tous les équipements du LAN • Multicast : vers tous ceux qui appartiennent au même groupe multicast • qui se sont "abonnés" à ce groupe

7. Exemple : téléséminaire Multicast : un seul flux d'information vers les destinataires

8. Téléséminaire (2) 224.2.0.1 Groupe Multicast d'adresse 224.2.0.1

9. Notions d’adressage multicast • Adresses de classe A, B, C ... • et D : 224.0.0.0 à 239.255.255.255 • réservation de plages d'adresses spécifiques : cf. le RFC 1700 ou http://www.iana.org/iana/assignments.html Exemples : • les adresses 224.0.0.0 - 224.0.0.255 • 239.*.*.* : "administratively scoped addresses" • adresses réservées pour des usages prives • toutes les autres adresses de 224.0.1.0 à 239.255.255.255 . attribuées de façon permanente a différentes applications . réservées pour une allocation dynamique via SDR ou autres méthodes

10. Adresses multicast réservées : exemples • 224.0.0.1 : tous les hosts multicast du LAN • 224.0.0.2 : tous les routeurs multicast du LAN • 224.0.0.4 : tous les routeurs DVMRP du LAN • 224.0.0.9 : tous les routeurs RIPv2 • 224.0.0.13: tous les routeurs PIM du LAN • Global scope: 224.0.1.0-238.255.255.255 • 239.*.*.* : "administatively scoped addresses • Limited scope: 239.0.0.0-239.255.255.255 • Site-local scope: 239.253.0.0/16 • Organization-local scope: 239.192.0.0/14 • toutes les autres adresses ont une portée non limitée

11. Allocation des adresses de groupes • Dynamique via des outils de type SDR • 224.2.x.y • 239.x.y.z • manuelle (déconseille) • ne demandez pas a votre ISP ! • RFC 2365 : Administratively scoped IP Multicast

12. Topologies des réseaux Multicast ISP Réseau multicast natif

13. Topologies des réseaux Multicast (2) ISP Réseau ne supportant pas les paquets multicast => établissement de tunnels

14. Tunnels IP • Structure logique faisant abstraction de la topologie physique sous-jacente du réseau • Dans RFC 1075, on utilise “Loose Source Routing” • En réalité, on encapsule les paquets multicast dans des paquets unicast(protocole = 4, tunnel DVMRP) • Association d’un métrique et d’un seuil (threshold ) à chaque tunnel (en plus d ’une adresse IP à chaque extrémité …) • métrique permet de privilégier une interface parmi n • le seuil définit la portée du datagramme multicast < 16 site local < 32 régional < 48 national < 64 transcontinental

15. La topologie du MBone routeur multicast Tunnel routeur multicast

16. Les équipements multicast • Postes de travail • stations, PC, portables … + carte réseau supportant le multicast • avoir un système intégrant les fonctionnalités multicast • configurer une route pour les adresses de groupes : 224.0.0.0/4 194.57.137.115 … • Le(s) routeur(s)+ cartes réseau supportant le multicast (ainsi que le niveau 2 !) avoir un IOS qui intègre IGMP + le routage multicast

17. Les stations hôtes • Par défaut, le driver d'une station écoute deux adresses Ethernet : la sienne et celle de broadcast (FF...FF) • Les autres adresses Ethernet doivent être explicitement programmées dans le driver • Au minimum, il faut écouter : • équivalent Ethernet de 224.0.0.1 • équivalent Ethernet du répertoire des sessions Mbone (224.2.127.254) • Architectures natives : • Sun/Solaris, SGI/IRIX, Dec/OSF-1, Windows 9x & NT • Linux, FreeBSD,... 9/24

18. Algorithme de transmission d ’un datagramme multicast • Si TTL(de l ’entête IP) > Seuil (fixé sur linterface) • alors : TTL = TTL - 1 on transmet le paquet • On détruit le paquet si : • Si TTL < 2 • pas de route • Paquet reçu sur une interface non-RPF • Destination = 224.0.0.{1,2}

19. Envoi de paquets • Une adressemulticast ne peut être quedestinataire • c ’est l’adresse d’un groupe de machines abonnées à une session multicast • les sources (émetteurs) sont « vues » par leur 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

20. Multicast : correspondance adresses IEEE 802.3 et adresses IP Préambule SFD @ DEST @ SCE Lg DATA DATA FCS Octet 0 Octet 5 - - - - - - X Y Y = 0 => Adresse de station particulière Y = 1 => Adresse d ’un groupe de stations 0 1 0 5 0 9 0 D X = 0 => Adresse universelle X = 1 => Adresse locale

21. Application UDP IP Multicast : correspondance adresses IEEE 802.3 et adresses IP (2) 224.2.0.1 inchangé Ethernet 0 2 0 0 0 1 mapping 0x 01 00 5E ______________________________ 23 bits de droite de l'@ IP destination (le 24 eme bit est a 0) Le bloc d ’adresses IEEE802 01:00:5E:00:00:00 - 01:00:5E:FF:FF:FF est réserve aux groupes multicast

22. Réception de paquets • Par défaut, le coupleur Ethernet d'une station écoute • son adresse Ethernet (fixée en 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 (224.2.127.254 p.exemple)

23. Résumé • Multicast = meilleure utilisation de la bande passante • les mêmes données ne circulent qu’une seule fois sur le même lien • les émetteurs (sources) et les receveurs (membres) sont distincts • les hôtes disent aux routeurs de quels groupes ils sont membres • et ne reçoivent que les datagrammes de ces groupes • ils ne disent rien sur les groupes multicast auxquels ils envoient des informations • les routeurs doivent écouter toutes les adresses multicast • pour être capables de transmettre les datagrammes multicast • les routeurs utilisent des protocoles de routage multicast pour administrer les groupes multicast

24. Diffusion de Groupessur le LAN

25. Internet Group Management Protocol( IGMP ) RFC 1112 (IGMP version 1) RFC 2236 (IGMP version 2)

26. 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 reçus par le groupe multicast d ’adresse d.d.d.d” • deux versions existent, IGMPv1 et v2 • IGMP versions 3 & 4 en cours d’élaboration (IETF/ IDMR)autoriseront l ’écoute d ’un sous-ensemble de participants au groupe multicast

27. IGMP: un seul routeur sur le LAN • le routeur envoie toutes les 60 (120) secondes • une sollicitation aveugle à l’@ 224.0.0.1 (query) avec un TTL = 1 • “à 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’(es) 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

28. IGMP: un seul routeur (2) • quand l’ hôte reçoit l’invitation 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 => une réponse par groupe multicast et par LAN • le routeur arme une temporisation sur les abonnements aux groupes multicast avant de solliciter à nouveau tous les hôtes • sollicitation périodique

29. IGMP : s’abonner à un groupe 224.2.0.1224.5.5.5 224.2.0.1 224.2.0.1 Hôte 1 Hôte 2 Hôte 3 Envoi Reportpour 224.2.0.1 Envoi Reportpour 224.5.5.5 Envoi périodiqueIGMP Query à 224.0.0.1

30. IGMP : plusieurs routeurs sur le LAN • Un routeur est élu entre tous les routeurs • c’est le Designated Router (DR) • 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

31. 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 querydirectionnel aux hôtes qui ont été abonnés à ce 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

32. IGMP : quitter un groupe 224.2.0.1 224.2.0.1 Host 1 Host 2 Host 3 Envoi Report pour 224.2.0.1 Envoi Leavepour 224.2.0.1 à 224.0.0.2 Envoi Leavepour 224.5.5.5 à 224.0.0.2 Envoi IGMP Query spécifique pour 224.2.0.1 Envoi IGMP Query pour 224.5.5.5

33. Diffusion de Groupesau-delà du LAN

34. Les Protocoles de routage Multicast • IGMP permet la distribution des datagrammes multicast sur le LAN • Protocole de routage pour acheminer ces paquets hors du LAN • Protocoles de routage multicast -distincts des protocoles de routage unicast : • tous les routeurs ne savent pas traiter les datagrammes multicast • la topologie multicast est -souvent- distincte de la topologie Unicast (basée sur les tunnels inter-routeurs multicast) • ils construisent des arbres de diffusion du trafic multicast où l ’émetteur est la racine de l ’arbre de diffusion • l’arbre minimal de diffusion ... toutes les branches sont utiles (id. ont au moins un abonne) • … est en constante évolution ajout (suppression) d ’une feuille/branche

35. Les Protocoles de routage Multicast (2) • On distingue deux familles de protocoles en fonction du mode de diffusion des paquets multicast utilisé : • Mode dense : inondation et élagage • DVMRP, PIM-DM et MOSPF • suppose que les abonnés aux groupes multicast sont nombreux • Mode épars (clairsemé) : greffe et élagage • PIM-SM et CBT • faible population abonnée

36. Bilan des modes de diffusion • Mode Dense • Flood + Prune : très inefficace • Peut provoquer des problèmes dans certaines topologies (congruence) • Creation d’un état (S, G) dans chaque router • Meme s’il n’y a aucun récepteur pour ces données • Traffic engineering pratiquement impossible • Ne “scale” pas aussi bien que le Sparse mode

37. Bilan des modes de diffusion (2) • Sparse mode • Impose de configurer un RP • Très efficace • abonnement explicite • Trafic va sulement là où c’est nécessaire • Les états ({*,S},G) sont seulement créés sur les chemins des • Traffic engineering possible • Use shared-trees rooted at different RP’s • utilise des arbres partagés dont différents RP peuvent etre l’origine • “Scales” beaucoup mieux que le mode dense

38. Commutation des trames multicast (L2) Problème: Inondation des trames multicast L2 • Certains commutateurs traitent le trafic multicast comme inconnu ou comme broadcast et envoie la trame sur tous les ports • des entrées statiques peuvent parfois etre configurées pour perciser quels ports doivent commuter quel(s) groupe(s) multicast • La configuration automatique des ces entrées réduit d’autant le travail d’administration PIM Multicast M

39. Commutation des trames multicast (2) Solution 1: IGMP Snooping • les paquets IGMP sont interceptés par le processeur ou par un ASIC spécifique • Le commutateur doit examiner le contenu des messages IGMP pour déterminer quels ports veulent quels trafics • IGMP membership reports • IGMP leave messages • Impact sur le commutateur : • doit traiter TOUTES les trames multicast de L2 • la charge de traitement augmente quand le trafic multicast augmente • nécessite un hardware spécialisé pour maintenir les performances PIM IGMP IGMP

40. Commutation des trames multicast (3) Solution 2: CGMP—Cisco Group Multicast Protocol • Pour les commutateurs et les routeurs • le routeur envoie des paquets multicast aux commutateurs à une adresse MAC conventionnelle : • 0100.0cdd.dddd • le paquet CGMP contient : • Type : Join or Leave • MAC address du client IGMP • addresse Multicast du groupe • le commutateur utilise l’information du paquet CGMP pour ajouter ou supprimer une entrée pour une MAC addresse multicast particulière PIM CGMP Commands IGMP

41. Résumé : commutateurs de trames • IGMP snooping • Commutateurs traitant les informations du L3 (ASIC) • Haut niveau de performances est maintenu • mais leur coût est plus élevé • Les autres commutateurs • ont des performances nettement dégradées • CGMP • Nécessite des routeurs et des commutateurs Cisco • Peut être implanté sur des commutateurs de faible prix

42. Protocoles de Routagedes datagrammes IP Multicast

43. Distance Vector Multicast Routing Protocol( DVMRP ) RFC 1075

44. DVMRP : généralités • Version 3 du protocole • draft-ietf-idmr-dvmrp-v3-04.txt • Implanté dans certains routeurs • pas Cisco • “mrouted” sous Unix • natif dans certains Systémes (boot !) • s ’assurer que la version du mrouted est au moins de 3.8 • 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

45. 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 path) • Test RPF : • Oui : paquet retransmis, on inonde • Non : paquet mis à la poubelle • un paquet est retransmis vers toutes les interfaces non élaguées du routeur - SAUFl’interface RPF

46. multicast Reverse Path Forwarding (RPF) Source A D B C E

47. unicast multicast Reverse Path Forwarding (RPF) Source A D B C E Paquets multicast non retransmis

48. Routage DVMRP • DVMRP utilise son propre routage unicast • (variante de RIP) • pour déterminer son critère RPF et • sa décision de transmettre un datagramme multicast • Le routage Unicast est nécesaire 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.

49. Routage DVMRP • échange de tables de routage entre routeurs DVMRP • Destination / Masque / Métrique • Les destinations sont les @ unicast des sources (émetteurs des datagrammes multicast) • La métrique (distance) est le nombre de routeurs multicast à franchir pour atteindre la source • L’optique est de toujours construire un arbre minimal à partir de la source • Le même protocole de routage est utilisé dans tout l’arbre de diffusion (tous les routeurs ont la même vue de la topologie multicast)

50. Echange des tables de routage (théorie) Source (S,1) (S,1) A D B C E