Le réseau audio est devenu l'épine dorsale des environnements modernes de renforcement sonore, de production de radiodiffusion et d'enregistrement en studio. La norme AES67, officiellement intitulée -AES67-2018 : norme AES pour les applications audio des réseaux – Interopérabilité audio-over-IP en continu à haute performance – répond à ce besoin en fournissant un cadre commun qui permet aux appareils audio de différents fabricants de communiquer sans heurt. Une composante essentielle de la réussite AES67 est son approche robuste de la qualité du service (QoS), qui garantit que les données audio sensibles au temps arrivent intactes, dans l'ordre et à temps, même lorsque le réseau transporte d'autres trafics. Cet article explore chaque mécanisme QoS essentiel au sein de l'AES67, offre des conseils de configuration concrets et explique pourquoi le déploiement QoS sépare un système professionnel stable d'un système éprouvé par les abandons et les glissades.

Qu'est-ce que la qualité du service (QoS) dans AES67?

Dans les réseaux IP, tous les paquets sont traités de la même manière par défaut, une situation appelée -best-effort . Bien que cela fonctionne bien pour la navigation web, les e-mails ou les transferts de fichiers, il est tout à fait inacceptable pour les flux audio en temps réel, où les paquets tardifs ou perdus entraînent des abandons audibles, des glissades ou une perte complète de synchronisation. QoS change cette situation en accordant une priorité plus élevée aux paquets audio, en s'assurant qu'ils sont transmis avant moins de temps critique. Dans un déploiement AES67, QoS n'est pas un ajout facultatif; les comportements spécifiques mandatés par chaque appareil conforme doivent être pris en charge, y compris les mécanismes prioritaires Layer 3 (IP) et Layer 2 (Ethernet). Cette approche à double couche donne aux concepteurs de systèmes la flexibilité d'appliquer QoS dans divers environnements réseau, des configurations simples à un seul commutateur aux réseaux complexes à large aire route couvrant plusieurs bâtiments ou même des villes.

Le rôle de la QS dans le maintien de l'intégrité audio

Pourquoi le QoS est-il si crucial dans un réseau AES67 ? La réponse réside dans la nature des paquets audio. Les flux AES67 transportent généralement plusieurs canaux audio non compressés de modulation de code pulsé (PCM), avec des tailles de paquets conçues pour minimiser la latence tout en maintenant l'efficacité. Un flux AES67 typique peut envoyer des paquets toutes les 125 microsecondes (pour un paquet de 8 échantillons à 48 kHz) ou toutes les 1 millisecondes (pour un paquet de 48 échantillons). Toute variation de délai significative – appelée -jitter - ou perte de paquets va dégrader la qualité audio.

QoS s'attaque directement à ces problèmes par :

  • Réduction de la latence: La file d'attente prioritaire garantit que les paquets audio passent moins de temps à attendre dans les tampons de commutation. Lorsqu'un éclatement du trafic de transfert de fichiers arrive, les paquets non prioritaires sont en file d'attente pendant que les paquets audio sautent sur le devant.
  • Minimiser les jitters : Les récepteurs audio peuvent ensuite utiliser de petits tampons de jitter (souvent <1 ms) sans risquer de sous-courants.
  • Éliminer la perte de paquets : En réservant la bande passante et en marquant les paquets, QoS empêche la congestion de forcer la chute des paquets audio. Même un seul paquet perdu peut produire un clic audible, donc zéro perte est le but.

Au-delà de ces avantages de base, QoS protège également les paquets Precision Time Protocol (PTP) qui synchronisent tous les appareils AES67. Si le timing PTP est retardé ou perdu, la précision de l'horloge du réseau entier se dégrade, ce qui entraîne des sous-exécutions ou des dépassements de tampons dans chaque flux audio.

Mécanismes clés de QoS définis par AES67

La norme AES67 s'appuie sur plusieurs technologies de réseau bien établies pour atteindre ses garanties QoS. Ces mécanismes fonctionnent à différentes couches du modèle OSI et se complètent pour créer une couche de transport audio fiable. La compréhension de chaque mécanisme et de leur interaction est essentielle pour toute personne qui conçoit, déploie ou dépanne les réseaux AES67.

1. Point de code de services différencié (CPSD) – couche 3 QoS

