Résumé

  • Le partage d’un VC entre données et signalisation réduisait le nombre de circuits et la latence de mise en place, tout en exposant les rafraîchissements RSVP aux rejets provoqués par un trafic non conforme.
  • Un VC de signalisation séparé apportait un contrat de trafic distinct, pas une preuve de service : admission, transport, renouvellement de l’état et traitement des données restaient des résultats différents.

L’économie était séduisante. RSVP entretenait ses réservations au moyen de messages PATH et RESV périodiques. ATM transportait les paquets sur des circuits virtuels soumis à des contrats de trafic. Pourquoi construire un second circuit si le message de contrôle pouvait emprunter celui des données concernées ?

La réponse apparaissait lorsque le trafic sortait de son contrat. Le mécanisme chargé de rejeter le trafic non conforme n’était pas tenu de préserver le paquet RSVP mêlé au même flux. La perte occasionnelle était prévue par RSVP. Une série de pertes pouvait cependant laisser expirer l’état souple, provoquer la disparition du VC de qualité de service, puis déclencher sa reconstruction. La méthode choisie pour diminuer la signalisation pouvait ainsi en produire davantage.

Un état souple dépend d’une réception à temps

Dans la RFC 2205, l’état RSVP n’était pas une inscription permanente. PATH et RESV le créaient et le rafraîchissaient. Faute de message correspondant avant l’expiration du délai de nettoyage, le routeur ou l’hôte le supprimait. Ce choix permettait aux anciens états de disparaître quand les routes ou les groupes multicast changeaient, même sans transaction de suppression parfaitement fiable.

La répétition rendait le système robuste aux pertes isolées. Elle ne transformait pas un chemin durablement congestionné en chemin fiable. La RFC 2205 recommandait donc un minimum de bande passante pour protéger les messages RSVP contre les pertes de congestion.

Un journal d’émission ne suffisait pas. Il fallait connaître le VC choisi, son contrat, le résultat de l’admission, la traversée du segment ATM, l’heure de réception et la nouvelle échéance de l’état. Un VC pouvait rester présent alors que l’état RSVP avait expiré. L’état pouvait exister alors que l’appel QoS des données avait été refusé. Aucun de ces voyants ne prouvait la livraison applicative.

Quatre familles, quatre répartitions du risque

La RFC 2382 présentait quatre grandes façons de transporter le contrôle. La signalisation pouvait partager le VC de données. Chaque réservation pouvait recevoir un VC RSVP parallèle. Plusieurs sessions ayant la même entrée et le même ensemble de sorties pouvaient mutualiser un VC point-à-multipoint. Enfin, plusieurs VC point-à-point pouvaient être partagés entre sessions.

Le premier modèle réduisait le nombre de VC et supprimait, pour PATH, l’attente liée à l’ouverture d’un circuit supplémentaire. En échange, les messages héritaient du traitement appliqué aux données. La RFC avertissait qu’un trafic non conforme pouvait faire perdre la signalisation et que des pertes excessives conduiraient à des démontages et rétablissements répétés de VC QoS.

Une variante plaçait la signalisation sur le chemin de données best effort. Elle échappait au défaut de conformité du VC QoS, mais non à la congestion du réseau ATM. Le texte recommandait une classe préférentielle pour le contrôle. Donner une priorité aux paquets RSVP dans l’ordonnanceur IP avant leur entrée dans ATM paraissait prometteur, mais restait difficile.

Le VC parallèle isolait plus nettement les responsabilités. Son propre contrat empêchait qu’un message de contrôle conforme soit rejeté à cause du trafic fautif sur l’autre VC. Le coût était explicite : deux fois plus de circuits au minimum, une signalisation ATM supplémentaire et un délai de mise en place.

La mutualisation exigeait une mémoire plus précise

Un VC de contrôle point-à-multipoint ne pouvait être mutualisé proprement que pour un même ingress et un même ensemble d’egress. Or cet ensemble évoluait. Après le départ ou l’arrivée d’un destinataire, l’entrée devait trouver un autre VC, en créer un, modifier l’existant, ou accepter d’envoyer encore des messages vers une sortie devenue inutile.

Le gain ne se trouvait donc pas dans la seule configuration. Il dépendait de la topologie et des motifs de trafic réels. Des VC point-à-point durables dans le cœur pouvaient amortir les ouvertures et utiliser une voie retour. Leur nombre restait lié aux nœuds participants et à leurs échanges. Réutiliser un VC best effort économisait encore une connexion, au prix d’une probabilité supérieure de perdre le contrôle.

La preuve devait suivre cette complexité. À l’identifiant du message et du VC s’ajoutaient, pour un circuit mutualisé, la correspondance session-VC et l’ensemble des sorties valables à cet instant. Sans ces clés, une capture ne permettait pas de savoir quelles réservations dépendaient du chemin défaillant.

Surdimensionner le contrôle pouvait faire échouer son admission

Attribuer une forte QoS à la signalisation ne résolvait pas tout. Les messages RSVP étaient peu fréquents, typiquement toutes les trente secondes ; une petite allocation devait suffire. Une demande excessive risquait de faire rejeter le VC de contrôle lorsque les ressources se raréfiaient.

Le repli best effort révélait le même cercle. Si l’appel QoS échouait parce que le réseau ATM était congestionné, le paquet de contrôle de repli devait traverser ce réseau congestionné avec moins de protection. La présence d’un repli ne prouvait pas son passage.

La RFC 1755 avait déjà cherché à éviter le connection thrashing, ces créations et suppressions inutiles de connexions. La RFC 2382 montrait une autre origine possible : la perte du transport de contrôle faisait expirer l’état, l’expiration démontait le service, puis la reconstruction ajoutait du travail au système.

La chaîne de reçus devait rester modeste et exacte : émission d’un message donné, choix d’un VC et d’un traitement, admission du VC, transport du message, rafraîchissement avant échéance, maintien du VC de données, puis observation du service. Chaque étape pouvait réussir tandis que la suivante échouait.

La RFC 2382 n’imposait pas une topologie universelle. Elle rendait comparables des choix qui ne produisaient ni les mêmes coûts ni les mêmes preuves. Son invariant minimal était que le chemin entretenant l’état souple soit suffisamment protégé, observable et honnêtement relié à cet état.