Résumé

  • La RFC 3532 exige que le partitionnement dynamique conserve l’état existant d’un élément de commutation virtuel actif. Elle n’impose pourtant pas à tous les protocoles une notification proactive : le contrôleur peut apprendre la réduction seulement lorsqu’une demande ultérieure échoue et qu’il interroge les ressources disponibles.
  • Une preuve sérieuse sépare le droit de répartir, l’allocation imposée, les ressources déjà utilisées, le gel et la vidange, la prise de connaissance du contrôleur, les services entre partitions et le résultat applicatif. Le mot « réussi » ne peut signer toute cette chaîne.

Le redémarrage est un événement commode pour l’audit : il marque une frontière que tout le monde voit. La méthode statique décrite dans la RFC 3532 déconnecte les contrôleurs concernés, libère généralement l’état configuré, met l’élément virtuel hors service puis oblige à le reconstruire. La méthode dynamique retire cette rupture visible. Elle modifie les ressources d’une partition active et doit conserver son état existant.

L’absence de rupture ne crée cependant pas une connaissance instantanée. Une session de contrôle peut rester ouverte tandis que son budget a changé. Des entrées peuvent subsister alors que les files, tampons, connexions ou capacités disponibles se sont contractés. La continuité de l’état est une propriété précise, pas une garantie de capacité ni de résultat.

Publiée en mai 2003, la RFC 3532 est Informational et précise qu’elle ne définit aucune norme Internet. C’est un document d’exigences, non un protocole complet. Il vise surtout le partitionnement de commutateurs GSMP. Pour d’autres commutateurs, notamment ceux qui utilisent la correspondance au préfixe le plus long, les exigences peuvent être nécessaires sans être suffisantes.

Le propriétaire, le gestionnaire, le commutateur et le contrôleur ne signent pas la même chose

L’élément de commutation, ou SE, transporte les paquets et expose des ressources divisibles. Une partition, aussi appelée SE virtuel, est un ensemble de ces ressources. Un contrôleur dirige une partition active. Le gestionnaire de partitions, ou PM, décide combien de SE virtuels existent et ce que chacun reçoit.

Ces rôles ouvrent plusieurs plans de preuve. Le PM demande une allocation au SE. Le SE applique et impose la limite. Le contrôleur programme l’activité de la partition. Le PM et le contrôleur peuvent négocier une baisse en cours d’exploitation. Une seule ligne « capacité modifiée » efface l’auteur, l’exécutant, l’utilisateur et le destinataire de l’information.

Les entités sont logiques. Elles peuvent vivre dans une même machine ou être distribuées. Leur séparation logique n’atteste donc ni une isolation physique ni un domaine de panne indépendant. Leur colocalisation ne fusionne pas leurs pouvoirs. Une trace doit associer chaque rôle à son principal réel et à son emplacement au moment de l’opération.

La RFC propose l’exemple d’un propriétaire qui découpe une infrastructure et loue le contrôle de SE virtuels à des tiers. Cet exemple ne prouve aucun contrat commercial réel. Le droit issu du bail, l’autorité du PM, l’autorité du contrôleur et la limite effectivement appliquée sont quatre faits distincts.

Une ressource occupée transforme la réduction en refus légitime

Le SE doit empêcher un contrôleur de consommer plus que son allocation courante. Cette obligation fixe la nouvelle frontière. Elle n’autorise pas à détruire silencieusement un travail actif pour faire paraître la réduction conforme.

Si le PM demande de retirer des ressources à une partition active et qu’une partie de ces ressources est utilisée, le SE doit refuser. Le refus protège l’activité existante ; il n’est pas une anomalie à maquiller. Il sépare une capacité inutilisée, qui peut partir tout de suite, d’une capacité vivante, qui exige une coordination.

Après ce refus, le PM devrait geler la partition, demander au contrôleur de réduire son utilisation, ou combiner les deux. Une partition gelée abandonne ses ressources libres, garde ses connexions actuelles et rend progressivement des ressources lorsque ces connexions se ferment. Elle n’est ni en fonctionnement normal ni arrêtée. C’est un état de vidange orienté vers une cible.

Si le contrôleur ne rend jamais assez de ressources, le PM peut recourir à une extinction virtuelle : la partition devient inactive et les contrôleurs sont déconnectés. Cette issue évite une rétention indéfinie, mais elle est perturbatrice. Obtenir finalement la capacité par extinction ne permet pas d’affirmer que la réduction dynamique s’est déroulée sans interruption.

Le reçu doit conserver l’ancienne allocation, l’usage observé, la cible, le type de ressource, la décision du SE, le gel, la négociation et le sort de chaque élément occupé. Une nouvelle limite isolée ne dit pas si elle a été atteinte en attendant une vidange ou en supprimant un service.