DSCP est le mécanisme primaire de QoS de la couche 3 utilisé dans AES67. Il fonctionne en insérant une valeur 6 bits dans l'octet Type de Service (ToS) de chaque paquet IP. Les routeurs et les commutateurs de la couche 3 peuvent être configurés pour examiner ce marquage DSCP et placer les paquets dans la file d'attente prioritaire appropriée. AES67 définit trois valeurs DSCP spécifiques pour différentes classes de trafic:

  • AES67 Audio Streams – DSCP 46 (EF – Transaction accélérée) : Il s'agit de la plus haute priorité, utilisée uniquement pour la charge utile audio. EF assure un délai faible, un faible jitter et une faible perte – souvent appelé traitement -premium-. Dans la pratique, le trafic EF devrait être surveillé pour empêcher tout flux unique de surcharger la file d'attente prioritaire.
  • AES67 Contrôle et découverte – DSCP 56 (CS7): Le contrôle du trafic comme les annonces SAP et la gestion de la connexion est indiqué par le sélecteur de classe 7 pour s'assurer que la signalisation critique n'est pas bloquée. Bien que les paquets de contrôle soient petits, les perdre peut empêcher les appareils de se découvrir ou de maintenir une connexion.
  • AES67 PTP (Protocole de délai de précision) – DSCP 46 (EF) ou DSCP 44 (CS5): Les paquets PTP contiennent des informations de synchronisation que tous les appareils doivent rester synchronisés. De nombreuses implémentations utilisent le même marquage EF que l'audio, ou une priorité légèrement inférieure comme CS5 pour éviter toute interférence avec l'audio si les ressources de file d'attente sont rares. Une configuration commune est de placer PTP dans une file d'attente strictement prioritaire dédiée avec une garantie de bande passante très petite, en s'assurant qu'il est servi avant tout sauf l'audio.

Malheureusement, de nombreux commutateurs de qualité entreprise ont différents modèles de confiance par défaut : certains ne font confiance qu'à la couche 2 QoS (802.1p), tandis que d'autres peuvent être configurés pour faire confiance à DSCP. Une configuration adéquate est essentielle pour empêcher que les paquets audio ne soient remarqués ou déclassés au meilleur effort. Par exemple, un commutateur Cisco réglé à --non-fidulisé sur un port d'accès va supprimer le champ DSCP, détruisant instantanément la priorité.

2. IEEE 802.1Q Points de marquage VLAN et de code de priorité (PCP) – couche 2 QoS

Au calque 2, AES67 prévoit l'utilisation de l'étiquette IEEE 802.1Q VLAN pour les flux audio. Une étiquette VLAN contient un champ 3 bits de code de priorité (CPP) qui peut spécifier huit niveaux de priorité (0 à 7). La norme AES67 recommande une valeur de 5 PCP pour le trafic audio, ce qui correspond à des applications critiques dans la cartographie de priorité 802.1Q.

  • Séparation du trafic audio : Placer l'audio dans un VLAN dédié l'isole des tempêtes de radiodiffusion, du bruit multicast et d'autres trafics de données qui pourraient causer des congestions. Un VLAN séparé simplifie également l'application de la sécurité ACL et la surveillance de l'utilisation de la bande passante.
  • Priorité par hub : Les commutateurs Ethernet qui ne prennent pas en charge DSCP peuvent toujours utiliser la valeur PCP pour prioriser les paquets audio sur d'autres VLAN ou trafic non identifié. Même lorsque DSCP est fiable, la priorité Layer 2 fournit un mécanisme de recul sur les commutateurs plus simples.

Il est important de noter que le marquage VLAN seul n'est pas suffisant pour la QoS de bout en bout dans les réseaux routés. Le marquage PCP est supprimé lorsqu'un paquet traverse un routeur à moins que le commutateur et le routeur ne soient configurés pour mapper la priorité de calque 2 vers DSCP. Par conséquent, un réseau AES67 robuste doit avoir une configuration QoS cohérente entre les deux couches. De nombreux ingénieurs utilisent une carte politique sur l'interface routée qui copie le PCP vers DSCP, ou ils comptent sur le paramètre pour définir correctement DSCP afin que la priorité de calque 2 en soit dérivée.

3. Réservation de bande passante et contrôle d'admission

Bien que la norme ne soit pas strictement un QoS --mécanisme au sens du DSCP, AES67 encourage l'utilisation de techniques de réservation de bande passante pour empêcher la surabonnement de liens réseau. La norme définit une bande passante maximale admissible pour les flux AES67 sur un segment donné du réseau, généralement 100 Mbps pour Gigabit Ethernet pour laisser la tête d'entrée pour d'autres trafics. Les ingénieurs en réseau peuvent utiliser des protocoles comme le Protocole de réservation de ressources (RSVP) pour demander dynamiquement la bande passante pour les flux audio, bien que RSVP n'est pas obligatoire dans AES67. Dans la pratique, la planification manuelle de la bande passante est souvent préférée pour garantir un comportement déterministe.

