Pourquoi Multicast est la base de réseaux audio AES67 efficaces

Les environnements modernes de production, de diffusion et de sons installés passent rapidement de connexions analogiques ou numériques à points en passant par des architectures audio-over-IP (AoIP) performantes. AES67, un standard ouvert développé par l'Audio Engineering Society qui assure l'interopérabilité entre différents écosystèmes AoIP. Cependant, simplement numériser l'audio et l'envoyer par Ethernet ne garantit pas l'efficacité. multicast, une méthode de transmission réseau qui permet à AES67 de fournir un son synchronisé et à faible latence à des dizaines ou même des centaines de destinations sans accaparer le réseau.

Pour les ingénieurs en réseau, les intégrateurs de systèmes et les techniciens audio, comprendre comment fonctionne la multidiffusion dans AES67 n'est plus facultatif. C'est une compétence essentielle pour concevoir des réseaux audio fiables, évolutives et à l'épreuve du futur. Cet article fournit un examen complet de la multidiffusion dans le contexte de AES67, couvrant ses fondements techniques, avantages et défis pratiques, lignes directrices de mise en œuvre et le paysage évolutif des normes AoIP.

Fondements multicasts : au-delà de la définition simple

La source envoie un seul flux de paquets, et l'infrastructure réseau réplique intelligemment ces paquets uniquement aux appareils qui ont explicitement demandé de les recevoir. unicast, lorsque la source doit envoyer une copie indépendante des données à chaque récepteur individuel, et à partir de diffusion, où les paquets sont livrés à chaque périphérique du segment réseau, quel que soit l'intérêt.

Adresse IP multidiffusion

Le trafic multicast fonctionne à l'intérieur d'un bloc réservé d'adresses IPv4: 224,0.0.0 à 239.255.255.2555 Dans cette gamme, des sous-catégories spécifiques servent à des fins différentes. Pour AES67, les administrateurs utilisent généralement des adresses dans la gamme 239.0.0.0/8 (administrativement globated) pour éviter les conflits avec Internet multicast global. Chaque flux audio se voit attribuer une adresse multicast unique, et les récepteurs s'abonnent à cette adresse pour recevoir le flux.

Considérations concernant les couches 2 et 3

Au calque 2 (la couche de lien de données), les adresses IP multicast sont cartographiées à Adresses MAC Ethernet commençant par 01-00-5F (pour IPv4). Cette cartographie n'est pas un à un: 32 adresses IP multicast map à la même adresse MAC, ce qui peut conduire à de faux positifs si le réseau n'est pas correctement configuré. Comprendre cette cartographie est crucial pour résoudre les problèmes de livraison de paquets fallacieux. Protocole Indépendant Multicast (PIM) construire des arbres de distribution et faire avancer le trafic multicast entre les segments de réseau.

IGP: Protocole d'abonnement

Les Protocole de gestion du groupe Internet (IGMP) est le protocole de signalisation qui permet aux récepteurs de rejoindre ou de quitter des groupes multicast. Lorsqu'un récepteur AES67 (par exemple, un DSP ou un haut-parleur réseau) veut recevoir un flux particulier, il envoie un rapport d'adhésion IGMP à son commutateur ou routeur local. Snooping des IGPG, écoute ces messages et configure dynamiquement sa table de renvoi de sorte que le trafic multicast n'est envoyé qu'aux ports où existent des récepteurs. Sans IGMP snooping, le commutateur inonderait le trafic multicast vers tous les ports, transformant efficacement le multicast en radiodiffusion et niant l'avantage d'efficacité.

IGMP est disponible en plusieurs versions. IGMPv3, qui prend en charge la diffusion multicast (SSM) spécifique à la source. La diffusion multicast permet à un récepteur de demander un flux à partir d'une adresse source spécifique, ce qui est utile dans les déploiements AES67 où plusieurs sources peuvent partager la même adresse multicast de groupe.

Le rôle de la diffusion multimédia dans le streaming audio AES67

