Résumé

  • RFC 7212 permet à une extrémité MPLS d’annoncer des capacités, des paramètres de configuration et des données propres à une application sur le G-ACh ; l’émetteur ne devient pas l’autorité de configuration du récepteur.
  • Le récepteur garde la maîtrise grâce à l’activation par canal, à l’autorisation locale des applications, aux règles de traitement propres à chaque application, aux durées de vie et à la vérification de fraîcheur.
  • Une automatisation sûre exige une chaîne de raisons visible : donnée reçue, authentification, durée de validité, règle locale consommatrice et justification de toute modification.

Une annonce décrit un fait, elle ne donne pas un ordre

Le protocole GAP répond à un besoin concret des réseaux de transport. Une extrémité de LSP, de pseudowire ou de section doit parfois indiquer à son pair les capacités qu’elle prend en charge, les paramètres qu’elle utilise ou les informations utiles à une application. Dans un environnement MPLS-TP sans IP, les mécanismes usuels de découverte IP peuvent être absents. Un canal d’annonce indépendant de la couche de liaison réduit alors la configuration statique fragile et révèle plus tôt les incohérences.

La frontière de gouvernance se trouve dans le terme « annonce ». RFC 7212 définit un mode unidirectionnel simple : un émetteur configuré transmet des blocs de données applicatives typés. Le récepteur peut valider ou ajuster sa propre configuration, mais les deux rôles administratifs ne fusionnent pas. Émission et réception sont configurables canal par canal par l’opérateur. Toutes les applications GAP sont désactivées par défaut. Les données reçues ne sont exposées qu’aux applications locales qui en ont besoin et sont autorisées à les consulter.

Le partage des pouvoirs est donc net. L’émetteur répond de la donnée qu’il publie. L’opérateur du récepteur décide si GAP fonctionne, quelle application peut voir l’information et ce qu’elle a le droit d’en faire. La spécification de l’application donne leur sens aux TLV. L’arrivée d’un paquet ne prouve aucune de ces permissions.

Un cas de contrôle concret

Prenons deux nœuds MPLS-TP voisins sur une section Ethernet dépourvue d’acheminement IP. Le nœud A annonce son adresse MAC source et sa taille maximale de trame avec l’application Ethernet Interface Parameters de RFC 7213. Le nœud B peut apprendre l’adresse et comparer la taille annoncée à son minimum local.

Cette information est utile, mais elle n’ordonne pas à distance l’arrêt du lien. RFC 7213 laisse la réponse à la politique configurée : l’opérateur peut couper le lien après une incompatibilité ou le maintenir et vérifier la taille effective avec un outil OAM. Un même fait reçu peut donc produire des décisions légitimes différentes selon la politique locale.

L’opérateur bénéficie d’une vue vérifiable de l’état du pair, d’un moyen de remplacer des hypothèses statiques devenues obsolètes et d’une trace de diagnostic lorsque les deux extrémités divergent. RFC 7213 recommande d’émettre l’annonce concernée dès que possible après une reconfiguration, un redémarrage ou une déconnexion détectée afin de réinitialiser l’état du lien. Les applications disposent d’un support commun qui ne dépend pas d’un protocole de découverte particulier. Aucun de ces gains n’exige l’abandon de l’autorité locale.

Fraîcheur, identité et sens sont trois contrôles distincts

Chaque bloc applicatif possède une durée de vie. Les données statiques ne peuvent être retenues que pendant cette période. Une durée nulle les marque immédiatement comme expirées ; un bloc vide peut expirer les données antérieures de l’application. Après un redémarrage, l’état conservé des pairs et des applications doit être supprimé. Une ancienne observation ne doit pas se présenter comme une autorité actuelle.

L’authentification répond à une autre question. RFC 7212 prévoit un code d’authentification de message et des horodatages contre le rejeu. Les identifiants de clé sont associés aux paramètres cryptographiques par configuration explicite de l’opérateur ou par un mécanisme d’échange distinct. Authenticité, fraîcheur et autorisation sémantique restent séparées. Un MAC valide démontre la protection du message par une clé admise ; il ne décide ni d’une réécriture locale ni de la prolongation d’une donnée expirée.

Un récepteur qui ne sait pas interpréter une application peut conserver les octets pendant la durée indiquée afin d’aider l’opérateur. Conserver une preuve n’est pas l’exécuter. Le système peut signaler qu’il ignore le sens sans fabriquer une décision.

Le coût d’exploitation suit l’autorité

GAP laisse volontairement plusieurs charges aux applications et aux opérateurs. L’émetteur choisit la cadence. L’application fragmente elle-même les données trop grandes, car GAP ne fournit ni fragmentation ni réassemblage. Ensemble, application et opérateur doivent éviter de saturer le lien. Gestion des clés, horloges, tolérance au rejeu, expiration, purge au redémarrage et visibilité d’audit exigent un propriétaire opérationnel.

Le protocole impose aussi que les données reçues soient inspectables. Quand une information entrante modifie la configuration locale, la cause du changement doit être claire. C’est le contrôle essentiel : l’automatisation reste gouvernable si un reçu permet de reconstruire le passage entre observation authentifiée, règle locale et modification. Sans cette trace, la commodité transforme silencieusement la déclaration d’un pair en autorité inexpliquée.

Sources