4. Protocole de précision du temps (PTP) et son rapport avec la QoS

Tous les appareils doivent synchroniser avec une horloge commune en utilisant IEEE 1588-2008 (PTPv2). Les paquets PTP sont eux-mêmes critiques en temps; s'ils sont retardés ou perdus, la précision de l'horloge se dégrade, entraînant des sous-tours ou des dépassements de tampons. QoS s'applique donc aussi au trafic PTP. AES67 recommande de marquer PTP avec le même DSCP de transit accéléré en audio (46) ou, au minimum, un sélecteur de classe 5 (CS5, DSCP 40). De nombreux déploiements dans le monde réel consacrent un groupe VLAN ou multicast distinct pour PTP pour l'isoler d'autres trafics, réduisant ainsi encore les risques de variation de retard.

De plus, les commutateurs qui prennent en charge les horloges PTP ou les horloges transparentes peuvent corriger les retards de pont, mais ces fonctionnalités exigent que QoS fonctionne correctement.

Pourquoi QoS n'est pas négociable pour les réseaux audio professionnels

Dans toute application audio professionnelle, d'une comédie musicale de Broadway à une émission de nouvelles en direct, les tolérances pour la latence, le jeu et la perte de paquets sont extrêmement serrés. L'oreille humaine peut détecter même un seul paquet perdu si cela donne lieu à un clic ou une pop, et le jeu de quelques millisecondes peut causer une distorsion audible ou perturber la synchronisation entre haut-parleurs. Les mécanismes QoS fournissent les garde-corps nécessaires pour que les réseaux AES67 répondent à ces exigences précises.

Budgets de latence en direct

Pour le renforcement sonore en direct, la latence de bout en bout doit généralement rester inférieure à 10 millisecondes, et souvent beaucoup moins. Chaque hop réseau – interrupteur, routeur ou câble – ajoute une petite quantité de latence. Sans QoS, une explosion de données d'un transfert de fichier ou d'un flux vidéo peut remplir les tampons de commutation, ce qui fait que les paquets audio sont en attente derrière des dizaines de paquets non audio. Ce -bufferbloat - peut ajouter des dizaines de millisecondes de retard imprévisible, rendant le système inutilisable. Avec les marquages DSCP et PCP appropriés, les paquets audio contournent ces files, maintenant la latence constante et faible.

Impact de la perte de paquets sur la fidélité audio

AES67 utilise le protocole de transport en temps réel (RTP) sur UDP, qui ne retransmet pas les paquets perdus. Par conséquent, toute perte de paquets corrompt directement la forme d'onde audio. Bien que certains appareils récepteurs puissent cacher un petit nombre d'échantillons perdus consécutifs, une perte persistante de même 0,1% des paquets peut être audible. QoS empêche la perte en s'assurant que le réseau n'arrive jamais à un point où les paquets audio sont rejetés en raison de la congestion.

Synchronisation et stabilité de l'horloge

Un réseau fortement encombré peut provoquer l'arrivée tardive des paquets PTP, ce qui entraîne la dérive des algorithmes de récupération d'horloges dans les récepteurs. Au fil du temps, cette dérive entraîne des débordements ou des écoulements sous-jacents de tampons, qui se manifestent par des glissades ou un silence. En appliquant un traitement QoS généreux au trafic PTP, les ingénieurs du réseau s'assurent que tous les appareils restent synchronisés avec précision, souvent dans des limites de précision sous-microsecondes, comme l'exige AES67. Certaines implémentations utilisent un profil PTP dédié (comme SMPTE ST 2110-10) qui resserre encore les exigences de temps, rendant QoS encore plus critique.

Mise en oeuvre de la QS dans un réseau AES67 – Pratiques exemplaires

Déployer un réseau AES67 réussi nécessite une configuration soignée à chaque périphérique réseau le long du chemin de données. Ci-dessous sont des étapes concrètes et des considérations pour la mise en œuvre de QoS qui répond aux recommandations AES67. Ces étapes supposent un réseau Layer 2/3 géré avec du matériel qui prend en charge les fonctionnalités standard de QoS. Les principes s'appliquent à Cisco, Arista, Juniper, HP, et la plupart des autres familles de commutateurs d'entreprise.

Étape 1: Faites confiance aux bons repères

