---
# System prepended metadata

title: Multicast
tags: [Network]

---

# 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<br/>0.0.0.0 à 255.255.255.255]
        
        IP --> Unicast[Adresses Unicast<br/>Ex: 192.168.1.1]
        IP --> Multicast[Adresses Multicast<br/>224.0.0.0 à 239.255.255.255]
        
        subgraph Plages_Unicast[Plages Unicast Principales]
            Unicast --> ClassA[Classe A<br/>1.0.0.0 à 126.255.255.255]
            Unicast --> ClassB[Classe B<br/>128.0.0.0 à 191.255.255.255]
            Unicast --> ClassC[Classe C<br/>192.0.0.0 à 223.255.255.255]
        end
        
        subgraph Plages_Multicast[Plages Multicast]
            Multicast --> Local[Local Network Control Block<br/>224.0.0.0 à 224.0.0.255]
            Multicast --> InternetWork[InterNetwork Control<br/>224.0.1.0 à 238.255.255.255]
            Multicast --> Reserved[Reserved<br/>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<br/>Pas de séparation Network/Host]
    end

    subgraph Paquet_IP[Structure Paquet IP Multicast]
        IP[Paquet IP] --> SRC[Adresse Source:<br/>Toujours Unicast] & DST[Adresse Destination:<br/>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<br/>Ex: 192.168.1.10]
            U_Header --> Network[Partie Réseau<br/>Ex: 192.168.1]
            U_Header --> Host[Partie Hôte<br/>Ex: .10]
            Network --> Masque[Masque de sous-réseau<br/>définit la séparation<br/>Ex: 255.255.255.0]
        end

        subgraph Multicast[Structure Adresse Multicast]
            M_Header[Adresse Multicast<br/>Ex: 224.0.0.1]
            M_Header --> GroupID[Identifiant de Groupe<br/>pas de séparation réseau/hôte<br/>Ex: tout l'ID 224.0.0.1<br/>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<br/>4 bits]
        IP --> GroupIP[ID Groupe IP<br/>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<br/>01:00:5E:XX:XX:XX]
        MAC --> MACPrefix[Préfixe MAC<br/>25 bits<br/>01-00-5E-0]
        MAC --> GroupMAC[ID Groupe MAC<br/>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<br/>du groupe IP]
        Map --> Used[23 bits utilisés<br/>pour l'adresse MAC]
        Note[Plusieurs adresses IP<br/>peuvent correspondre à<br/>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<br/>192.168.1.10] -->|"Paquet Multicast<br/>Dest: 224.0.0.1<br/>MAC: 01:00:5E:00:00:01"| SW{Switch}
        
        SW -->|"1. IGMP Join<br/>2. Copie du flux"| PC1[PC1<br/>Membre du groupe<br/>IGMP Join envoyé]
        SW -->|"1. IGMP Join<br/>2. Copie du flux"| PC2[PC2<br/>Membre du groupe<br/>IGMP Join envoyé]
        SW -.->|"Pas de copie<br/>Non membre"| PC3[PC3<br/>Non membre<br/>Pas d'IGMP Join]
        SW -->|"1. IGMP Join<br/>2. Copie du flux"| PC4[PC4<br/>Membre du groupe<br/>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<br/>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.