Résumé

  • La lecture de apsCommandSwitch rendait la dernière commande écrite; elle ne disait pas nécessairement quelle demande gouvernait encore le groupe de protection SONET.
  • Une demande locale ou distante de priorité égale ou supérieure pouvait la préempter. Les K1/K2 reçus et transmis, l’état du canal, le chemin lumineux et le service devaient donc être vérifiés séparément.

Deux paires d'octets pouvaient avoir davantage d'autorité descriptive qu'une commande lisible. K1/K2 reçus racontaient ce que le pair demandait; K1/K2 transmis, ce que l'élément local répondait. Si cette conversation ne correspondait plus au dernier ordre écrit, la MIB n'était pas incohérente. Elle conservait deux réalités différentes : l'intention passée et l'arbitrage présent.

RFC 3498 définissait une MIB SMIv2 pour la commutation automatique de protection linéaire SONET. Les architectures 1+1 et 1:n étaient couvertes, pas les anneaux. Les gestionnaires pouvaient créer les canaux, former un groupe, activer sa configuration, commander une commutation et observer état, compteurs et notifications.

L'activation imposait une structure. Les canaux d'un groupe devaient être valides et consécutifs, commencer à zéro dans la plupart des modes ou à un dans le 1+1 optimisé, et ne pas dépasser quatorze pour les canaux de travail. L'InterfaceIndex désignait le LTE SONET; la priorité ne comptait que pour 1:n. Une incohérence de numérotation, d'architecture ou de paramètres entraînait inconsistentValue.

Cette validation prouvait qu'un modèle de gestion pouvait entrer à l'état actif. Elle ne prouvait pas qu'un défaut avait été vu, que l'extrémité distante partageait le mode, que le commutateur optique avait bougé ni que les clients recevaient encore leurs trames.

La table des commandes autorisait l'effacement, le verrouillage de la protection, les commutations forcées ou manuelles dans les deux sens et l'exercice du protocole. Une demande de priorité égale ou supérieure déjà en cours pouvait empêcher l'exécution. Le résultat inconsistentValue était alors une information sur l'arbitrage, pas une simple erreur de formulaire.

Le piège venait de la lecture suivante. L'objet renvoyait la dernière valeur écrite, ou noCmd si aucune commande n'avait été écrite depuis l'initialisation. RFC 3498 précisait que cette valeur ne prouvait pas l'effet actuel. Une requête locale ou distante plus forte pouvait avoir pris la main. La seule voie vers l'état courant passait par K1/K2 et les objets d'état.

Dans K1, quatre bits décrivaient la requête et quatre le canal. K2 répétait l'identité du canal, distinguait 1+1 de 1:n et portait mode unidirectionnel, bidirectionnel, RDI-L ou AIS-L. Leur émission et leur réception donnaient deux points de vue sur le dialogue de protection. Une égalité apparente restait toutefois plus faible qu'une preuve de trafic arrivé à destination.

Les états rendaient les désaccords explicites : mode, canal, octet de commutation, ligne de protection distante et trafic supplémentaire. Une défaillance d'octet pouvait être déclarée quand aucune suite de trois K1 cohérents n'apparaissait dans la fenêtre de douze trames pertinente, ou quand un code invalide persistait trois trames. L'état du canal séparait verrouillage, dégradation, panne, commutation et attente de restauration.

Les historiques avaient aussi leurs frontières. Le nombre de commutations, le moment de la dernière et la durée passée sur protection n'étaient pas interchangeables. La durée n'était valable qu'en mode réversif. Désactiver la réversion pouvait la remettre à zéro et devait déplacer l'horodatage de discontinuité. Une réinitialisation de la gestion pouvait également rompre les compteurs. Le zéro avait besoin de son époque et de son mode.

Les notifications n'étaient pas une couverture automatique. Leur masque était vide par défaut, et le groupe d'événements était facultatif. L'absence de notification pouvait signifier absence d'événement, désactivation, fonction non implémentée ou perte de transport. Les compteurs et les bits courants pouvaient changer dans le silence.

La sécurité soulignait la puissance de la surface. Commandes, verrouillages, mode, direction, seuils BER, attente, interfaces et priorités pouvaient perturber APS s'ils étaient modifiés avec malveillance. Le RFC déconseillait les versions antérieures à SNMPv3 et recommandait authentification, confidentialité et contrôle d'accès. Mais même un principal légitime n'abolissait pas la hiérarchie des requêtes APS.

Il faut donc conserver une chaîne complète : identité et droit du gestionnaire, SET accepté, arbitrage de priorité, commande mémorisée, K1/K2 envoyés, réponse distante, canal courant, déplacement optique, continuité des mesures, retour du trafic puis capacité à protéger la panne suivante. La commande ne possède que le début de cette histoire.

La spécification minimale rendait cette histoire observable par des outils différents. Elle n'accordait pas au champ symbolique « dernière commande » le pouvoir de réécrire l'exécution. C'est pourquoi une MIB fidèle pouvait contredire un tableau de bord naïf — et avoir raison.

Sources