Résumé

  • Une Barrier Reply OpenFlow atteste qu’avant elle, les messages d’une même connexion ont été entièrement traités, réponses et erreurs comprises, avant le début des messages suivants.
  • Elle n’atteste ni la victoire de la règle souhaitée dans le pipeline, ni la sortie physique du paquet, ni sa réception finale ; la spécification le montre explicitement pour Packet-Out.
  • Nick McKeown compte ici comme cofondateur intellectuel d’une interface programmable collective : sa bonne exploitation consiste à assembler des preuves bornées, pas à transformer un accusé d’ordre en verdict de livraison.

Le succès administratif d’un paquet perdu

Prenons un commutateur qui répond correctement à une barrière. La modification précédente peut être présente et néanmoins inutile au paquet observé. Une entrée plus prioritaire peut la masquer. Un masque peut être trop large ou trop étroit. Une autre table peut remplacer l’action. Un groupe peut choisir un compartiment inattendu, un meter peut rejeter, un port peut être bloqué. Plus loin, le lien ou la destination peuvent être indisponibles.

Rien de tout cela ne rend fausse la réponse de barrière. Cela rend fausse l’interprétation « déploiement réussi ».

La version 1.3.5 d’OpenFlow autorise un commutateur à réordonner certains messages pour gagner en performance lorsqu’aucune barrière ne sépare les dépendances. Sur une connexion donnée, tout ce qui précède la Barrier Request doit être entièrement traité, avec les réponses ou erreurs produites ; la barrière est ensuite traitée et acquittée ; les messages postérieurs peuvent alors commencer. Le texte cite des cas précis : créer un groupe avant la règle qui le référence, modifier un port avant un Packet-Out qui l’emploie, ou installer une règle avant d’envoyer un paquet dans la table.

Le contrat porte donc sur une séquence de contrôle. Il ne constitue ni une transaction distribuée ni un reçu de données.

Une architecture écrite à plusieurs mains

L’article OpenFlow de 2008 réunit Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker et Jonathan Turner. Son intuition pratique consistait à ouvrir une interface limitée vers les tables de flux des commutateurs : le contrôleur décide, installe ou supprime des entrées ; les paquets suivants restent traités à grande vitesse par le matériel. L’exemple Amy-OSPF illustre un contrôleur choisissant un chemin et programmant les appareils.

McKeown est un co-initiateur d’OpenFlow et du logiciel réseau programmable, non son inventeur solitaire. La sémantique ultérieure de Barrier provient de l’évolution collective de la spécification et des déploiements. Son rôle dans cette analyse tient à la séparation rendue visible entre décision du logiciel et exécution du datapath. Quand une frontière est claire, on peut enfin nommer ce que son accusé prouve — et ce qu’il laisse hors champ.

Le bilan des déploiements publié en 2014 explique que les retours d’expérimentation ont conduit à la commande Barrier dès OpenFlow 0.9. Le même bilan décrit des délais variables d’installation, des processeurs de commutateurs limités, des difficultés de contrôle in-band et des diagnostics croisant traces de contrôle, RTT, charge CPU, débit d’installation et mesures applicatives. La barrière répondait à un besoin d’ordre ; elle n’a jamais remplacé cette observation à plusieurs étages.

« Entièrement traité » n’est pas « transmis »

La spécification 1.3.5 fournit elle-même le meilleur antidote à la surinterprétation. Le traitement complet d’un Packet-Out ne garantit pas que le paquet sorte du commutateur. Une congestion, une politique QoS, un port bloqué ou invalide peuvent provoquer une perte silencieuse après le traitement OpenFlow. Même un paquet destiné au contrôleur peut disparaître sous l’effet d’un policing sans Packet-In correspondant.

Une entrée de flux comprend des champs de correspondance, une priorité, des compteurs, des instructions, des délais et un cookie. Le paquet commence en table 0, peut traverser d’autres tables, accumuler des actions, passer par un groupe ou un meter. La lecture après barrière d’un cookie attendu prouve davantage que le seul acquittement. Elle ne dit pas encore que l’en-tête réel a choisi cette entrée. Une hausse de compteur établit ce choix local, mais s’arrête au point de mesure.

Le périmètre de la connexion est tout aussi strict. OpenFlow n’impose aucune synchronisation entre connexions. Une barrière reçue sur le canal principal ne couvre pas un ordre dépendant parti sur un canal auxiliaire. Après une reconnexion, il faut vérifier le rôle du contrôleur, la génération du canal et l’état réellement conservé par le commutateur.

Deux tests parce qu’il existe deux questions

La spécification de conformité ONF 1.3.4 Basic Single Table teste la barrière avec une seule connexion de contrôle. Elle ajoute jusqu’à 10 000 flux, les supprime, envoie une Barrier Request et attend la réponse après tous les avis Flow-Removed demandés. À proximité, le test Packet-Out ouvre une liaison de données et vérifie séparément la réception du paquet.

Cette séparation est une leçon de méthode. Le premier test valide l’ordre d’exécution ; le second observe un effet sur le plan de données. Une interface d’exploitation peut juxtaposer leurs voyants, mais ne doit pas leur attribuer la même signification.

Les bundles d’OpenFlow 1.5.1 renforcent encore un autre reçu. Plusieurs modifications peuvent être préparées puis appliquées ensemble ; en cas d’échec à la validation du commit, l’ensemble ne doit pas être appliqué. Le support reste optionnel et dépend des capacités du matériel. L’atomicité de configuration ne prouve toutefois ni la correspondance du paquet de production, ni la continuité du chemin, ni la réponse de l’application.

VeriFlow ajoute une vérification des invariants réseau entre le contrôleur et les équipements. Il part du constat qu’un code de contrôle complexe ne mérite pas une confiance absolue. Une boucle ou une rupture logique peut ainsi être détectée dans un modèle avant propagation. Mais le modèle n’est pas une observation du câble ou du serveur : il constitue un reçu distinct, très utile, mais non final.

Huit reçus, aucune promotion automatique

Une conduite de changement défendable conserve la chaîne suivante :

  1. Intention — version de politique et règles désirées.
  2. Transport — Datapath ID, rôle et connexion effectivement utilisés.
  3. Ordre — Barrier Reply sur cette connexion, erreurs précédentes rapprochées.
  4. État — relecture des tables, priorités, masques, cookies, groupes, meters et ports.
  5. Correspondance — paquet contrôlé et variation des bons compteurs.
  6. Sortie — compteur du port ou de la file et absence de cause locale de perte.
  7. Chemin — observation en aval ou sonde active représentative.
  8. Résultat — reçu de la destination ou transaction applicative.

Chaque preuve a une frontière. Les assembler exige des identifiants communs : version du changement, identité du commutateur, génération de connexion, transaction OpenFlow, cookie, en-tête de sonde et fenêtre temporelle. Sans cette jointure, une lecture d’état ancienne et une sonde récente peuvent fabriquer un succès qui n’a jamais existé.

Sources