Il y a 2 ans j’écrivais sur ce blog cet article qui donnait quelques pistes pour implémenter de la QoS dans des environnement de communications unifiées (avec notamment la question du softphone). Je restais alors sur des éléments assez “traditionnels”: qui marque? Comment gérer le CAC? Comment gérer la QoS indépendamment pour les VLANs voix et data? Le modèle traditionnel permet déjà d’avancer mais on on en voit rapidement les limites… Un champ DSCP ne permet pas de qualifier un flux dans sa totalité: quelle application? quel codec? quelles exigences au niveau du réseau? Comment avoir une vision de ces éléments de bout en bout? C’est suite a une discussion avec un client ce matin que j’ai pensé qu’il serait intéressant de présenter une nouvelle approche. Dans la suite de cet article je vais rapidement décrire une autre solution basée sur des échanges de “Metadata” entre les terminaux et le réseau, partie intégrante de notre architecture Medianet. Si cette approche existait déjà il y a 2 ans, elle a depuis mûri et est supporté sur davantage de plateformes aussi je risque de frustrer moins de monde en abordant ce point aujourd’hui!
J’ai déjà commencé par un gros mot: “Metadata”. Ne prenez pas peur l’idée est très simple: il s’agit de permettre à un terminal d’annoncer au réseau la description des flux qu’il génère. Par exemple le poste de travail va indiquer au réseau que le flux UDP entre les adresses/ports 1.1.1.1:17243 et 2.2.2.2:18542 correspond à un flux Jabber, application Cisco, qu’il s’agit de voix et que les numéros d’appelant et d’appelés sont 17357682 et 19873263.
Quand le commutateur ou le routeur verra passer le flux en question il aura immédiatement connaissance de toutes les caractéristques associées. Ainsi on pourra définir sur le commutateur une règle de QoS directement pour l’application Jabber, sans se soucier du champ DSCP, des IP, du port etc. Ce dernier n’appliquera la QoS en question que pour les flux qui auront reçu avant les bonnes Metadata.
Ce qui est intéressant ici est que les Metadata sont envoyées par la source vers la destination. Ainsi tous les noeuds intermédiaires (switchs/routeurs) peuvent avoir connaissance de ces Metadata s’ils sont bien configurés (une ligne de commande: “metadata flow”) et surtout s’ils sont du bon constructeur! 🙂 Notez bien qu’il n’est pas du tout nécessaire que tout les noeuds supportent ces metadata. Ceux qui ne connaissent pas cette fonctionnalité laisseront simplement passer le message d’annonce des Metadata (transporté sur RSVP pour la petite histoire)
Le principe de base est compris? Alors regardons un peu plus précisément certains aspects de cette solution…
1°) Qui va pouvoir générer des Metadata?
Ici plusieurs options:
- On va pouvoir les générer directement sur le terminal: on parle de MSI: Media Service Interface. On va avoir le support sur nos terminaux vidéo. Sur le poste de travail un petit driver MSI peut être installé pour faire l’interface avec le réseau. Ensuite toute application va pouvoir interfacer avec ce driver pour générer les bonnes metadata (on fournit les API pour le faire). Chez Cisco les applications Webex et Jabber annoncent les Metadata.
- Dans le cas où le terminal n’annoncerait pas les metadata on a la capacité sur certains commutateurs de détecter certains flux voix/video (au moment de la signalisation). Ces commutateurs peuvent ensuite annoncer les metadata. Bien pratique quand le terminal ne gère pas la fonction MSI. On parle ici de MSP: Media Service Proxy.
- Un peu dans le même esprit, un routeur qui implémente NBAR2 (fonction de Deep Packet Inspection – qui permet de reconnaître une application en analysant finement les paquets échangés sur le réseau) pourra lui aussi générer des Metadata pour le flux reconnu.
2°) Que faire des Metadata
- Vous l’avez déjà compris: on peut déjà faire de la QoS. Au lieu d’un match sur une ACL avec une tonne de “permit udp…” il suffira de faire un “match applucation webex-meeting”. Sympa non?
- On peut également exporter ces metadata à une console de supervision ou bien s’en servir pour lancer des analyses approfondies de flux (performance monitor). Ici non seulement on aura la visibilité de la performance du flux mais en plus on saura à quoi il correspond précisément. Plus de fossé entre les équipes “‘Media/téléphonie” et les équipes réseaux!
- Mais ce n’est pas tout. On pourra utiliser également les metadata pour faire du PBR (Policy Based Routing). En gros on peut décider de choisir pour chaque application le chemin désiré.
J’arrête là pour le théorique. J’espère que vous avez compris l’intérêt d’une telle solution. Je pense vous faire prochainement un petit article détaillé sur le sujet, avec tests etc. afin de vous montrer que tout cela est bien concret!
Références:
@JeromeDurand
Authors
