Résumé

  • La RFC 2379 recommandait d'envoyer les messages de contrôle RSVP sur le chemin best effort déjà disponible, même lorsque ces messages devaient conduire à la création de circuits virtuels ATM séparés et assortis de paramètres de qualité de service.
  • Son apport durable est une discipline de la preuve : PATH ou RESV, état RSVP, admission, circuit configuré et performance observée sont des reçus successifs, jamais des synonymes.

Demander plus que le chemin ne promettait

Le détail le plus fécond de la RFC 2379 tient dans un trajet apparemment mal assorti à son message. RSVP demandait une réservation de ressources. ATM savait établir des circuits virtuels dotés de caractéristiques de service explicites. Pourtant, le guide ne réservait pas d'abord un canal sûr à la signalisation : il faisait circuler les messages RSVP sur la voie best effort déjà utilisée pour joindre le destinataire ou, en multidiffusion, le groupe.

La raison était une économie de mécanismes. Avant d'ouvrir une session et d'initier une réservation, un chemin ordinaire devait déjà exister. Le réutiliser pour le contrôle évitait de multiplier les circuits ATM uniquement pour préparer d'autres circuits. Le plan de contrôle pouvait donc demander un service plus fort tout en voyageant sur un support plus faible.

Le texte ne transformait pas cette faiblesse en garantie par un jeu de vocabulaire. Il reconnaissait qu'un VC best effort pouvait être moins fiable que ne le souhaitait la signalisation RSVP. La tolérance venait ailleurs : l'état RSVP était un état souple, périodiquement rafraîchi. Une perte ponctuelle ne détruisait pas nécessairement la synchronisation, puisqu'un rafraîchissement ultérieur pouvait maintenir ou reconstruire l'état.

Cette temporalité change la nature de la preuve. Un message manquant ne signifie pas aussitôt que la réservation a disparu; mais un message émis ne prouve pas davantage qu'elle existe. Il faut observer les rafraîchissements, l'expiration, la décision d'admission et la survie du circuit associé.

Un VC par réservation, en attendant mieux

Le partage de plusieurs sessions RSVP sur un même circuit pouvait promettre une meilleure utilisation des ressources ATM. En 1998, l'agrégation restait toutefois un sujet de recherche. La RFC recommandait donc un VC indépendant pour chaque réservation RSVP.

Cette prudence rendait visible la chaîne de transformation. Une session RSVP n'était pas déjà un circuit ATM. Il fallait traduire la demande en paramètres de service, admettre ou refuser la réservation, créer ou choisir un VC, puis classer les paquets vers ce circuit. Et le circuit lui-même n'était pas encore la preuve que les paquets avaient reçu la prestation annoncée.

Les textes compagnons répartissaient volontairement les responsabilités. La RFC 2380 formulait les exigences d'implémentation; la RFC 2381 reliait les services Integrated Services « controlled-load » et « guaranteed » aux capacités ATM; la RFC 2382 donnait le cadre général. Cette séparation documentaire reflétait la séparation opérationnelle des reçus.

Le raccourci n'inventait pas sa destination

Un raccourci ATM pouvait franchir plusieurs sous-réseaux IP logiques. PATH et RESV pouvaient alors suivre des routes asymétriques. La RFC 2379 s'appuyait sur le comportement RSVP existant—l'objet NHOP et le transfert d'un message reçu sur la mauvaise interface—pour absorber cette dissymétrie.

La règle décisive concernait le choix de l'extrémité. Un raccourci QoS ne devait pas découvrir seul sa destination. Si le trafic best effort avait déjà établi un raccourci, le VC QoS déclenché par RSVP devait reprendre la même extrémité. Dans ce modèle, sans raccourci best effort, il n'y avait pas non plus de raccourci QoS traversant les sous-réseaux.

Cela n'interdisait pas les VC QoS de saut en saut. La contrainte portait sur l'autorité qui désignait le point terminal du raccourci. Le routage best effort fournissait la décision antérieure; le circuit réservé en héritait. Un VC ainsi créé attestait une configuration, non la réussite rétroactive de la découverte, de l'admission ou de la livraison.

La multidiffusion refusait l'uniformité

Dans une session multicast, certains récepteurs pouvaient demander des niveaux de QoS différents tandis que d'autres ne demandaient rien. Le cadre compagnon distinguait des modèles totalement hétérogène, partiellement hétérogène, homogène et homogène modifié. La RFC 2379 n'en faisait pas un vainqueur universel. Elle demandait au moins l'hétérogénéité limitée ou l'homogénéité modifiée, de préférence les deux avec un mécanisme de choix.

Cette retenue compte dans l'histoire du réseau. Le document de bonnes pratiques ne faisait pas disparaître la diversité opérationnelle pour obtenir un dessin plus propre. Il fixait un minimum réalisable tout en laissant le désaccord entre récepteurs observable.

Quatre reçus à conserver

Une lecture rigoureuse sépare quatre familles de traces : le chemin best effort qui porte le contrôle; l'état RSVP et ses rafraîchissements; la décision d'admission et le VC ATM configuré; enfin les compteurs et mesures applicatives qui décrivent le service obtenu.

PATH n'est pas RESV. RESV n'est pas l'admission. Le VC n'est pas le classement correct des paquets. Une étiquette QoS n'est ni la latence, ni la perte, ni la livraison. L'architecture reliait ces plans précisément parce qu'elle ne les confondait pas.