Résumé

  • RFC 3186 présentait aux équipements clients une liaison PPP transparente en remplaçant à l’entrée un ou deux octets d’en-tête, puis en les restaurant à la sortie.
  • Le chemin réel dépendait d’une paire d’adresses MAPOS, de deux changements de mode, d’une convergence bidirectionnelle et d’un isolement par chemin. La base OAM décrivait cet ensemble sans participer au transfert.

Publié en décembre 2001, le document était Informational. La note de l’IESG précisait qu’il ne provenait pas d’un groupe de travail IETF, n’appartenait pas au Standards Track et n’avait pas nécessairement bénéficié du même examen collectif. Il faut donc lire ses mesures comme une expérience documentée, non comme une preuve d’adoption générale.

Le mécanisme profitait d’une ressemblance entre la trame PPP sur SONET/SDH et la trame MAPOS. Le commutateur d’entrée remplaçait les octets PPP fixes par l’adresse MAPOS du port distant. Le réseau acheminait la trame selon cette destination. À la sortie, le commutateur rétablissait les valeurs PPP. Une version changeait un octet, MAPOS 16 en changeait deux.

Le client ne recevait aucun nouvel en-tête. Mais l’absence de surcharge visible ne supprimait pas l’état. Elle le déplaçait vers les commutateurs : destination de réécriture, mode du port, étiquette de signal, route interne, règles d’isolement et correspondance entre ports.

Le passage en mode tunnel réunissait plusieurs opérations. Il fallait désactiver NSP et SSP sur le port client, couper la diffusion et la multidiffusion MAPOS, régler l’étiquette C2 selon le brouillage choisi et activer la réécriture. Le retour au mode natif inversait cet ordre. Le mot « mode » masquait donc une transition distribuée dont chaque étape pouvait réussir ou échouer séparément.

L’établissement du chemin commençait par le choix d’une paire d’adresses MAPOS inutilisée. Dans le modèle décrit, chaque adresse correspondait à un port de commutateur. Les deux extrémités étaient configurées, puis l’opérateur attendait la stabilité des routes et du transfert dans les deux sens. Jusqu’à cette preuve, la liaison vers les équipements clients devait rester abaissée.

Ce détail empêche de confondre configuration et service. Écrire deux adresses dans un outil ne créait pas la bidirectionnalité. Autoriser l’échange transparent des contrôles LCP devenait une décision postérieure à la convergence observée.

RFC 3186 proposait une base de chemins pour l’OAM&P. Son exemple associait utilisateur, débit, mode, paire d’adresses et statut. Cette base aidait notamment à éviter les duplications. Le texte indiquait pourtant qu’elle n’était pas utilisée pour acheminer les trames.

Une ligne « Up and running » était donc une assertion d’exploitation. Le transfert dépendait encore de SSP, des ports et des fonctions de réécriture. La ligne ne prouvait ni le passage d’une trame précise ni sa livraison à l’application. Inversement, un changement réel pouvait précéder la mise à jour de l’inventaire.

La suppression confirmait cette séparation. L’opérateur désactivait les ports clients, pouvait mettre à jour la base, puis rétablissait éventuellement le mode MAPOS par défaut. Toute trame arrivant après la désactivation de la destination devait être jetée silencieusement. Aucun accusé n’expliquait au voisin quelle opération avait produit le silence.

La panne locale ne traversait pas automatiquement le réseau. Une rupture optique près d’un client déclenchait des alarmes SONET/SDH de ce côté. Le côté distant gardait son état physique, car chaque chemin optique se terminait au bord MAPOS. Ce n’est qu’à l’expiration des Echo LCP qu’il distinguait ligne physique et protocole.

Une expiration de keepalive était une observation bornée : l’écho attendu n’était pas revenu à temps. Elle ne localisait pas la rupture, ne distinguait pas toute seule une perte unidirectionnelle et ne décrivait pas le résultat applicatif. SSP pouvait reconstruire une topologie interne sans que le client voie autre chose qu’une interruption temporaire.

La liaison paraissait privée, mais la capacité restait partagée. MAPOS n’offrait pas de QoS au niveau du protocole et POS n’avait pas de contrôle de flux. Le RFC demandait du débit inter-commutateurs suffisant et recommandait l’équité par port dans les configurations surabonnées. La transparence n’était donc ni une réservation ni une garantie de débit.

Les essais de latence avaient une vraie valeur historique parce que leurs limites étaient décrites : équipement nommé, trafic OC12c unidirectionnel à 30 %, paramètres fixes, vingt-cinq essais de 150 secondes et intervalles de confiance. Le commutateur MAPOS mesuré était plus rapide que le routeur comparé dans ce cadre. Cela ne disait rien de définitif sur toutes les charges, tous les fournisseurs ou toutes les applications.

La sécurité reposait elle aussi sur l’intérieur invisible. Le document estimait qu’un CPE ne pouvait pas piloter directement MAPOS et qu’il lui était difficile d’injecter un autre flux. Il insistait en même temps sur l’isolement par chemin, sur le danger des duplications et sur le risque d’un environnement mêlant ports natifs et tunnels.

MAPOS ne portait pas d’adresse source. En mode mixte, cette absence compliquait l’attribution d’une trame au bon chemin. L’opacité envers le client n’était donc pas une preuve de séparation ; la séparation dépendait de tous les commutateurs et de la discipline de l’opérateur.

L’héritage de RFC 3186 tient à cette dissociation. L’interface simple était réelle, mais partielle. Pour expliquer un incident, il faut conserver la commande de service, la paire d’adresses, les ports, chaque étape de transition, la convergence par direction, la version de la base, l’isolement, les alarmes, les échos LCP et les observations de trames. La liaison visible n’est qu’une couche de la réalité.