L’information peut arriver par quatre chemins aux temporalités différentes

Un protocole de contrôle peut offrir une notification proactive : le SE avertit le contrôleur de façon asynchrone lorsque l’allocation change. C’est le chemin le plus lisible. La RFC ne l’impose toutefois pas à tous les protocoles, car elle exige déjà une forme de notification réactive.

La notification réactive explicite apparaît lorsqu’une demande ultérieure échoue avec une erreur indiquant que les ressources ont été réaffectées. Dans la forme implicite, la demande reçoit une erreur générique, inconnue ou relative aux ressources. Le contrôleur doit alors interroger les ressources disponibles pour déterminer si une réallocation explique l’échec.

Le PM peut aussi prévenir directement le contrôleur. Cette voie exige sa propre preuve d’authentification, d’envoi, de réception et de traitement. Un message expédié ne garantit pas une mise à jour du planificateur. Une erreur précise ne garantit pas une interprétation correcte. Une interrogation réussie ne révèle pas les décisions futures du contrôleur.

Il faut donc distinguer l’heure d’allocation, l’heure de connaissance, l’heure d’adaptation du modèle et l’heure d’observation du service. Leur écart peut être celui d’un message, de la prochaine demande ou d’une enquête après erreur générique. Pendant cet intervalle, le SE peut appliquer correctement la nouvelle limite tandis que le contrôleur agit de manière cohérente avec une représentation périmée.

Les automatisations doivent conserver le mécanisme exact : notification proactive, erreur réactive explicite, erreur implicite suivie d’une interrogation, ou contact direct du PM. Elles doivent ensuite enregistrer la version du modèle du contrôleur, son accusé et son nouvel essai. Sans cette seconde preuve, sa connaissance reste une hypothèse.

L’inventaire du commutateur n’est pas la mémoire du contrôleur

Le PM doit pouvoir interroger le SE sur ses ressources, ses partitions configurées et l’allocation de chacune. Pour automatiser l’échange avec les contrôleurs, il doit pouvoir obtenir du SE les adresses des contrôleurs attachés à un SE virtuel. Il peut aussi connaître le protocole de contrôle et sa version.

Cet inventaire est indispensable : il dit ce que le SE déclare et aide à trouver qui contacter. Il ne dit pas que le contrôleur a reçu une notification, accepté le nouveau budget, cessé de demander des ressources absentes ou maintenu le service.

Si l’état désiré par le PM diverge de l’état déclaré par le SE, le problème concerne l’allocation ou la réconciliation. S’ils concordent mais que le contrôleur agit avec l’ancienne limite, le problème concerne la connaissance ou l’adaptation. Si les trois concordent mais que l’utilisateur échoue, l’enquête doit passer au plan de données et à l’application. Une alerte unique « désynchronisé » brouille ces diagnostics.

Une interrogation a aussi une date. La preuve doit fixer l’identité du SE, la partition, le schéma de ressources, les valeurs, l’heure et le condensat de réponse. Le prochain inventaire ne doit pas écraser le précédent : la valeur actuelle ne reconstitue pas ce que le contrôleur croyait lors d’une demande rejetée.

Les services entre partitions dessinent le vrai rayon d’impact

Un SE peut fournir un service d’un SE virtuel à un autre, par exemple une liaison virtuelle. Il doit exposer les services disponibles entre partitions, et le PM doit pouvoir les configurer. Si une opération ajoute ou retire un port virtuel, le SE doit notifier les contrôleurs attachés lorsque leur protocole le permet.

Une réduction locale dans le registre d’allocation peut donc modifier une dépendance consommée ailleurs. L’autre partition peut ne pas être la cible directe et néanmoins dépendre d’un port ou d’une capacité touchée. La conservation de son propre quota ne prouve pas la conservation du service traversant la frontière.

La validation doit d’abord montrer que des partitions représentatives hors impact conservent leur allocation et leur identité d’exécution. Elle doit ensuite inventorier les services qui franchissent la frontière et tester leurs ports, leur capacité et leur résultat. Le premier contrôle protège les locataires sans rapport ; le second empêche de confondre un déploiement minimal avec l’ignorance d’une dépendance réelle.

Le partage d’un châssis, d’un gestionnaire, d’un protocole ou d’un fichier de configuration ne suffit pas à mettre toutes les partitions dans le lot. L’impact suit les allocations changées, les entrées exécutables, les dépendances directes et les migrations nécessaires.

Être autorisé à répartir n’établit ni le droit commercial ni la sécurité de la cible

