Résumé

  • ATM UNI ne savait pas modifier la QoS d'un VC actif : l'ancien circuit devait continuer pendant la construction du remplaçant, et seule la fin de cette construction autorisait bascule puis fermeture.
  • Si le remplacement échouait, une hausse recevait une erreur; une baisse pouvait être déclarée réussie tout en conservant l'allocation supérieure.

Une réussite sans circuit correspondant

RSVP autorisait les changements de réservation à tout moment. ATM UNI 3.x et 4.0 ne permettait pas de retoucher les paramètres QoS après l'établissement d'un VC. La RFC 2380 imposa donc un remplacement : garder l'ancien VC intact, créer le nouveau, déplacer le trafic une fois le nouveau complet, puis seulement fermer l'ancien. En cas d'échec, le circuit initial demeurait en service.

Pour une augmentation, cet échec devait produire une erreur, car l'ancien VC ne fournissait pas la capacité supplémentaire. Pour une diminution, il fallait traiter la modification comme réussie : le grand VC satisfaisait déjà la demande plus petite. Cette situation était sous-optimale, mais elle préservait la prestation et les règles d'erreur RSVP.

La réponse ne prouvait donc pas que les ressources physiques avaient diminué. Elle confirmait que l'obligation plus faible restait couverte. Demande courante et capacité réellement détenue exigeaient deux reçus.

Le silence n'avait aucun droit de fermeture

Les VC IP-sur-ATM ordinaires pouvaient expirer faute d'activité, puisque l'IP sans connexion ne signalait pas sa fin. RSVP disposait de ses propres messages et échéances. Un VC de données gouverné par RSVP ne devait donc jamais être supprimé par un simple compteur d'inactivité : valeur infinie côté initiateur, aucune purge côté receveur.

Le silence du trafic était une observation, non une instruction de libérer la réservation.

Le récepteur demandait, l'émetteur construisait

La réservation RSVP partait du récepteur, tandis que le contrôle ATM appartenait à l'émetteur. L'émetteur du sous-réseau devait initier tous les VC QoS; le récepteur devait pouvoir les accepter. RESV attestait une demande reçue, pas la création du circuit.

Signalisation et données ne pouvaient pas non plus partager le VC QoS associé. Une panne de données irrécupérable devenait un échec d'allocation. Une panne irrécupérable du VC de contrôle imposait de fermer les VC QoS associés afin que le transfert ne survive pas silencieusement à l'état de réservation.

En multicast, un bref doublon valait mieux qu'un trou

Sur un VC point-à-multipoint, utiliser ancien et nouveau chemins pouvait dupliquer; utiliser trop tôt le nouveau pouvait priver des récepteurs. Un nouveau VC QoS ne devait transporter aucune donnée avant l'ajout de toutes les parties. Pour déplacer un seul récepteur du best effort vers un VC QoS existant, il fallait en revanche l'ajouter d'abord, puis le retirer de l'ancien chemin. Le doublon transitoire empêchait la perte.

La transition possédait ainsi plusieurs vérités simultanées : demande réduite, réponse positive, grand circuit encore actif, coût inchangé, livraison continue. Les confondre aurait détruit la possibilité de rendre des comptes.