" Les politiques de qualité de service mises en place par les entreprises sont rares, souvent parcellaires, et limitées aux flux informatiques qui ne peuvent pas s'en passer tels que la voix sur IP ou la visioconférence " , constate Emmanuel Cabon, responsable de la veille technologique d'Arche Groupe Siemens.

Ces politiques sont souvent amorcées lorsque des applications non stratégiques telles que les accès au Web accaparent la bande passante au détriment des flux métiers. " La plupart des entreprises se contentent alors de réserver un débit minimal à l'ERP, tout en augmentant massivement la bande passante. Mais le protocole TCP-IP a tendance à remplir entièrement les tuyaux. Les entreprises comprennent alors qu'elles ne peuvent faire l'impasse sur une hiérarchisation de l'ensemble des flux " , ajoute Emmanuel Cabon. Dans ce domaine, le secteur bancaire aurait déjà une longueur d'avance : " Migrant de Frame Relay ou de X.25 vers des VPN-IP, les banques ont couramment besoin de différencier jusqu'à sept classes de services. Les données circulant entre le siège et les agences étant aussi prioritaires que des flux de type voix sur IP " , déclare Thierry Leclère, responsable du conseil chez CSSI.

Si peu d'entreprises ont cette vision globale, un vaste mouvement s'amorce. Ce fragile consensus reste scindé entre les partisans d'une augmentation de la bande passante et les promoteurs d'une prioritisation des flux. Sur le réseau local, la première approche suffit habituellement, grâce à l'Ethernet commuté à 100 Mbit/s, complété d'un backbone Gigabit. " Cela revient moins cher d'augmenter la bande passante que de la gérer " , souligne François Bellini, p.-d.g. de Teldata. En témoigne Eiffage, le consortium de travaux publics : afin de fluidifier les accès à ses serveurs stratégiques, son équipe réseau a recâblé leur desserte en catégorie 5E de telle sorte que chaque serveur soit raccordé à 100 Mbit/s au commutateur d'étage.

Les mécanismes de qualité de service 802.1p avaient été testés. Le constat ? " Protéger l'application de paye (du trafic Citrix) ralentissait trop les transferts de fichiers de CAO. Mais nous n'avons pas cherché à optimiser les réglages, le recâblage ayant réglé les problèmes " , expose Hervé Couaillet, d'Eiffage.

Des contraintes inédites apparaissent toutefois avec l'arrivée de la téléphonie sur le LAN. " Certains de nos clients ont dû marquer les flux voix d'une priorité supérieure, afin d'obtenir un fonctionnement satisfaisant " , note Stéphane Chapurlat, directeur de projet chez Siticom. Cette prioritisation de la téléphonie est parfois invisible, l'infrastructure LAN de certains constructeurs marquant automatiquement les paquets grâce aux mécanismes 802.1p ou DiffServ : " Un téléphone IP de Cisco négocie de lui-même un circuit protégé " , explique Pierre Chambon, consultant chez Siticom.

Même situation chez 3Com, dont le PABX LAN (le NBX) n'a pas vu ses paramètres de qualité de service modifiés par la société Gestrim, lors de son déploiement sur cent quarante agences. Seule précaution : " Sur les sites de plus de dix postes, nous avons dû remplacer les hubs par des commutateurs , se souvient Gabriel Bensimon, responsable informatique de Gestrim. Sur certains sites, cinquante personnes réalisent simultanément des accès Internet, du trafic Citrix, et téléphonent sur le LAN, sans difficulté. S'il y avait plusieurs commutateurs, nous devions les interconnecter en Gigabit, tandis que les serveurs étaient raccordés en 100 Mbit/s. "

Pendant un temps, des entreprises ont aussi défini des réseaux virtuels sur le LAN, dédiés à la téléphonie. Cela arrive encore, mais davantage par souci de sécurité.

Quand on passe au réseau étendu, le débat reste ouvert. " Certains estiment qu'il est inutile de prioritiser les flux en l'absence de congestion. Or, gérer la qualité de service, c'est prévenir avant de guérir, donc il faut toujours agir en amont " , affirme Emmanuel Cabon. Dès lors, comment mettre en oeuvre une politique globale ? Cela passe par le marquage des paquets et la réservation de ressources sur les équipements, le choix du périmètre, ainsi que le paramétrage des matériels. Ces actions dépendent de la maîtrise de l'entreprise sur son réseau.

Parmi les mécanismes de prioritisation, DiffServ fait l'objet d'un certain consensus. " C'est le seul à être employé par les entreprises, tandis que les mécanismes de type IntServ, comme RSVP, qui imposent une négociation avant l'établissement de la connexion, sont délaissés " , constate Richard Hernu, ingénieur chez Alcatel Réseaux d'Entreprise. " DiffServ apporte des garanties de qualité de service. On parvient ainsi à minimiser efficacement la gigue en téléphonie sur IP , confirme Emmanuel Cabon, mais si la bande passante est insuffisante, DiffServ restera impuissant. "

