Résumé

  • Le service externe FAS pouvait autoriser, refuser, rediriger ou assortir une connexion de règles, mais le commutateur restait le lieu où la connectivité naissait.
  • FAR, FAA, FAU, FUN, FUA, FCR et FCA formaient des reçus successifs, jamais une preuve unique d’exécution et de résultat.
  • Les erreurs AMBIGUOUS et NO_SUCH_FLOW, plus l’absence d’analyse de sécurité, rendaient visible la séparation entre décision, état et trace économique.

En mars 1997, RFC 2124 proposa de sortir la politique d’admission d’un commutateur ATM. Un Connection Control Entity (CCE) local décrivait la connexion à créer ; un Flow Admission Service (FAS) externe décidait si elle pouvait être admise et sous quelles conditions. L’intérêt était immédiat : une organisation pouvait appliquer une politique commune à plusieurs commutateurs alors qu’aucune représentation normalisée de cette politique n’existait.

Le registre RFC Editor et la fiche IETF Datatracker rappellent toutefois la portée exacte du texte : document informatif, pas norme Internet. Il n’atteste ni adoption générale ni déploiement encore actif.

Une question envoyée avant la connexion

Le commutateur prenait toujours l’initiative. Juste avant l’établissement d’un flux, son CCE envoyait un Flow Admission Request (FAR) avec l’identifiant du flux, les extrémités, le type de service, l’heure du commutateur et, selon le cas, des données client.

Le FAS répondait par un Flow Admission Acknowledge (FAA). Il pouvait refuser pour raison de politique, accepter, ajouter des règles de fonctionnement ou indiquer une destination de redirection. Cette réponse décrivait la décision du FAS. Elle ne démontrait pas que le commutateur avait créé la connexion ni qu’un paquet avait atteint son destinataire.

La distinction entre règle facultative et règle obligatoire l’établissait sans ambiguïté. Une règle facultative incomprise pouvait être ignorée. Une règle obligatoire incomprise imposait l’abandon du flux et l’envoi d’un Flow Admission Update signalant l’échec. La politique centrale fixait donc une condition ; la capacité locale déterminait si cette condition pouvait devenir réalité.

L’état vécu arrivait plus tard

Après établissement, le CCE envoyait des Flow Update Notifications (FUN), périodiquement ou lors d’un changement. Elles pouvaient contenir l’heure, l’état actif ou inactif, les octets et les paquets, cellules ou trames reçus et envoyés.

Il fallait conserver la sémantique du compteur. Un compteur cumulatif partait du début du flux ; un compteur différentiel couvrait seulement l’intervalle depuis le FUN précédent. Mélanger les deux détruisait la chronologie. Et même un compte exact ne prouvait ni droit d’usage, ni livraison applicative, ni montant facturable.

Le Flow Update Acknowledge (FUA) avait une portée remarquablement précise : SUCCESS signifiait que l’information du FUN avait été acceptée et relevait désormais de la responsabilité du FAS. C’était un transfert de garde de l’information, pas une garantie de conservation durable, de complétude ou de résultat de service.

Le FAS pouvait ensuite envoyer un Flow Change Request (FCR) pour modifier la politique ou arrêter le flux. Le commutateur répondait par un Flow Change Acknowledge (FCA). POLICY_REJECT signalait une politique non supportée ; NO_SUCH_FLOW, l’absence d’état correspondant côté commutateur. L’autorisation initiale n’abolissait donc jamais la nécessité de réconcilier les deux systèmes.

Les identifiants ne remplaçaient pas le contenu

Un Flow ID répété n’était sûr que si le nouveau FAR était identique au précédent, sauf éventuellement pour Message ID. Le FAS rejouait alors la même réponse. Si le contenu différait, il retournait AMBIGUOUS et exigeait un nouvel identifiant. L’idempotence portait sur la requête entière, non sur le numéro.

NO_SUCH_FLOW révélait également la divergence dans l’autre sens : le FAS pouvait recevoir un FUN pour une connexion jamais admise ou dont il avait perdu l’état. Il pouvait demander une nouvelle admission, suivre l’erreur ou demander l’arrêt de la connexion. Aucun côté n’était déclaré vrai par principe.

Un préfixe attribué par le FAS, combiné à l’identifiant du CCE, devait maintenir l’unicité lors d’un basculement vers un FAS alternatif. Sans ce préfixe, un même appel pouvait apparaître comme deux appels au point d’agrégation. Le préfixe organisait l’identité ; il ne prouvait pas que les instances alternatives avaient répliqué le même historique.

Le protocole centralisait du pouvoir sans traiter sa sécurité

Un FAS pouvait refuser, rediriger ou arrêter des connexions. Pourtant la section Security Considerations se contente d’indiquer que les questions de sécurité ne sont pas discutées. Une session TCP n’authentifiait pas à elle seule l’origine légitime de la politique. L’actuel registre IANA des services et ports associe csi-lfap au port 3145 et signale par ailleurs un usage non autorisé connu de ce port : enregistrement et sécurité restent deux faits différents.

La différence avec les articles BTW voisins est nette. RFC 2063 fournit l’architecture de mesure, et l’article existant étudie le temps perdu entre deux lectures. RFC 2123 décrit NeTraMet, et l’article existant étudie la projection des paquets par le jeu de règles. Ici, le sujet est le passage d’un verdict central à un état exécuté, puis à une trace réconciliée.

Les textes de Heng Lu sur la primauté du code en fonctionnement, la spécification initiale minimale et la décision future localisée et les couches de réalité offrent un vocabulaire contemporain pour cette discipline : la déclaration centrale n’est pas encore l’exécution locale.

LFAP préfigurait les contrôleurs programmables. Sa leçon durable est plus sobre : conserver séparément le reçu de décision, le reçu d’action, le reçu d’état et le reçu comptable.

Sources