Les commutateurs modernes gérés peuvent être configurés pour faire confiance aux valeurs DSCP des paquets entrants. Ce -boundary -trust doit être défini aux ports de commutation qui se connectent aux terminaux AES67. Si un port de commutation est défini à -untrusted , le commutateur re-marquera la valeur DSCP à zéro, en retirant la priorité. Configurez toujours les ports d'accès connectés aux périphériques audio avec (Cisco) ou des commandes équivalentes sur d'autres marques. Pour les ports de réseau se connectant à d'autres commutateurs, la confiance devrait être maintenue, bien que certains administrateurs préfèrent appliquer une politique spécifique à ces points en utilisant une carte de politique par port.

Il est également sage de configurer les ACL qui permettent uniquement des marquages DSCP élevés à partir d'adresses IP connues des périphériques AES67, empêchant le trafic voyou de revendiquer la priorité.

Étape 2 : Carter les calques 2 à 3 de façon cohérente

Tous les commutateurs n'inspectent pas DSCP, surtout ceux de la couche d'accès qui ne regardent que 802.1p PCP. Pour combler l'écart, vous pouvez créer une politique de mappage qui convertit le PCP entrant en marquage DSCP sur les interfaces routées. Cela garantit que lorsqu'un paquet quitte une limite de la couche 3, sa balise DSCP est correcte. Inversement, en cours d'expédition, le DSCP peut être traduit en PCP si nécessaire. Par exemple, sur un commutateur Cisco, vous pouvez configurer une carte de classe qui correspond au PCP 5 et définit DSCP 46.

Cette mappage doit être appliqué à toutes les interfaces où le trafic AES67 est attendu.

Étape 3: Bande passante de réserve pour les flux audio

Bien que les flux AES67 soient relativement petits, soit 48 canaux à 24 bits, 48 kHz pourraient consommer environ 24 Mbps, ce qui permet de stabiliser rapidement un lien réseau. Utilisez le marquage DSCP EF pour garantir une bande passante minimale pour l'audio. Beaucoup de plates-formes de commutation prennent en charge les mécanismes de queue comme la file d'attente prioritaire (PQ) ou la file d'attente à faible latence (LLQ). Le trafic audio devrait être placé dans la file d'attente prioritaire, mais attention à ne pas la sous-inscrire : si la file d'attente prioritaire reçoit plus de trafic que le lien peut transporter, des gouttes de queue se produiront.

Étape 4: Isoler le PTP sur un VLAN dédié

Bien que le trafic PTP utilise DSCP EF ou CS5, de nombreux ingénieurs préfèrent le séparer davantage en plaçant PTP dans un groupe multicast dédié et VLAN. Cette pratique simplifie le dépannage et empêche les données de contrôle de se mélanger avec la charge utile audio. Le VLAN PTP devrait également être accordé une priorité élevée de QoS, éventuellement avec un policier encore plus strict pour s'assurer que les paquets de synchronisation ne sont jamais retardés par de grands flux audio multicast. Certains réseaux vont jusqu'à utiliser une adresse multicast PTP séparée et un VLAN séparé pour le timing seulement, avec sa propre file d'attente prioritaire. Cette isolation aide également lorsque l'utilisation des horloges limites PTP qui doivent traiter des messages PTP sans interférence du trafic audio.

Étape 5: Essai et validation

Des outils comme iPerf peuvent générer du trafic de fond synthétique pour charger le réseau, tandis que les propres journaux de diagnostic de l'appareil AES67 peuvent signaler des dommages, des latences et des pertes de paquets. De plus, des outils d'analyse Ethernet gratuits (par exemple Wireshark) peuvent capturer des marquages DSCP et confirmer que la priorité se propage correctement. Un test de terrain utile est de diffuser l'audio tout en exécutant simultanément un grand transfert de fichier sur le même commutateur; si l'audio reste propre, la politique QoS fonctionne. Des tests plus avancés peuvent impliquer l'injection de quantités variables de trafic de fond à l'aide d'un émulateur de déficience réseau pour vérifier la tolérance de jitter.

Considérations supplémentaires: Snooping multicast et IGMP

Bien que la multidiffusion ne change pas les marques QoS, elle interagit avec la QoS de manière importante. Les commutateurs avec l'insonorisation IGMP doivent être activés pour prévenir les inondations multidiffusion dans tous les ports, mais la limite de confiance QoS doit encore être appliquée au trafic multidiffusion. De nombreux commutateurs traitent le trafic multidiffusion différemment dans leurs CITI de commutation; vous pouvez avoir besoin d'activer explicitement la QoS pour les groupes multidiffusion. De plus, assurez-vous que le protocole de routage multidiffusion (p. ex. PIM) ne modifie pas les valeurs DSCP lors de la transmission entre VLANs ou sous-réseaux.

