Bonjour à tous,
 
Voilà je m'interroge sur la QoS sur la VoiP, j'ai lu dans un article qu'il fallait mettre en oeuvre le protocole 802.1p ou DSCP et un Contrôle d’admission des appels (avec mise en place du protocole RSVP).
 
Première question, est-ce que DSCP c'est là même chose que le modèle DiffServ
 
De plus, le protocole RSVP fait partie du modèle IntServ mais on ne peut pas mettre en place un modèle DiffServ et un modèle IntServ en même temps, fin je ne comprends pas trop pourquoi l'auteur préconise de mettre en place ces 2 protocoles.
 
D'avance merci.

Bonjour,
 
802.1p : priorisation au niveau Ethernet.
 
IntServ : construit un chemin avec RSVP sur IP. Difficile à mettre en place sur de grands réseaux.
 
DiffServ : utilise le champ DSCP (DiffServ Code Point, ex-Type Of Service) d'IP pour prioriser selon des classes de service. Per Hop Behavior : passe mieux à l'échelle.
 
L'implémentation la plus courante est DiffServ pour classer la VoIP en Expedited Forwarding. Je ne vois pas non plus pourquoi mettre en place DiffServ et IntServ.

Intserv on le voit jamais. Les opérateurs (OBS en tete) refusent catégoriquement de mettre RSVP en service sur leurs routeurs donc a moins d'un réseau privé géré de bout en bout (ultra rare)...

 
si tes flux sont commutés en niveau 2 et taggués pourquoi pas utiliser CoS/802.1p comme ça tu restes sur de la QoS de niveau 2
 
si tes flux sont routés en niveau 3 il vaut mieux s'orienter vers du DSCP comme ça tu restes sur de la QoS de niveau 3  
 
par contre attention CoS/802.1p n'est valide que si les flux sont taggués !!! y'a pas de p sans q

C'est qu'un p sans q c'est difficile

Ok ok ça part en cacahouête là, non j'avou sympa la p'tite boutade. Bon pour revenir à nos moutons ça sert à rien intserv alors ? Car en faite je fais un mémoire de recherche sur la voip on Wlan, donc grosse partie sur la QoS.
 
En gros que préconiseriez-vous à mettre en place pour avoir une QoS de qualitaÿ pour de la VoWlan, j'aurais p'tète du commencé par là en faite car vous m'avez l'air tous bien callé.

IntServ est une autre approche qui ne passe pas à l'échelle. C'est pour ça que DiffServ a pris le dessus.
 
Pour le WLAN... Ca ne sera effectivement pas de l'IP ! Regarde peut-être du côté des mécanismes de CSMA/CA, de l'algorithme de backoff et de RTS/CTS.

On se passe de l'IntServ pour la VoIP en limitant strictement la bande passante allouée aux flux taggés en Expedited Forwarding dans le modèle DiffServ.

En fait, l'auteur voulait peut-être préconiser de mettre en place DiffServ et RSVP. RSVP n'est pas forcément lié à IntServ. Le cas auquel je pense est MPLS TE avec DiffServ pour gérer les classes de service et RSVP pour gérer les chemins. Mais là, on s'éloigne de ton cas puisqu'il s'agit de la couche 2 en réseau local. Le meilleur moyen de gérer les flux VoIP sur un réseau LAN est de les mettre sur un sous-réseau à part, pour justement mieux classer les flux au niveau IP. Mais bon, je ne connais pas bien 802.1p.

Ben 802.1p n'est pas très différent de DSCP sauf que ce flag fait parti de l'en-tête 802.1q par contre c'est que sur 3 bits donc il n'y a que 8 niveaux contrairement au DSCP qui en a 8 fois plus
 
Aujourd'hui la quasi totalité des commutateurs l'Ethernet de niveau 2 sait gérer le DSCP ce qui explique l'engouement de moins en moins important pour la QoS basée sur CoS/802.1p... d'autre part DSCP permet de s'affranchir de la contrainte lié au média et au VLAN taggué ou non
 
Grosso modo il n'y a plus besoin de gérer le flag suivant tel ou tel support physique, juste à bien configurer le mapping des flags L3 vers L2 et la gestion des queues sur les équipements en fonction des mécanismes disponibles

OK. Je vois l'idée. Donc, tu veux dire que les switches gèrent un classifieur, des files d'attente, une précédence et un ordonnanceur ? C'est donc au niveau du routeur inter-VLAN que se fait la classification ?  
 
Mais si on reste au niveau d'un même VLAN au niveau d'un même switch, quelqu'un qui utilise la VoIP et transfert des fichiers en même temps aura un souci ?
 
Si c'est bien ça, on revient au fait qu'il faut séparer les flux VoIP et les flux data dans 2 sous-réseaux alors ?
 
En ce qui concerne le problème de soad029, s'il utilise son PC et un softphone, il ne s'en sortirait donc pas. Le seul moyen serait d'utiliser le VLAN natif pour tagger la VoIP ?
 
