Résumé

  • À l’entrée du réseau, le PE remplace les CPI du client par des PPI du fournisseur dans les objets Session et Sender Template ; à la sortie, un autre PE restitue les CPI.
  • Une session demeurée stable ne démontre donc pas quelle version de la PIT a été consultée, quel port physique a été choisi, ni si le plan de données a réellement livré le service attendu.

Le reçu rassurant qui ne suffit pas

Un équipement client demande une connexion entre deux ports qu’il connaît. La signalisation revient avec les mêmes repères compréhensibles par le client et l’état de session paraît cohérent. Pour l’exploitant ou le décideur, la tentation est forte : si la session n’a pas changé d’identité, le service aurait suivi un chemin continu et bien déterminé.

La RFC 5251 organise précisément une autre réalité. Son mode de brassage maintient une session RSVP-TE de bout en bout tout en changeant le vocabulaire employé à l’intérieur du réseau. Le PE d’entrée traduit les identifiants de ports clients, ou CPI, en identifiants de ports fournisseur, ou PPI. Le PE de sortie exécute la traduction inverse. La même abstraction visible recouvre ainsi deux décisions de correspondance et un segment interne que le client n’a pas à voir.

Cette séparation est utile. Elle permet au fournisseur de garder son plan d’adressage indépendant et de masquer sa topologie. Elle interdit toutefois de faire du reçu de session une preuve universelle. Ce reçu atteste une transition de signalisation ; il ne certifie pas à lui seul la table de traduction, le brassage physique, la ressource programmée ou le trafic arrivé.

Trois noms, trois autorités

Le CPI désigne le côté client d’un port. Le PPI désigne son côté fournisseur. Le VPN-PPI est l’identité du port du PE dans l’espace d’adressage du L1VPN. Ces noms ne sont pas trois orthographes interchangeables. Le fournisseur maîtrise les PPI, tandis que l’administration du L1VPN maîtrise les CPI et VPN-PPI.

La RFC autorise, par commodité, un PPI non numéroté et un VPN-PPI à partager le même indice. Une valeur identique ne fusionne pas les espaces d’autorité. Un journal qui conserve seulement « port 17 » mais perd le type d’identifiant, le VPN et la frontière observée détruit l’information nécessaire à l’enquête.

La même prudence vaut pour le canal de contrôle. Les adresses CE et PE doivent être uniques au sein d’un L1VPN, mais peuvent être réutilisées dans un autre. L’adresse ne devient donc significative qu’avec le contexte VPN. Ce qui ressemble à un identifiant global peut n’être qu’un symbole local.

La PIT est la charnière opérationnelle

Chaque bordure tient une Port Information Table propre au VPN. Elle associe CPI et PPI et conserve, pour les ports locaux, les informations VPN-PPI. Le provisionnement peut l’alimenter ; les mécanismes de découverte décrits par les RFC 5195 et 5252 peuvent aussi fournir des éléments.

Mais la découverte n’est pas l’acte décisif de cet article. Au moment de la demande, le PE d’entrée choisit une PIT dans le contexte du L1VPN, résout le CPI cible en PPI et réécrit les objets RSVP-TE. À l’autre extrémité, une seconde consultation restaure les valeurs que le CE destinataire peut comprendre.

Pour qu’un audit soit reproductible, il faut savoir quelle génération exacte de la PIT a servi aux deux décisions. Une ligne syntaxiquement valide peut être périmée, mal provisionnée ou rattachée au mauvais contexte. Le protocole peut alors exécuter correctement une mauvaise correspondance. La section sécurité de la RFC ne remplace pas cette question par une promesse : elle insiste sur la protection de la gestion et invite à envisager une vérification du plan de données contre les erreurs de configuration.

La topologie cachée reste une topologie

Dans le réseau du fournisseur, les messages portent les PPI. Aux frontières, le brassage doit s’appliquer à tous les messages RSVP-TE concernés, faute de quoi les différents états de la même session divergeraient. Du côté client, le service demeure un LSP et le segment entre PE apparaît comme un lien virtuel. Du côté fournisseur, ce segment possède des détails de chemin et de ressources.

Le PE peut filtrer ces détails. Les objets Record Route et Notification peuvent être modifiés ou retirés aux frontières selon les règles de superposition. Ce cloisonnement est légitime : l’acheteur d’un service n’acquiert pas automatiquement la carte interne de l’opérateur. Il signifie seulement qu’un auditeur ne peut pas reconstruire le chemin caché à partir de la vue épurée du client.

Une seule session visible ne signifie ni un seul saut, ni une seule longueur d’onde, ni un chemin immuable. La RFC prévoit aussi des modes cousus ou imbriqués. Les RFC 5150 et 4206 décrivent comment associer des segments ou une hiérarchie de LSP au service client. Le résultat commercial peut sembler identique alors que les reçus internes sont très différents. Le mode choisi appartient donc à l’évidence, pas seulement à la configuration.

L’acceptation n’est pas le brassage physique

Le CE émet une demande avec un CPI source et un CPI cible. Le fournisseur applique sa politique de topologies autorisées, traduit les noms et calcule le chemin interne. Le CE distant peut accepter la demande. Chacune de ces étapes répond à une question bornée : intention du client, autorisation, résolution d’identité, décision du destinataire.

Aucune ne regarde directement le commutateur ou le circuit. Un message Path ou Resv appartient au plan de contrôle. La réservation de ressources, la programmation d’un label ou d’une longueur d’onde, l’état de protection, la continuité optique et le trafic client relèvent de couches ultérieures. Même un test CE-à-CE ne prouve que les paquets ou signaux qu’il a effectivement envoyés et reçus ; il ne démontre pas automatiquement la performance contractuelle ni le résultat applicatif.

Un Explicit Route Object fourni par le client ne renverse pas cette autorité. Le PE peut le refuser. Quand la forme permise est lâche, le PE calcule encore le chemin interne et l’insère. Le client peut contraindre le service sans devenir l’auteur de chaque saut du réseau fournisseur.

Construire une chaîne de preuve réversible

Le premier reçu devrait préserver l’identité du L1VPN, le canal de contrôle, les CPI source et cible originaux et l’horodatage. Le reçu suivant devrait nommer la version de PIT, la provenance de ses lignes, les PPI résolus et les valeurs avant et après réécriture. La sortie devrait conserver la consultation inverse, les CPI restaurés et l’acceptation du CE cible.

Ensuite seulement viennent l’état RSVP, la programmation des ressources, le test du plan de données et l’observation du service. Réduire cette chaîne à un booléen « session active » rend l’explication impossible dès qu’une table change. Le fournisseur peut protéger les détails de topologie vis-à-vis du client tout en conservant, dans un domaine d’audit restreint, la corrélation entre le segment caché et l’abstraction vendue.

La discipline des couches de réalité de Lu Heng donne ici une règle très concrète. Un nom dans l’espace client n’est pas le même fait qu’un nom dans l’espace fournisseur. Une traduction réussie n’est pas une connexion physique observée. Une session continue n’est pas encore un service continu. La responsabilité d’un système en production commence lorsque chaque frontière indique ce qu’elle a transformé et ce qu’elle a réellement mesuré.

Sources