Seul un PM autorisé peut repartitionner dynamiquement le SE. Celui-ci doit utiliser un processus sûr par lequel une entité autorisée sélectionne le PM de contrôle, explicitement ou au moyen d’une découverte autorisée. Seul ce PM ou son agent autorisé peut demander aux contrôleurs de libérer des ressources ou les informer d’une hausse.

Dans l’autre sens, le PM doit authentifier qu’une demande de changement provient d’un contrôleur autorisé pour le SE virtuel indiqué. Cette frontière empêche un locataire de remodeler l’enveloppe d’un autre.

L’authentification identifie le détenteur d’un justificatif dans un processus de confiance. L’autorisation dit s’il peut effectuer cette opération sur cette partition. Ni l’une ni l’autre ne prouve le droit contractuel, la suffisance de la capacité, l’application effective ou le résultat du service.

La sélection du PM doit rester historisée. Si l’autorité passe d’un gestionnaire à un autre, un justificatif valide aujourd’hui ne légitime pas rétroactivement une opération ancienne. Chaque demande doit être liée à la sélection, au justificatif, à la version de politique, à la partition et au condensat qui existaient lors de la décision.

Les RFC ultérieures fournissent un contexte, pas un reçu rétroactif

Les RFC 3654 et 3746 ont ensuite décrit des exigences et un cadre de séparation entre éléments de transfert et de contrôle. Les RFC 5810 et 5812 ont spécifié le protocole ForCES et son modèle d’élément de transfert ; la RFC 7121 a traité la haute disponibilité ForCES.

Cette histoire n’élève pas la RFC 3532 au rang de norme, ne remplit pas une trace d’exploitation absente et ne prouve pas qu’un système donné emploie ForCES. Les RFC 3654 et 3746 sont Informational ; les RFC 5810, 5812 et 7121 sont Proposed Standard. Chacune garde sa date, son statut et son périmètre.

Les métadonnées bibliographiques, l’historique et les errata établissent l’identité et l’état documentaire. Ils n’observent aucune partition en fonctionnement. Une filiation de protocole n’est pas une preuve de déploiement.

Construire un reçu qui suit la transition au lieu de l’écraser

La chaîne commence par les identités : SE, PM, contrôleur, partition, implantation physique, sélection du PM, justificatifs, version de politique et condensat de la demande. Elle fixe ensuite les ressources déterministes, l’ancienne allocation, l’usage observé et la cible.

Elle enregistre la décision du SE en distinguant libération immédiate de capacité libre, refus pour usage en cours, gel, réduction négociée et extinction virtuelle. Elle contrôle l’état maintenu et la manière dont la nouvelle limite est imposée.

Puis elle nomme le chemin de connaissance : message proactif, erreur explicite, erreur implicite plus interrogation, ou contact direct. La mise à jour du modèle et le nouvel essai du contrôleur y sont liés. L’inventaire postérieur du SE complète le dossier sans se substituer à l’accusé du contrôleur.

Enfin, elle teste les services entre partitions, des partitions non touchées, la capacité du plan de données et le résultat applicatif. Le PM signe sa demande, le SE son allocation, le contrôleur son modèle, le propriétaire du service son comportement et le propriétaire de l’application le résultat utilisateur.

La phrase courte acceptable n’est pas « repartitionnement réussi », mais : « le gestionnaire autorisé a déplacé ces ressources libres à cette heure ; le SE a conservé ces états ; le contrôleur a appris par cette voie et adopté ce modèle ; les dépendances et résultats suivants ont ensuite été observés ». Les maillons inconnus doivent rester visibles.

Evidence boundary

Cet Article ne désigne aucune implémentation, aucun fournisseur, opérateur, SE, PM, contrôleur, locataire, bail, pool, partition, déploiement, incident, panne, événement de sécurité ou résultat client. Il ne rapporte ni adoption actuelle, ni capacité, utilisation, perte, latence ou résultat de service.

La RFC 3532 est traitée comme un document d’exigences Informational de mai 2003, non comme une norme Internet ou un protocole complet. Son hypothèse de partitionnement déterministe n’est pas étendue aux pools statistiques ou à la surréservation. Les documents GSMP, Megaco et ForCES ultérieurs gardent leur propre statut et ne prouvent la conformité d’aucun système réel.

Les notes divulguées de Heng Lu fournissent une perspective éditoriale : borner une autorité à l’opération qu’elle contrôle et fermer un résultat avec des preuves d’exécution. Elles n’établissent ni l’intention de l’IETF, ni un comportement d’implémentation, ni un fait de déploiement.

La conclusion bornée est qu’une partition active peut être réallouée sans redémarrage alors que son contrôleur n’apprend le changement qu’après notification, erreur, interrogation ou contact direct. État conservé et inventaire à jour sont nécessaires, mais ne sont pas le résultat du service.

Sources