Merci pour l'explication sur 802.1p.

Ben en fait tu peux très bien faire la classification et le marquage bien avant le routage inter-vlan.
 
 
Dans un modèle CoS/DSCP le mieux étant de le faire le plus proche de la source et de faire du trust CoS ou DSCP (on peut pas truster les 2 champs dans la plupart du temps quand on fait un trust DSCP l'équipement va réécrire la valeur CoS correspondant à la table de mapping DSCP-to-CoS et vice versa pour le CoS vers DSCP) sur le réseau d'agrégation et le reste de l'infrastructure
 
 
En fait il y a 5 parties à prendre en compte dans la QoS :
- La classification qui permet de sélectionner le trafic à marquer. On peut la faire sur une interface physique, un VLAN, une ACL (avec des possibilités plus ou moins étendues en fonction de l'équipement ça peut aller des @IP source et/ou destination en passant par les ports TCP/UDP ou carrément un pattern bien spécifique de la trame ethernet sur certains équipements ) et surement d'autres mécanismes
- Le marquage du trafic en niveau 2 dans la trame avec une des 8 valeurs de CoS ou en niveau 3 dans le paquet avec une des 64 valeurs de DSCP (à noter que beaucoup d'équipement marque le trafic avec la valeur de CoS ou de DSCP spécifiée dans la conf mais aussi l'autre flag en prenant la bonne table de mapping )
- Le scheduling qui consiste à assigner tel ou tel flux dans tel ou tel queue. En général les équipements Ethernet (switch L2 ou L3, routeur...) ont 4 ou 8 queues.
- La "prioritisation" qui permet de déterminer le niveau de priorité de chaque queue (mécanisme Weighted Round Robin avec des poids pour chaque queue qui représentent "un pourcentage de bande passante" réservé pour telle queue, Strict Priority Queueing qui vide d'abord la queue la plus prioritaire avec de passer à la suivante et ainsi de suite... (perso je suis fan du SPQ )) et la gestion de la congestion qui permet de dropper le trafic de chaque queue en fonction d'un seuil déterminer s'il y a une saturation sur un lien  
- Le policing qui consiste à limiter la bande passante d'un flux de trafic et de soit dropper le trafic en cas de dépassement ou de le remarquer avec une priorité plus basse (ie par exemple tel service/client à le droit à 12Mbits/s après on drop ou si on est gentil on lui laisse 2Mbits/s en plus en Lower-than-best-effort )
 
 
Par exemple :
- pour un poste VoIP avec un PC connecté dessus le plus efficace c'est de le faire directement sur le poste VoIP (en général il le permet) lui-même avec une valeur de CoS et/ou DSCP pour le trafic voix et une autre pour le trafic data du poste informatique (si ce dernier et relier sur le terminal VoIP) et de faire ensuite un trust en ingress sur l'interface du commutateur
- pour un host (poste de travail, serveur, poste VoIP sans PC (ou avec aussi )) relier sur un commutateur c'est de le faire directement en ingress sur l'interface physique où est connecté l'host... après y'a plusieurs façons de le faire soit tout le trafic est taggué avec la même valeur soit on peut jouer avec des ACL pour tagguer le trafic en fonction de sa nature
 
 
Effectivement dans la 2ème option si on a un poste VoIP et un PC comme ça :  
                                        -----------------
PC---poste VoIP---switch---| Réseau Ethernet |  
                                        -----------------
les puristes plussoieront parce qu'ils vont dire qu'il n'y a pas de QoS entre le poste VoIP et le switch... enfin bon avec un lien à 100Mbits/s ça ne pose pas de problème en théorie

Merci twins_ ! J'aurais appris quelque-chose sur 802.1p.
 
Effectivement, ça ressemble beaucoup à DiffServ. Pour résumer, il faut que ça parle q (voire switch niveau 3) jusqu'au bout du réseau avant de parler p (celle-là, je la ressortirai et j'aurai vraiment l'air d'un geek). Vive la Qos de bout en bout !

hein ?
 
Le 802.1p c'est de la QoS ethernet.
 
Comme les réseaux ip sont routés, quand tu arrives au "bout" de ton réseau ethernet (au point de routage quoi) tu fais de la QoS sur IP tout en maintenant de la QoS de niveau 2 cohérente avec la QoS qui traite tes paquets.

Hein ? Je n'ai pas compris ta remarque.. Quand je parlais de bout, je parlais de l'hôte, par opposition au backbone.
 
Entre un hôte et son routeur, les switches traitent la QoS avec 802.1p, non ? Et à partir du moment où tu traverses un routeur, tu traduits 802.1p en DSCP + IP prececdence ?

en fait le "hein ?" c'était pour ça

voilà t'as tout compris En concept c'est assez simple, en implémentation, l'ingénierie de trafic peut être très complexe

Ah OK ! Corrige-moi si ma déduction est fausse, il faut que le switch remonte jusqu'au niveau 3 si on prend le premier point de twins_ : ACL avec adresse IP et ports.

Un switch ne fixe pas sa CoS grace à des acl (seul un équipement de niveau 3 peut le faire). Il fixera la CoS soit en fonction de champ prédeterminé, soit par interface.

ça dépend des switchs L2 y'en a qui le font très bien

Perso et après pas mal de recherches j'ai du mal a trouver des docs claires qui expliquent clairement la difference de traitements des paquets entre un fq et un wfq ou un wfq et wrr.
C'est bien gentil de dire qu'on colle une pondération a chaque file en fonctione de la valeur de la priorité, mais bon ca explique pas dans le détail ce qui se passe
Sinon du L3 en extrémité mis a part se faire plaisir sur des temps de convergence < au rstp en implementant de l'eigrp/ospf  tuné partout ca sert a qlq chose d'autre?
 

C'est ce genre de schéma que tu cherches ?  

Bon là c'est du frame relay...
 
En fouillant sur le site de cisco, tu devrais en trouver (notemment par là : http://www.cisco.com/en/US/tech/tk [...] _home.html )

Si tu veux une bonne intro à la QoS, y a ce bouquin : http://www.amazon.com/CCNP-Officia [...] 1587201763
 
que je trouve très bien écrit sans être trop surchargé d'infos

Bonjour à vous tous et merci fortement pour vos participations.
 
Voici pour l'instant la partie que j'ai mis pour la QoS de la VoWlan dans mon mémoire  :
 

 
Pensez-vous que cela est suffisant ou est-ce superficiel comme recommandation. J'ai essayé de suivre votre conversation mais j'ai du mal quand même  à bien appréhender vos conseil, notamment celui de _twins qui m'a l'air vraiment pertinent :
 

Ca me parait plutôt pas mal. Je pense que pour être plus précis tu peux ajouter quelques lignes sur le fait que 802.1p utilise un champ de 802.1q.
 
Attention, RSVP n'alloue pas, il permet de demander aux équipements un chemin répondant à des critères et de vérifier que c'est toujours le cas une fois le chemin est en place. Je ne crois pas que c'est utilisé avec 802.1p.
 
En ce qui concerne les 5 points de twins_, il s'agit en fait de l'implémentation des mécanismes de priorisation des flux. Ce sont les mêmes que pour DiffServ et pour le schéma de djoul. Il y a d'ailleurs plus de détails sur son lien.

Salut shinmaki et merci pour ta réponse, elle m'a beaucoup rassuré, j'ai apporté les modifications que tu as indiqué. De plus, j'ai rajouté un nouveau point sur la norme 802.11e, penses-tu que c'est bon de rajouter ça comme ça brute de fonderie où faut t'il mettre un lien entre la précente partie et celle-ci ?
 
Merci encore
 

On pourra rappeler qu'a la base le wifi n'est pas fait pour de la qualité de service. Aucune reservation de timeslot pour un flux contrairement au GSM ou au wimax.
C'est pour ca que je suis vraiment pas fana de la voix sur wifi, d'ailleurs ya qu'a voir comme ca lutte pour décoller.
Le dect est pas encore mort

la VOIP en wifi fonctionne très bien. C'est juste qu'il faut plus de bornes que pour la data pour des raisons de couverture.

Je sais que ca marche tres bien mais je suis pas du tout convaincu. D'ailleurs y'a qu'a voir ca a pas vraiment décollé. Les clients voient difficilement l'interet pour l'instant c'est tout.
Et le dect a encore un bel avenir y'a qu'a voir comment ca a decollé aux US depuis que la FDA a ouvert les frequences.

La problématique de fond est la même que pour la convergence vers IP : intégrer des services exigeant des garanties (ex: délai, jigue, bande passante et perte pour la téléphonie) sur une unique infrastructure IP, qui n'est pas prévue pour à la base.

Ouai sauf que le vrai pb c'est la couverture.
Une borne DECT pousse bien plus loin qu'une borne WIFI et il est bcp plus robuste en environnement difficile (ex combles de hangars avec poutrelles a gogo).
Conclusion la mutualisation avec une appli data n'est bien souvent pas suffisante. Le client a prévu de couvrir des salles de reunions, qlq locaux administratifs, eventuellemetn de l'entrepo logistique.
Mais pour l'exterieur, les couloirs et cie bon courage (a moins de dire que le roaming c'est fini). Et quand il voit qu'il faut multiplier par 2 ou 3 le nombres de bornes et qu'en plus on le fait chier avec une distance de 100m vers le repart (alors qu'une borne dect ca peut dépasser sans pb le kilomètre) bah il voit plus du tout l'interet.
Ok c'est ptet valable a Paris dans les immeubles de bureaux, mais en milieu non tertiaire je vous souhaite bon courage pour vendre de la VoWIFI

Ca faisait aussi partie de ce que je voulais dire par infra IP. Le Wifi a été pensé pour étendre le réseau informatique filaire à la base. Pas pour y connecter des téléphones ou le roaming.