📡 Guide Internet & Fibra

IPTV e multicast IGMP su fibra: come viaggia la TV in rete

Come funziona la distribuzione IPTV su rete FTTH tra multicast, IGMP snooping e VLAN dedicate, e perché a volte il decoder perde i canali.

Redazione Velix29 luglio 20266 min di lettura
📡

La TV via internet non funziona come lo streaming di Netflix o YouTube. Quei servizi usano unicast: ogni utente apre una connessione dedicata verso il server. L'IPTV tradizionale degli operatori usa invece il multicast, e questa differenza cambia tutto nel modo in cui la rete va progettata e configurata.

Unicast, broadcast, multicast

Tre modi diversi di consegnare lo stesso pacchetto:

  • Unicast: un mittente, un destinatario. Mille utenti che guardano lo stesso canale generano mille flussi identici.
  • Broadcast: il pacchetto arriva a tutti i dispositivi del segmento di rete, che lo vogliano o no. Inefficiente e limitato al dominio di livello 2.
  • Multicast: il mittente invia un solo flusso verso un indirizzo di gruppo, e la rete lo replica solo sui rami dove qualcuno lo ha richiesto.

Il multicast usa l'intervallo IPv4 224.0.0.0/4. Un canale TV corrisponde a un gruppo, ad esempio 239.1.1.10:1234. Se sulla stessa OLT ci sono 300 utenti sintonizzati sullo stesso canale, in rete viaggia un solo flusso da 8 Mbps invece di 2,4 Gbps di traffico unicast duplicato.

Il ruolo di IGMP

IGMP (Internet Group Management Protocol) è il protocollo con cui un dispositivo dichiara alla rete a quale gruppo multicast vuole iscriversi. Quando cambi canale sul decoder succede questo:

  1. Il decoder invia un IGMP Leave per il gruppo del canale precedente.
  2. Invia un IGMP Join per il gruppo del nuovo canale.
  3. Il router più vicino, se non sta già ricevendo quel flusso, lo richiede a monte.
  4. Il flusso arriva e il decoder inizia a decodificare.

Tutta la catena deve completarsi in poche centinaia di millisecondi, altrimenti il cambio canale diventa lento. È il motivo per cui l'IPTV degli operatori zappa più velocemente di un servizio OTT: il flusso è già presente sulla rete di accesso e va solo instradato sull'ultimo tratto.

Le versioni rilevanti sono IGMPv2 e IGMPv3. La v3 supporta il source-specific multicast (SSM), che permette di iscriversi a un gruppo specificando anche la sorgente: più sicuro, perché impedisce a un host qualsiasi di iniettare traffico in un gruppo esistente.

IGMP snooping sugli switch

Uno switch di livello 2 non capisce IGMP: tratterebbe il traffico multicast come broadcast, inondando tutte le porte. Su una rete domestica con un flusso 4K da 25 Mbps significa saturare ogni link, incluso il Wi-Fi.

L'IGMP snooping risolve il problema: lo switch osserva i messaggi IGMP che transitano e costruisce una tabella porta/gruppo, inoltrando ogni flusso solo dove serve. Va abilitato su tutti gli switch della catena. Insieme allo snooping serve quasi sempre un IGMP querier, cioè un dispositivo che interroga periodicamente i membri dei gruppi per tenere aggiornate le tabelle. Se manca il querier, dopo qualche minuto le tabelle scadono e il video si blocca: è un classico sintomo di rete configurata a metà.

VLAN dedicata e QoS

Sulla maggior parte delle architetture FTTH il traffico IPTV viaggia su una VLAN separata da quella dati. I motivi sono pratici:

  • Isolamento del dominio broadcast, così lo snooping lavora su un perimetro ristretto.
  • Marcatura DSCP coerente e code prioritarie sugli apparati: il video multicast non ha ritrasmissioni, un pacchetto perso è un artefatto visibile.
  • Contabilizzazione separata, dato che il traffico IPTV di solito non consuma banda di transito internet.

Lato utente questo si traduce nella necessità che il router supporti il VLAN tagging sulla porta a cui è collegato il decoder, oppure che faccia da proxy IGMP tra la VLAN WAN e la LAN. I router forniti dall'operatore lo fanno di serie; sostituendoli con un apparato proprio, questa è la funzione che si rompe per prima.

Perché il Wi-Fi è il punto debole

Il multicast su Wi-Fi viene trasmesso al data rate più basso supportato dalla cella, senza acknowledgment e senza ritrasmissione. Un flusso video da 15 Mbps consegnato a 6 Mbps di rate effettivo semplicemente non passa. Le contromisure disponibili:

  • Multicast-to-unicast conversion (multicast enhancement), che l'access point applica convertendo il flusso in unicast per ogni client iscritto. Efficace fino a pochi client.
  • Directed Multicast Service (DMS), previsto da 802.11v, con lo stesso principio ma negoziato dal client.
  • Collegare il decoder via cavo, che resta la soluzione più affidabile.

Diagnosi rapida dei problemi comuni

SintomoCausa probabile
Video a scatti solo su alcuni canaliPerdita di pacchetti sul flusso specifico, o banda insufficiente sul canale HD
Il video si blocca dopo 3-5 minutiManca l'IGMP querier, tabelle di snooping scadute
Nessun canale dopo cambio routerVLAN IPTV non taggata o proxy IGMP disattivato
Rete lenta quando la TV è accesaIGMP snooping disabilitato, flooding multicast su tutte le porte
Zapping lentissimoJoin IGMP non propagati, flusso richiesto ogni volta a monte

Per verificare cosa sta realmente accadendo, tcpdump -i eth0 igmp mostra join e leave in tempo reale, mentre sugli switch gestiti il comando di dump della tabella multicast (la sintassi varia per vendor) dice esattamente quali gruppi sono attivi e su quali porte.

In sintesi

L'IPTV funziona bene quando l'intera catena, dall'OLT alla presa Ethernet, parla la stessa lingua: multicast instradato correttamente, snooping attivo con querier presente, VLAN dedicata e priorità di coda. Basta un anello non configurato per trasformare un servizio che consuma pochissima banda in una fonte di problemi diffusi su tutta la rete.

Vuoi portare Velix a casa tua?

Verifica la copertura FTTH al tuo indirizzo in 30 secondi. Gratis, senza impegno.

Verifica copertura →