Multicast - HackMD

# Le multicast ## C'est quoi? C'est la diffusion de données d'un émetteur vers un groupe de récepteurs (on parle aussi de diffusion de groupe). ## Pourquoi? Plus efficace par le fait qu'on envoie moins de données sur le support : on optimise ainsi la **bande passante**. On peut dire aussi qu'il y a moins de traitements réalisés au niveau des hosts et les routeurs. ## A noter Dans ce type de communication, l'émetteur ne connaît donc pas les adressses des destinataires puisqu'il envoie à un groupe de récepteurs. ## Les 3 types de transmission IP ### 1 - La transmission unicast On l'appelle aussi la transmission **point à point**. Dans ce cas de figure, le paquet IP ne transite qu'entre l'émetteur et **1 seul destinataire.** ### 2 - La transmission broadcast C'est la diffusion du paquet à tous les destinataires au sein du même **domaine de diffusion** [*(Définition, site de IONOS)*](https://www.ionos.fr/digitalguide/serveur/know-how/domaine-de-diffusion/), qui est délimité par les routeurs. ### 3 - La transmission multicast Appelé aussi transmission **multipoint**. Ici les destinataires peuvent se situer dans différents réseaux. ```mermaid graph TB subgraph Unicast E1[Émetteur] --> |Flux 1| R1[Router] R1 --> |Flux 1| D1[Destinataire 1] R1 --> |Flux 2| D2[Destinataire 2] R1 --> |Flux 3| D3[Destinataire 3] E1 --> |Flux 2| R1 E1 --> |Flux 3| R1 style E1 fill:#f9f,stroke:#333 style R1 fill:#ff9,stroke:#333 style D1 fill:#9ff,stroke:#333 style D2 fill:#9ff,stroke:#333 style D3 fill:#9ff,stroke:#333 end subgraph Multicast E2[Émetteur] --> |Flux unique| R2[Router] R2 --> |Copie 1| D4[Destinataire 1] R2 --> |Copie 2| D5[Destinataire 2] R2 --> |Copie 3| D6[Destinataire 3] style E2 fill:#f9f,stroke:#333 style R2 fill:#ff9,stroke:#333 style D4 fill:#9ff,stroke:#333 style D5 fill:#9ff,stroke:#333 style D6 fill:#9ff,stroke:#333 end ``` > Ce schéma montre la différence fondamentale entre un système à transmission multicast et unicast. Tout se joue sur l'optimisation de la bande passante : au lieu de générer autant de flux qu'il y ait de destinataires (ce qui consommera en bande passante), le multicast permet de réduire fortement cet aspect. > Le routeur sera moins sollicité aussi par le nombre de flux qu'il doit traiter. ## Caractéristiques du multicast IP * La standardisation du multicast IP s'est faite dans les RFC suivant : [RFC 1112](https://www.rfc-editor.org/rfc/rfc1112), [RFC 3228](https://www.rfc-editor.org/rfc/rfc3228) et [RFC 3376](https://www.rfc-editor.org/rfc/rfc3376). * Un groupe multicast est identifié par une adresse de [classe D](https://fr.wikipedia.org/wiki/Classe_d'adresse_IP) . * La localisation réseau des déstinataires importe peu dans une transmission multicast. En effet, les destinataires peuvent se situer dans différents réseaux et appartenir au même groupe de multicast. * Pour informer d'une arrivée ou un départ d'un récepteur d'un groupe multicast, il faut que la station communique cela au routeur concerné via le protocole standardisé [IGMP (Internet Group Management Protocol)](https://www.ionos.fr/digitalguide/serveur/know-how/igmp-internet-group-management-protocol/) * Un groupe multicast peut ne pas contenir de membres * Un hôte peut appartenir à plusieurs groupes multicast * L'émetteur n'est pas obligé d'appartenir à un groupe alors qu'un récepteur est forcément membre d'un groupe. ## Adressage ```mermaid graph TB subgraph Adresses_IP[Structure des Adresses IP] IP[Adresses IPv4 0.0.0.0 à 255.255.255.255] IP --> Unicast[Adresses Unicast Ex: 192.168.1.1] IP --> Multicast[Adresses Multicast 224.0.0.0 à 239.255.255.255] subgraph Plages_Unicast[Plages Unicast Principales] Unicast --> ClassA[Classe A 1.0.0.0 à 126.255.255.255] Unicast --> ClassB[Classe B 128.0.0.0 à 191.255.255.255] Unicast --> ClassC[Classe C 192.0.0.0 à 223.255.255.255] end subgraph Plages_Multicast[Plages Multicast] Multicast --> Local[Local Network Control Block 224.0.0.0 à 224.0.0.255] Multicast --> InternetWork[InterNetwork Control 224.0.1.0 à 238.255.255.255] Multicast --> Reserved[Reserved 239.0.0.0 à 239.255.255.255] end style IP fill:#f9f,stroke:#333 style Unicast fill:#9ff,stroke:#333 style Multicast fill:#ff9,stroke:#333 style ClassA fill:#e6f3ff,stroke:#333 style ClassB fill:#e6f3ff,stroke:#333 style ClassC fill:#e6f3ff,stroke:#333 style Local fill:#fff2cc,stroke:#333 style InternetWork fill:#fff2cc,stroke:#333 style Reserved fill:#fff2cc,stroke:#333 end ``` ```mermaid graph TB subgraph Structure_Adresses[Différence Structurelle] Unicast[Adresse Unicast] --> UN[Partie Network] & UH[Partie Host] Multicast[Adresse Multicast] --> GID[ID Groupe Unique Pas de séparation Network/Host] end subgraph Paquet_IP[Structure Paquet IP Multicast] IP[Paquet IP] --> SRC[Adresse Source: Toujours Unicast] & DST[Adresse Destination: Peut être Multicast] end style Unicast fill:#9ff,stroke:#333 style Multicast fill:#ff9,stroke:#333 style UN fill:#cef,stroke:#333 style UH fill:#cef,stroke:#333 style GID fill:#ffd,stroke:#333 style IP fill:#f9f,stroke:#333 style SRC fill:#cef,stroke:#333 style DST fill:#ffd,stroke:#333 ``` ```mermaid graph TB subgraph Structure_Adresses[Structure des Adresses IP] subgraph Unicast[Structure Adresse Unicast] U_Header[Adresse Unicast Ex: 192.168.1.10] U_Header --> Network[Partie Réseau Ex: 192.168.1] U_Header --> Host[Partie Hôte Ex: .10] Network --> Masque[Masque de sous-réseau définit la séparation Ex: 255.255.255.0] end subgraph Multicast[Structure Adresse Multicast] M_Header[Adresse Multicast Ex: 224.0.0.1] M_Header --> GroupID[Identifiant de Groupe pas de séparation réseau/hôte Ex: tout l'ID 224.0.0.1 identifie le groupe] end style U_Header fill:#9ff,stroke:#333 style Network fill:#cef,stroke:#333 style Host fill:#cef,stroke:#333 style Masque fill:#f9f,stroke:#333 style M_Header fill:#ff9,stroke:#333 style GroupID fill:#ffd,stroke:#333 end ``` ## Mapping d'adressage Il est important de comprendre comment se fait la correspondance entre les adresses IP multicast et les adresses ethernet multicast. #### Multicast Ethernet Les adresses multicast ethernet se fait de la manière suivante : *le bit de poids faible de l'octet du poids le plus fort, est à 1* . Ainsi, on obtient : ``` x1.xx.xx.xx.xx.xx ``` L'**IANA** a réservé un bloc spécifique pour l'adressage multicast dans un réseau ethernet: **00:00:5E:xx:xx:xx**. En appliquant le principe ci-dessus, la plage serait à partir de **01:00:5E:00:00:00** --> **01:00:5E:7F:FF:FF**. ```mermaid graph TB subgraph IP_Multicast[Structure Adresse IP Multicast] IP[Adresse IP Multicast] IP --> Prefix[Préfixe 1110 4 bits] IP --> GroupIP[ID Groupe IP 28 bits] style IP fill:#f9f,stroke:#333 style Prefix fill:#cef,stroke:#333 style GroupIP fill:#cef,stroke:#333 end subgraph MAC_Multicast[Structure Adresse MAC Multicast] MAC[Adresse MAC Multicast 01:00:5E:XX:XX:XX] MAC --> MACPrefix[Préfixe MAC 25 bits 01-00-5E-0] MAC --> GroupMAC[ID Groupe MAC 23 bits] style MAC fill:#ff9,stroke:#333 style MACPrefix fill:#ffd,stroke:#333 style GroupMAC fill:#ffd,stroke:#333 end subgraph Mapping[Mappage IP vers MAC] Map[Mappage des bits] Map --> Lost[5 bits perdus du groupe IP] Map --> Used[23 bits utilisés pour l'adresse MAC] Note[Plusieurs adresses IP peuvent correspondre à la même adresse MAC] style Map fill:#d9f,stroke:#333 style Lost fill:#f99,stroke:#333 style Used fill:#9f9,stroke:#333 style Note fill:#fff,stroke:#333 end GroupIP --> Lost GroupIP --> Used Used --> GroupMAC ``` ### Remarque La conséquence de ce mappage est que **32 (2^5) adresses IP multicast différentes** peuvent correspondre à la **même adresse MAC multicast.** Cette limitation signifie que le filtrage au niveau Ethernet n'est pas aussi précis qu'au niveau IP, et les stations doivent effectuer un filtrage supplémentaire au niveau IP pour s'assurer qu'elles ne reçoivent que le trafic multicast qui les intéresse. ## Multicast au sein d'un LAN ```mermaid graph TB subgraph LAN[Exemple de multicast dans un réseau local] SRC[Source Multicast 192.168.1.10] -->|"Paquet Multicast Dest: 224.0.0.1 MAC: 01:00:5E:00:00:01"| SW{Switch} SW -->|"1. IGMP Join 2. Copie du flux"| PC1[PC1 Membre du groupe IGMP Join envoyé] SW -->|"1. IGMP Join 2. Copie du flux"| PC2[PC2 Membre du groupe IGMP Join envoyé] SW -.->|"Pas de copie Non membre"| PC3[PC3 Non membre Pas d'IGMP Join] SW -->|"1. IGMP Join 2. Copie du flux"| PC4[PC4 Membre du groupe IGMP Join envoyé] style SRC fill:#f9f,stroke:#333 style SW fill:#ff9,stroke:#333 style PC1 fill:#9f9,stroke:#333 style PC2 fill:#9f9,stroke:#333 style PC3 fill:#f99,stroke:#333 style PC4 fill:#9f9,stroke:#333 end ``` Dans un environnement LAN, le processus commence par l'adhésion des machines au groupe multicast qui les intéresse. Pour cela, elles utilisent le protocole IGMP (Internet Group Management Protocol) en envoyant un message "IGMP Join" vers l'adresse du groupe multicast désiré. Le switch, équipé de la fonctionnalité "IGMP snooping", écoute ces messages et maintient une table de correspondance entre les ports et les groupes multicast. Lorsqu'une source souhaite transmettre des données au groupe, elle envoie un seul flux de données vers l'adresse multicast du groupe. Le switch, grâce à sa table d'adhésion construite via IGMP snooping, sait exactement quels ports hébergent des membres du groupe. Il peut ainsi dupliquer intelligemment le flux uniquement vers ces ports spécifiques. Les machines non membres du groupe, bien que physiquement connectées au même réseau, ne reçoivent aucune donnée du flux multicast. ### Avantages dans le LAN : * Économie de bande passante : un seul flux depuis la source * Filtrage efficace au niveau du switch * Pas besoin de routeur pour le multicast local * Les stations non intéressées ne sont pas impactées ## Multicast à l'échelle Internet ```mermaid graph TB subgraph LAN_A[Site Multicast A] SRC[Source Multicast] -->|Flux| MR1[MRouteur A] H1[Hôte 1] -->|IGMP Join| MR1 end subgraph LAN_B[Site Multicast B] H2[Hôte 2] -->|"1. IGMP Join"| MR2[MRouteur B] H3[Hôte 3] -->|"1. IGMP Join"| MR2 end subgraph Internet[Infrastructure Internet] Cloud((Réseau Unicast Internet)) end MR1 -.->|"2. Tunnel Multicast"| Cloud Cloud -.->|"3. Tunnel Multicast"| MR2 style SRC fill:#f9f,stroke:#333 style MR1 fill:#ff9,stroke:#333 style MR2 fill:#ff9,stroke:#333 style H1 fill:#9f9,stroke:#333 style H2 fill:#9f9,stroke:#333 style H3 fill:#9f9,stroke:#333 style Cloud fill:#ddd,stroke:#333 ``` Dans ce cas de figure, où les groupes multicasts sont situés dans des différents réseaux à différents endroits de la planète, les **Mrouteur** (formant le réseau *Mbone = backbone multicast*) jouent un rôle important dans l'achemeninement du flux. Ces routeurs spéciaux comprennent le protocole IGMP qui est utilisé par les hôtes pour informer ceux-ci de leur appartenance à un groupe. Une subtilité qu'il y a, c'est que tous les routeurs dans Internet n'implémentent pas le protocole IGMP. C'est pour contourner cela qu'on fait appel à du **tunneling Multicast over Unicast** : encapsulant l'IP multicast dans de l'IP unicast pour pouvoir traverser ces routeurs non-multicast. ## Le protocole IGMP Comme annoncé auparavant, c'est le protocole qui permet au routeur de savoir de **façon dynamique** s'il existe des hôtes dans les groupes multicast au sein d'un réseau auquel il est connecté. IGMP est standardisé en plusieurs versions dans les [RFC 1112 - v1](https://www.rfc-editor.org/rfc/rfc1112) et [RFC 2236 - V2](https://www.rfc-editor.org/rfc/rfc2236). Le paquet IGMP est encapsulé dans un paquet IP permettant la communication entre le routeur et les hôtes de la manière suivante : ```mermaid sequenceDiagram Routeur->>Hôte: Request (requête) Hôte->>Routeur: Report (rapport) ``` ### Format de paquet IGMP ![Capture d’écran 2025-01-19 232035](https://hackmd.io/_uploads/Skupclsw1g.jpg) ### Remarque Comme IGMP est encapsulé dans IP, le module IP identifiera ce paquet IGMP grâce au **champ protocole** qui vaudra **2** dans le paquet IP. Voici un diagramme illustrant les phases importantes pendant la communication IGMP. ### Les phases importantes de IGMP ```mermaid sequenceDiagram participant Host as Hôte participant LocalRouter as Routeur de groupe local participant OtherRouters as Autres routeurs de groupe Note over Host: Phase 1 : Rejoindre un groupe Host->>LocalRouter: Diffuse un rapport IGMP LocalRouter->>LocalRouter: Reçoit le message et détermine le routage LocalRouter->>OtherRouters: Communique les informations aux autres routeurs Note over LocalRouter: Phase 2 : Vérification périodique LocalRouter->>Host: Interroge périodiquement pour vérifier l'appartenance Host-->>LocalRouter: Réponse (si toujours dans le groupe) Note over Host, LocalRouter: Une seule réponse par groupe est suffisante ``` > Quand un hôte rejoint un groupe, il envoie un rapport (REPORT) IGMP au routeur de son sous-réseau via IGMP. Le routeur ayant reçu cette information, diffuse ensuite celle-ci aux autres Mrouters. > La deuxième phase consiste en la vérification périodique des groupes par le routeur (REQUEST), pour s'assurer qu'il y a **au moins 1 hôte** existant au sein de chaque groupe, sinon il le relâche. > Pour éviter la saturation des réseaux, il suffit qu'un seul hôte réponde pour que le routeur garde le groupe dans sa table. ### La version 2, qu'a-t-elle amené de plus? L'amélioration apportée par la version 2 de IGMP c'est l'annonce de **départ ou désabonnement** d'une station. Ainsi, quand un hôte quitte un groupe multicast, il envoie un message **IGMP MEMBERSHIP LEAVE** à tous les Mrouters du sous-réseau via l'adresse réservée **224.0.0.2**. Aussitôt que le routeur recoit ce message, il envoie donc une requête au groupe concerné pour savoir s'il reste au moins un hôte. * Il faut savoir que le temps de réponse maximal à un REQUEST (QUERY) est modifiable.