Chez Telindus, Robert Vanderberghe, responsable des services réseaux, est plus réservé : " Avec DiffServ, on bride les applications les plus gourmandes sans jamais approcher un véritable déterminisme. Après avoir qualifié les paquets, il faut les gérer. Pour cela, on associe les flux critiques à des files d'attente vidées plus rapidement. Les paquets des autres flux sont jetés lorsque leur file est pleine, ce qui oblige ces applications à refaire des transmissions. " Pierre Chambon atteste : " Si on affecte un pourcentage de la bande passante aux flux critiques, tout dépend du traitement réservé aux paquets excédentaires. Certains opérateurs les jettent, d'autres les acheminent avec une priorité moindre. Dans le premier cas, si l'on a mal évalué les besoins et qu'une application critique supplémentaire se présente, elle sera bloquée. Toute la difficulté est d'identifier des dizaines d'applications selon les adresses IP, source ou destination, et les numéros de ports TCP et UDP, afin de les ranger selon trois classes de services, grâce à une quinzaine de règles à télécharger dans les routeurs d'extrémité. "

Robert Vanderberghe conclut que, lorsque DiffServ montre ses limites, il ne reste qu'à augmenter la bande passante, ou à recourir à une passerelle d'optimisation des flux IP du type PacketShaper.

Chez Eiffage, on teste un boîtier Sitara. " Un boîtier sur le site central suffit à réguler les accès de tous nos sites distants ", se félicite Hervé Couaillet. Ces produits sont aussi appréciés pour leur analyse des performances, une fonction pour laquelle un opérateur comme Equant vient de choisir Packeteer.

DiffServ pose aussi un problème de déploiement massif. Les équipements relativement anciens n'acceptent pas les mécanismes de prioritisation. Or, " la qualité de service ne peut être assurée que si toute la chaîne la supporte " , alerte Robert Vanderberghe.

Des logiciels devaient faciliter la définition puis le déploiement des règles de qualité de service, mais ils n'ont pas connu le succès escompté.

" Ces logiciels supportent mal les réseaux multiconstructeurs, pourtant majoritaires " , constate Richard Hernu. De plus, " un serveur de règles n'est rentable qu'au-delà de cinq mille adresses réseaux " , assure Bertrand Ducurtil, directeur de Neurones.

En pratique, les entreprises optent donc pour une configuration équipement par équipement, certes plus fastidieuse, mais immédiatement réalisable. Les serveurs de règles se sont trouvés aussi confrontés aux VPN-IP. " Ces serveurs n'ont de sens que sur un réseau régi par l'entreprise. Or, celle-ci a tendance à le confier à des opérateurs qui maîtrisent leurs équipements " , constate Thierry Leclère.

Un phénomène inverse, au niveau métropolitain, pondère cette tendance. " Sur des distances inférieures à 100 km, les grands comptes se tournent vers la fibre noire. La configuration des routeurs peut alors justifier un serveur de règles ", évoque Richard Hernu. Par ailleurs, " il est difficile de comparer les offres des opérateurs, car chacun relaye DiffServ à sa façon, sur son backbone MPLS , prévient Thierry Leclère. Certains classifient les flux dès le premier octet transmis, tandis que d'autres ne le font que sur saturation. Les résultats peuvent être très différents. Il faut être vigilant à la signature du contrat. " En outre, " les opérateurs semblent ne gérer que deux types de flux sur leur backbone, correspondant aux qualités CBR et VBR de l'ATM " , révèle Renaud Jahan, consultant chez Siticom. Mais il ne faut pas trop se faire d'illusions. " Les opérateurs sont censés faire de la qualité de service, mais le client n'a aucun accès au paramétrage. Il doit se contenter du contrat de service et avoir confiance en son prestataire " , estime Bertrand Ducurtil.

Mais les entreprises ont tout intérêt à mesurer la qualité de service, éventuellement via un prestataire indépendant. Des tableaux de bord synthétiseront l'évolution des délais de transit, des débits et de la gigue, le nombre de paquets perdus par file d'attente, ainsi que leur taux de remplissage. Pour obtenir ces données, l'entreprise peut interroger les équipements de son opérateur, sous SNMP. " Seuls les grands comptes en obtiennent l'autorisation " , avertit Emmanuel Cabon.

" La solution de remplacement consiste à placer des agents fournis par Auditec ou InfoVista, qui testent l'accessibilité à un service technique ou applicatif. On mesure ainsi le taux de disponibilité, et certaines entreprises commencent à le faire pour la qualité de service proprement dite. " On constate alors un cercle vertueux. " Les engagements des opérateurs sont d'autant plus crédibles qu'ils savent que leurs clients disposent de moyens de vérification " , affirme Thierry Leclère. Une prise de contrôle plus proactive pourrait émerger : " Dans l'idéal, le client définirait sa politique de qualité de service, puis la transmettrait à l'opérateur, qui la déploierait sur ses équipements ", ajoute-t-il. En attendant, l'opérateur marque les paquets, selon une hiérarchisation des flux spécifiée lors du contrat. Il arrive que l'entreprise procède elle-même à ce marquage, ce qui pose un problème de compatibilité avec les valeurs de champs DSCP (DiffServ code point) que l'opérateur a réservé pour ses besoins. Un transcodage est alors nécessaire. Ce marquage en amont représente cependant une évolution logique, pour une qualité de service de bout en bout et modifiable à la volée. C'est pourquoi, " même si les flux ne sont pas prioritisés sur le réseau local, il faut marquer les paquets, au niveau des commutateurs, afin de véhiculer l'information, hors du réseau étendu ", préconise Thierry Leclère.