Certains routeurs bandent ou remarquent DSCP par défaut sur le trafic multidiffusion routé, ce qui briserait la priorité de bout en bout.

AES67 QoS comparé à d'autres protocoles de réseau audio

AES67 n'est pas la seule norme audio-sur-IP, d'autres incluent Dante, AVB/TSN, et Ravenna. Comprendre comment la QoS diffère entre eux peut aider les concepteurs de systèmes à choisir la bonne plateforme pour une application donnée.

Dante Dante utilise un système QoS propriétaire avec DSCP 46 pour l'audio et DSCP 56 pour le contrôle, très similaire à AES67. Cependant, Dante utilise également un protocole de découverte propriétaire et un calendrier local de liaison plutôt que PTP. L'implémentation QoS est étroitement intégrée dans le matériel d'Auvinate , ce qui le rend un peu plus facile à déployer mais moins flexible sur des réseaux hétérogènes.

AVB (Connectation vidéo audio) / TSN (Réseau sensible au temps) AES67 peut fonctionner sur les réseaux AVB, mais il n'exige pas de TSN, ce qui le rend plus accessible mais moins déterministe dans les réseaux partagés dépourvus de commutateurs TSN.

Ravenne, développé par ALC NetX, est très proche de AES67 (en effet, AES67 a fortement tiré de Ravenne). Ses recommandations QoS sont presque identiques: DSCP 46 pour audio, DSCP 56 pour contrôle, et PTP avec une priorité élevée. Les réseaux Ravenna bénéficient des mêmes pratiques QoS discutées ici. Certaines implémentations Ravenna ajoutent des optimisations de tampons propriétaires qui peuvent tolérer de plus grandes variations de retard, mais le principe de marquage des paquets reste le même.

Pièges communs et dépannage QoS dans AES67

Même avec une planification minutieuse, les problèmes de QS peuvent survenir. Les plus fréquents sont les suivants :

  • Changer la configuration de confiance : Si le périphérique réseau ne fait pas confiance aux marques DSCP depuis le point d'arrivée, la priorité est perdue. Vérifiez les paramètres de confiance sur chaque port de commutation le long du chemin. Utilisez ou l'équivalent pour confirmer.
  • Politiques de file d'attente erronées : Certains commutateurs utilisent un ordre de priorité fixe, tandis que d'autres utilisent un round robin pondéré (WRR). Le trafic audio doit être placé dans la file d'attente prioritaire (queue 4 ou 5 sur de nombreuses plateformes).
  • Interférences avec des applications voyous : Tout périphérique sur le réseau peut envoyer des paquets avec des valeurs DSCP élevées. Une imprimante ou un serveur mal configurés pourrait faire déborder les files d'attente prioritaires. Utilisez les ACL pour limiter les marquages DSCP hautement prioritaires aux paramètres connus de l'AES67. Envisagez de mettre en œuvre une politique DiffServ qui n'autorise DSCP 46 que les adresses MAC ou les sous-réseaux IP des appareils audio.
  • Calendrier PTP sur les VLAN: Si les paquets PTP doivent traverser les limites du VLAN (via un routeur ou un commutateur de couche 3), le périphérique doit être PTP-aware ou supporter la fonctionnalité de l'horloge limite. Sinon, le commutateur introduit latence et jitter que QoS seul ne peut pas corriger. Utilisez PTP- horloges transparentes ou limites sur tous les sauts de couche 3.
  • Congestion sur la file d'attente prioritaire elle-même: Même avec la police, une explosion peut provoquer des chutes de queue dans la file d'attente prioritaire si le shaper est placé de manière trop agressive.

Ressources externes pour la lecture supplémentaire

Pour une plongée plus profonde dans l'AES67 et ses mécanismes de QoS, les ressources suivantes sont recommandées :

Conclusion

Les mécanismes de qualité du service définis dans l'AES67 ne sont pas seulement des recommandations, mais ils sont essentiels pour la prestation d'un son de qualité professionnelle sur les réseaux IP. En tirant parti des marques DSCP à la couche 3, 802.1Q. Les balises SCP à la couche 2, une planification prudente de la bande passante et un timing PTP approprié, les intégrateurs de systèmes peuvent construire des réseaux à la fois fiables et évolutifs. Bien que la configuration nécessite une discipline et une compréhension solide des fondamentaux du réseautage, le paiement est une infrastructure souple qui prend en charge le compte de canaux élevés et le son à faible latence dans pratiquement tout environnement Ethernet moderne.