AES67 définit une pile de protocole complète pour diffuser des sons de haute qualité sur des réseaux IP. RTP (Protocole de transport en temps réel) pour encapsuler des échantillons audio, PTPv2 (Protocole sur la durée de la décision, IEEE 1588-2008) pour la synchronisation, et SDP (Protocole de description de la session) Pour la découverte du flux. Multicast n'est pas strictement requis par la norme, mais c'est la méthode de livraison recommandée et la plus couramment utilisée pour les scénarios multirécepteurs.

Lorsqu'une seule source audio, comme la sortie principale d'une console de mixage, doit être distribuée à plusieurs destinations et mdash;say, un flux de radiodiffusion, un système d'enregistrement, un processeur de remplissage et un enregistreur de sauvegarde et mdash;unicast exigerait que la source produise quatre flux RTP distincts. Chaque flux consomme de la bande passante, de la puissance de traitement et de la mémoire sur le périphérique source.

Synchronisation et PTP

AES67 exige que tous les appareils du réseau se synchronisent avec une horloge commune, en général en utilisant PTPv2. L'horloge grand-maître PTP distribue des informations de chronométrage à l'aide de messages multicast (généralement à l'adresse 224.0.1.129). Les récepteurs utilisent ces messages de chronométrage pour aligner leurs horloges d'échantillonnage, en veillant à ce que tous les appareils rejouent l'audio exactement au même rythme.

Comme les messages de synchronisation PTP sont eux-mêmes multicasts, les principes de l'efficacité multicast s'appliquent également ici : un grand maître unique peut servir tout un domaine d'esclaves PTP sans créer un goulot d'étranglement unicast. Cependant, PTP nécessite une configuration réseau soigneuse pour s'assurer que les messages de synchronisation sont livrés avec une latence faible et déterministe.

RTP Streams et redondance

Les flux audio AES67 sont transmis sous forme de paquets RTP, en général à l'aide de L24 ou L16 format de charge utile pour un son PCM linéaire. Un seul flux de 48 kHz, 24 bits, 8 canaux consomme environ 9,2 Mbps de bande passante. Dans une configuration multicast, cette bande passante n'est utilisée qu'une seule fois sur des liens partagés, indépendamment du nombre de récepteurs connectés. Redondance des flux (parfois appelé "redondance sans soudure" ou "fusion sans fin"), où deux flux identiques sont envoyés sur différents groupes multicast et le récepteur bascule entre eux en fonction des paramètres de perte de paquets.

Aperçu pratique: Dans un environnement de production en direct, il est courant de configurer deux groupes multicast distincts pour le même contenu audio, acheminés sur des chemins de réseau physiquement divers. Le récepteur rejoint les deux groupes et utilise des numéros de séquence et des horodatages RTP pour synchroniser les deux flux. Lorsqu'un chemin subit une perte de paquets, le récepteur se déplace en douceur vers l'autre flux sans problèmes sonores.

Avantages de la diffusion multiple dans les déploiements AES67

Les avantages de la multidiffusion sont bien compris dans les cercles de réseautage, mais pour les professionnels de l'audio qui ne possèdent pas de connaissances en informatique profondes, il est utile de déterminer comment ces avantages se traduisent directement en améliorations opérationnelles.

Préservation de la largeur de bande sur les liens partagés

Dans un grand lieu avec 100 récepteurs Dante ou RAVENNA tous abonnés au même bus mixte, une approche unicast nécessiterait 100 flux RTP séparés traversant le commutateur de cœur. Chaque flux consomme de la bande passante, et lorsqu'il est multiplié par le nombre de sources dans une matrice typique, la bande passante agrégée peut facilement dépasser 1 Gbps. Multicast l'effondre à un seul flux sur le cœur, avec réplication se produisant seulement à la couche d'accès où les récepteurs sont situés.

Latence déterministe

Comme la diffusion multicast envoie une copie de chaque paquet et s'appuie sur des commutateurs réseau pour se reproduire au plan de renvoi, la latence de la source à tous les récepteurs est essentiellement identique. Ceci est critique pour les systèmes où plusieurs zones haut-parleurs doivent être alignées sur le temps, ou où un flux de diffusion doit arriver à la console et l'enregistreur de sauvegarde simultanément.

Configuration simplifiée des sources

Du point de vue du dispositif de transmission, multicast est une opération "fire and oubli". La source n'a besoin que de connaître son propre adresse multicast et son propre port RTP. Elle n'a pas besoin de tenir une liste d'adresses IP de récepteur, de gérer la configuration de connexion ou de gérer les requêtes de retransmission. Cela réduit la charge du processeur sur la source et simplifie la configuration des consoles de mélange, des boîtes de scène et des interfaces audio. Lorsqu'un nouveau récepteur est ajouté au réseau, il rejoint simplement le groupe multicast; aucun changement n'est nécessaire sur la source.

Écailabilité sans coût proportionnel

Dans un système unicast, l'ajout de récepteurs augmente la charge sur la source et les liaisons réseau. Dans un système multicast, l'ajout de récepteurs n'a pas d'impact sur la source et un impact minimal sur le réseau (seul le commutateur de couche d'accès où le récepteur est connecté voit du trafic supplémentaire).

Défis et considérations critiques

Multicast n'est pas une panacée. Elle introduit une complexité qui doit être gérée par la conception de réseau appropriée, la sélection des équipements, et les procédures opérationnelles.

IGMP Snooping et traitement des requêtes

Certains commutateurs à bas prix ne sont pas dotés de snooping IGMP ou ne l'appliquent pas mal, ce qui entraîne une inondation du trafic multicast dans tous les ports. Cela peut surcharger les appareils en aval et saturer les liaisons ascendantes. Même sur les commutateurs qui supportent l'insonorisation IGMP, la IGMP quireur Dans un réseau avec plusieurs VLAN ou sous-réseaux, un appareil (généralement le commutateur ou routeur de calque 3) doit agir comme le questionnaire pour les récepteurs de sondage périodiques et vérifier l'adhésion au groupe. Si le questionnaire échoue, le trafic multicast peut arrêter de circuler.

PIM et l'acheminement inter-VLAN

Lorsque le trafic AES67 doit franchir les frontières du réseau VLAN ou être acheminé entre les sous-réseaux, Protocole Indépendant Multicast (PIM) PIM construit des arbres de distribution qui indiquent aux routeurs où faire avancer les paquets multicasts. La configuration de PIM est significativement plus complexe que la configuration du routage unicast. Mode PIM Sparse et Mode PIM DensePour AES67, le mode Sparse avec un point de rendez-vous (RP) est l'approche la plus courante, mais il introduit un point d'échec potentiel unique et nécessite une planification minutieuse du placement et de la redondance du point de rendez-vous.

Congestion du réseau et QoS

Si les flux multicasts sont trop nombreux sur un commutateur, le trafic global peut dépasser la vitesse du port ou la capacité du rétroplan. Qualité du service (QoS) Il faut configurer les paquets RTP AES67 (et les messages de synchronisation PTP) pour les meilleurs efforts de trafic tels que les transferts de fichiers, la navigation sur le Web ou les flux vidéo. L'approche standard consiste à attribuer le trafic AES67 à une file d'attente hautement prioritaire (généralement DSCP EF ou CS7 pour PTP, et AF41 ou AF42 pour les données audio) et s'assurer que le commutateur impose une file d'attente prioritaire stricte.

Gestion et coordination des activités

Dans une grande installation avec plusieurs sources AES67, la gestion des adresses multicasts de groupes peut devenir un défi de coordination. Deux sources qui utilisent accidentellement la même adresse multicasts de groupes et le port UDP provoqueront des conversations croisées, les récepteurs entendant les deux flux superposés. SAP (Protocole d'annonce de session) ou un serveur d'allocation d'adresse multicast dédié, est recommandé pour les réseaux avec plus d'une poignée de flux. De nombreuses plateformes de contrôle AoIP, comme le contrôleur Dante d'Audinate ou les outils de RAVENNA, aident à automatiser cette coordination, mais la responsabilité sous-jacente pour éviter les conflits d'adresses incombe au concepteur du système.

Mise en œuvre de la multidiffusion pour AES67: un guide pratique

La conception et le déploiement d'un réseau AES67 multicast nécessite une approche structurée qui intègre les exigences audio aux meilleures pratiques en TI. Les étapes suivantes fournissent un cadre pour une mise en œuvre réussie.

Étape 1: Sélection et vérification de l'équipement réseau

Tous les commutateurs réseau ne conviennent pas à AoIP. Sélectionnez des commutateurs gérés qui prennent explicitement en charge:

  • Snooping des IGPG (de préférence IGMPv3) avec fonctionnalité de questionr configurable.
  • PIM (pour les déploiements routés) avec support pour le mode PIM Sparse.
  • QoS avec au moins quatre files d'attente et un support pour la classification basée sur DSCP.
  • PTP horloge transparente ou horloge limite le soutien à la propagation précise des horaires dans l'ensemble du réseau.
  • Support de cadre Jumbo (bien que AES67 ne l'exige pas, les cadres jumbo peuvent améliorer l'efficacité sur les flux de nombres de canaux élevés).

Les commutateurs de fabricants tels que Cisco, Arista, Netgear (série M4250) et Luminex sont couramment utilisés dans les installations AES67. Toujours tester l'interrupteur dans un environnement de laboratoire avec des charges de trafic réalistes avant de le déployer dans un système de production.

Étape 2: Segmentation du VLAN et mise en valeur multicast

Séparer le réseau en VLAN séparés pour le trafic audio, le contrôle et les TI générales. Ceci isole les flux audio multidiffusion des domaines de diffusion qui contiennent des imprimantes, des serveurs DHCP ou d'autres dispositifs de chat. Au sein du VLAN audio, limiter les adresses de groupes multidiffusion à une plage bien définie (p. ex., 238.0.0.0/8) et s'assurer qu'aucun autre VLAN ne fuit le trafic multidiffusion dans le VLAN audio. Filtre IGMP sur les ports d'accès pour empêcher les dispositifs non autorisés d'injecter ou de recevoir des flux multicasts.

Étape 3: Configuration du domaine PTP

Désignez une seule horloge grandmaster PTP (généralement un appareil dédié ou un commutateur réseau haute performance) et configurez tous les appareils AES67 comme esclaves PTP. IEEE 1588-2008 Le profil spécifié dans AES67 (souvent appelé « profil AES67 » ou « profil IEEE 1588 pour AoIP ») s'assure que les messages de synchronisation PTP sont assignés à la priorité QoS la plus élevée (DSCP CS7) et que le chemin réseau entre le grand maître et tous les esclaves a une latence symétrique et faible.

Étape 4 : Gestion des volets et des PDD

Assigner chaque flux audio une adresse de groupe multicast unique et un port UDP. Documenter ces affectations dans une base de données centralisée ou utiliser un outil de gestion automatique de l'adresse. Générer des fichiers SDP pour chaque flux qui comprennent l'adresse multicast, le type de charge utile RTP, le taux d'échantillonnage, la profondeur de bits et le nombre de canaux. Système d'information géographique pour distribuer automatiquement les annonces SDP, mais soyez conscient que SAP utilise lui-même multicast (224.2.127.254) et doit être configuré en conséquence.

Étape 5 : Essais et surveillance

Après le déploiement, vérifier l'opération multicast à l'aide d'outils d'analyse de réseau tels que Filière (avec les dissecteurs IGP et RTP), iperf (avec support multicast), ou des outils de surveillance AoIP dédiés comme Dante Carte Son Virtuelle ou Appareil audio virtuel RAVENNA. Vérifiez que les jointures IGMP sont correctement signalées, que le trafic multicast n'atteigne que les ports avec récepteurs actifs, et que les jitters et latences restent dans la tolérance AES67 (généralement moins de 1 ms). Surveillez l'utilisation du processeur de l'interrupteur et la taille de la table de renvoi multicast pour s'assurer que le plan de contrôle peut gérer le nombre de groupes concurrents.

Multidiffusion dans les écosystèmes AoIP : AES67, Dante, RAVENNA et Livewire

AES67 est une norme d'interopérabilité, pas une plateforme complète. Les déploiements du monde réel impliquent souvent des dispositifs provenant de plusieurs écosystèmes fournisseurs, chacun avec sa propre mise en œuvre de multicast.

Dante

Le protocole Dante d'Auvinate utilise une couche de contrôle propriétaire sur les flux RTP compatibles AES67. Les appareils Dante supportent à la fois uncast et multicast, mais uncast est la valeur par défaut pour les connexions point à point. Multicast dans Dante est généralement utilisé pour la distribution un à plusieurs, comme l'envoi d'un mix master à plusieurs processeurs de zone. Dante Controller fournit une interface simple pour permettre les flux multicasts, mais le réseau sous-jacent doit encore supporter l'instantannage IGMP et le timing PTP. Horloge Dante ), qui adhère à la même norme PTPv2 utilisée dans AES67.

RAVENNA

RAVENNA est un protocole ouvert développé par ALC NetworX qui a été un prédécesseur direct d'AES67. RAVENNA utilise largement la diffusion multicast pour le transport en flux et la découverte des appareils (via SAP). Les réseaux RAVENNA sont souvent déployés dans des applications de radiodiffusion et de sonorisation en direct où la latence déterministe et la redondance sont critiques.

Livewire (Alliance de télécommunications)

Le livewire, utilisé principalement dans la radio de radiodiffusion, prend également en charge les flux multicast compatibles avec AES67. Gestionnaire de fils live L'écosystème Livewire a tendance à utiliser un nombre relativement faible de groupes multicast par rapport à Dante ou RAVENNA, ce qui simplifie la gestion des adresses mais peut limiter la flexibilité dans les très grandes installations.

A emporter : Quel que soit l'écosystème, les exigences du réseau sous-jacent pour la multidiffusion sont les mêmes. Tout commutateur ou routeur qui supporte AES67 doit bien gérer IGMP, PIM (si routé) et QoS. Les outils spécifiques aux fournisseurs peuvent simplifier la gestion du flux, mais ils ne peuvent pas compenser une infrastructure réseau mal conçue.

Dépannage des enjeux communs multicasts dans AES67

Même avec une planification minutieuse, des problèmes multicast peuvent se poser. Voici quelques-uns des problèmes les plus fréquemment rencontrés et leurs solutions.

Récepteurs ne recevant pas de flux

Si un récepteur ne reçoit pas de flux AES67, commencez par vérifier que l'appareil a rejoint le bon groupe multicast. Utilisez l'interface web du récepteur ou un outil en ligne de commande pour vérifier l'adhésion au groupe IGMP. Ensuite, confirmez que la table de snooping IGMP du commutateur inclut le port du récepteur pour le groupe attendu. Si l'interrupteur affiche la connexion mais aucun trafic ne circule, vérifiez un questionnaire IGMP manquant ou mal configuré. Du côté source, vérifiez que l'appareil transmet effectivement des paquets RTP à l'adresse multicast à l'aide d'une capture de paquets.

Décrochages audio intermittents

Si le décalage dépasse 1 ms, examinez le chemin réseau entre le grand maître et l'esclave. Recherchez les liaisons encombrées, les QoS mal configurés (par exemple, le trafic audio étant placé dans la même file d'attente que le trafic le mieux placé) ou le positionnement suboptimal de l'horloge limite PTP. Vérifiez également que la table de renvoi multicast du commutateur ne déborde pas; si le commutateur ne fonctionne plus des entrées matérielles pour les groupes multicast, il peut revenir à la transmission logicielle, qui introduit la latence et le jeu.

Tempête ou inondations multicast

Une tempête multicast se produit lorsque le trafic multicast est en inondation vers tous les ports parce que le snooping IGMP est désactivé ou dysfonctionnement. Cela peut surcharger les récepteurs qui ne s'attendent pas au trafic et saturer les liaisons montantes. Pour résoudre cela, activez le snooping IGMP sur tous les commutateurs du réseau, configurez un questionr (généralement sur le commutateur central ou le routeur de la couche 3) et vérifiez qu'aucun snooping ne fonctionne en mode "IGMP snooping disabled". contrôle des tempêtes fonctionnalités sur les ports bord pour limiter la quantité de trafic multicast qui peut entrer dans le réseau à partir de dispositifs non autorisés.

Régler les conflits

Si deux sources utilisent la même adresse multicast et le même port UDP, les récepteurs recevront les deux flux mélangés. Résolvez cela en mettant en œuvre un plan centralisé d'attribution d'adresses. De nombreux contrôleurs AoIP, comme Dante Controller ou le gestionnaire de flux de RAVENNA, détectent automatiquement et annoncent les conflits d'adresses. Si vous opérez dans un environnement purement AES67 sans contrôleur, maintenez un tableur ou une base de données d'adresses attribuées et appliquez une coordination stricte pendant la conception du système.

L'avenir de la multidiffusion dans AoIP: ST 2110, AVB et au-delà

AES67 n'est pas le dernier mot dans le réseau audio professionnel. SMPTE ST 2110 ST 2110-30 (le composant audio) est directement basé sur AES67 et utilise les mêmes mécanismes multicast et PTP. Avec l'adoption ST 2110, le rôle de multicast dans les réseaux professionnels de médias deviendra encore plus critique. Les exigences de bande passante de la vidéo 4K non comprimée sont substantielles, et l'efficacité multicast est essentielle pour le routage des flux vidéo vers de multiples zones de production sans multiplier l'utilisation de bande passante.

Radio Vidéo Bridging (AVB) / Réseautage sensible au temps (TSN) AVB/TSN introduit des protocoles de réservation de flux IEEE 802.1Qat qui allouent dynamiquement la bande passante et mettent en place des voies de transfert multicast avec une latence garantie. Bien qu'AVB/TSN n'est pas encore omniprésent dans l'audio professionnel, il offre la promesse de configuration multicast plug-and-play sans gestion manuelle IGMP ou PIM. Les réseaux hybrides qui combinent AES67 multicast avec la réservation de flux AVB/TSN commencent à émerger, en particulier dans les applications embarquées et automobiles.

Réseau de logiciels (SDN) Dans un réseau basé sur le SDN, un contrôleur centralisé gère les tables de renvoi de tous les commutateurs, permettant un contrôle fin sur la distribution multicast sans compter sur IGMP ou PIM. Cela pourrait simplifier la configuration de très grands réseaux AES67, bien que le SDN pour AoIP reste aujourd'hui une application de niche.

Conclusion

Multicast n'est pas seulement une caractéristique de AES67; c'est la base sur laquelle sont construits des réseaux audio-over-IP évolutifs, efficaces et synchronisés. En transmettant un flux RTP unique à plusieurs récepteurs grâce à une réplication intelligente du réseau, multicast réduit la consommation de bande passante, simplifie la configuration des sources et assure une latence déterministe sur tous les points d'arrêt.

L'investissement dans l'apprentissage des fondamentaux et des meilleures pratiques multicasts est rentable pour la fiabilité du système, la facilité d'expansion et la capacité d'intégrer des dispositifs provenant de multiples écosystèmes AoIP. À mesure que l'industrie se dirige vers des comptes de canaux plus élevés, l'adoption plus large de la norme ST 2110 et l'intégration des technologies TSN, les principes de multicasts demeureront au cœur du réseau audio professionnel.

Ressources supplémentaires :