Résumé

  • RFC 9730 décrit une coexistence : les éléments GMPLS peuvent découvrir l’état, calculer sous politique locale, signaler via RSVP-TE et agir rapidement en protection, tandis que des contrôleurs coordonnent plusieurs domaines et peuvent demander l’établissement d’un chemin sans configurer chaque saut.
  • Une acceptation par contrôleur, une signalisation RSVP-TE réussie, un basculement local et une restauration de service de bout en bout sont quatre affirmations différentes. Elles exigent des preuves distinctes, avec versions d’état, horodatages et frontières de responsabilité explicites.

Une architecture de coexistence, pas de remplacement

RFC 9730, publié par l’IETF en mars 2025 avec le statut Informational, s’intitule Interworking of GMPLS Control and Centralized Controller Systems. Son apport principal est de décrire l’interfonctionnement entre deux styles de contrôle déjà établis, et non l’abolition de l’un par l’autre.

Dans un domaine GMPLS, un élément de réseau peut collecter l’état des nœuds et des liens, construire une topologie, calculer un chemin selon une politique locale, puis allouer des labels au fil de la signalisation RSVP-TE. Cette capacité distribuée reste pertinente parce que l’équipement dispose d’une connaissance directe de ses ressources et de son environnement immédiat.

Dans une architecture ACTN, RFC 8453 place le Multi-Domain Service Coordinator, ou MDSC, entre les demandes du Customer Network Controller et les ressources exposées par les Physical Network Controllers. Le MDSC traduit les services, coordonne les domaines et travaille avec des représentations plus ou moins abstraites. Le PNC configure et surveille les éléments de réseau et peut exposer une topologie brute, réduite ou abstraite.

Un contrôleur peut donc sélectionner ou pré-calculer un chemin puis demander au nœud d’entrée de le provisionner, par exemple via PCInitiate ou NETCONF. Il n’a pas besoin de configurer chaque saut. Une fois la demande reçue, RSVP-TE peut fonctionner entre les éléments pour établir le chemin et programmer les ressources locales.

Cette séparation évite une fausse opposition. « Centralisé » ne signifie pas que toute action se déroule au centre ; « distribué » ne signifie pas que le contrôleur est absent. RFC 9730 décrit une surface de contrôle composite.

Où se prend la décision de chemin

Le calcul peut se situer dans le contrôleur, au nœud d’entrée sur la base de sa Traffic Engineering Database, ou dans un Path Computation Element. Dans le modèle PCE classique, le PCE renvoie un chemin au Path Computation Client, qui décide si et quand le déployer. Avec le fonctionnement PCE-initiated, le PCE peut déclencher l’établissement, la maintenance ou la suppression d’un LSP.

Cette distinction compte pour la preuve. « Le PCE a calculé un chemin » ne signifie pas « le chemin a été installé ». « Le contrôleur a envoyé PCInitiate » ne signifie pas « RSVP-TE a convergé ». Même un échange RSVP Path/Resv réussi ne démontre pas encore que le service client respecte son objectif de performance.

En multi-domaine, le montage peut prendre plusieurs formes : RSVP-TE de bout en bout, LSP de domaines assemblés, ou segments séparés. Les labels inter-domaines peuvent être alloués par des nœuds frontières ou par des contrôleurs. Une vue globale peut donc connaître la continuité logique du service sans posséder tous les détails internes.

Une vue globale peut être volontairement incomplète

L’interface MPI transporte des demandes de connectivité et de bande passante ainsi que des abstractions filtrées par politique. Un graphe multi-domaine peut donc être global tout en étant volontairement incomplet à l’intérieur des domaines.

Cette abstraction n’est pas nécessairement une faiblesse. Elle permet de préserver l’autonomie, de limiter l’exposition et de coordonner sans publier toutes les ressources internes. Mais elle change la portée de l’affirmation « le contrôleur connaît le réseau ».

Les éléments et contrôleurs peuvent détenir des états différents, à des granularités différentes et sur des horloges différentes. Le PNC peut avoir une vue brute récente, le MDSC une vue abstraite, et le head-end une TED mise à jour selon un autre rythme. RFC 9730 ne fournit aucune borne universelle de fraîcheur.

Une décision doit donc être reliée à la version ou à l’instant de l’abstraction utilisée, aux politiques appliquées et aux réponses des PNC. Sans cela, il devient difficile de distinguer un mauvais calcul d’une décision raisonnable prise à partir d’un état devenu obsolète.

La restauration comme passage de relais

Lors d’une défaillance, la réaction peut combiner action locale rapide et coordination plus large. Ce n’est pas un bouton unique. Pour la protection de span, RFC 9730 n’ajoute pas de nouvelle exigence. Une architecture centralisée peut calculer des chemins disjoints, tandis que le basculement effectif peut être assuré localement par APS ou des mécanismes GMPLS tels que Notify.

Le Fast Reroute montre la séparation des rôles : le contrôleur peut calculer, RSVP-TE peut créer l’état nécessaire, puis le Point of Local Repair détecte la panne et commute le trafic. Calcul, création et détection/basculement sont des opérations différentes.

RFC 4873 permet en outre à un point de branchement ou PLR d’établir un LSP de récupération indépendant jusqu’à un nœud de fusion. Le choix dynamique du point de branchement et du merge node peut être local. Si la récupération ne peut pas être établie, l’incapacité doit être signalée.

RFC 4426 distingue les récupérations span, segment et bout en bout et autorise des niveaux concurrents. Une protection locale peut donc réussir tandis qu’une restauration plus large s’organise. Préemption et réversion peuvent également provoquer de nouvelles perturbations : l’existence d’un chemin alternatif ne prouve pas une transition sans effet secondaire.

Quand le problème dépasse un domaine

Dans un domaine GMPLS, une panne peut d’abord déclencher un reroutage de segment. Si les ressources sont insuffisantes, ou si une liaison inter-domaine échoue, l’information remonte via le Controller(G) vers le MDSC. Celui-ci peut calculer et déclencher une alternative multi-domaine, y compris en faisant intervenir un nouveau domaine.

Il faut alors séparer quatre affirmations :

  1. le contrôleur a accepté ou produit une demande de reroutage ;
  2. les domaines ont reçu et signalé les chemins nécessaires ;
  3. le mécanisme local a réellement commuté le trafic ;
  4. le service de bout en bout a retrouvé la connectivité et les performances attendues.

Les journaux du contrôleur ne prouvent pas à eux seuls la commutation physique. Les messages RSVP-TE ne prouvent pas à eux seuls l’expérience de service. Une mesure de bout en bout, inversement, ne permet pas toujours d’identifier le mécanisme qui a fourni la continuité.

La chaîne de preuves opérationnelle

Pour rendre l’interfonctionnement vérifiable, la preuve doit suivre la décision jusqu’au résultat.

Au niveau contrôleur et MDSC, il faut relier la demande et ses contraintes à la version de topologie abstraite, aux politiques de filtrage, aux réponses des PNC, au chemin ou aux segments retenus, aux hypothèses de disjonction et à l’accusé de réception de la commande de reroutage.

Au niveau du domaine, il faut conserver l’état pertinent de la TED brute, le résultat du calcul sous politique locale, la réception de PCInitiate ou NETCONF, les messages RSVP Path, Resv et les erreurs, la programmation des labels et cross-connects, ainsi que l’état remonté par un mécanisme équivalent à PCRpt.

Pour la récupération locale, les éléments utiles sont l’horodatage de détection, le PLR, les points de branchement et de fusion, la portée protégée, l’état du détour ou bypass, l’instant de commutation, les notifications de ressources insuffisantes et les événements de préemption ou de réversion.

Enfin, le niveau de service fournit la preuve finale : accessibilité des extrémités, performance observée et respect des objectifs à la frontière client.

Cette succession empêche de prendre une preuve de contrôle pour une preuve de service. L’acceptation d’une commande et la récupération d’un service appartiennent à la même chaîne causale, mais ce ne sont pas le même fait.

Fraîcheur, continuité et limites

RFC 9730 permet à un contrôleur de rafraîchir un chemin alternatif dans un domaine unique. Cela peut réduire le risque de reposer sur un état ancien, mais la fraîcheur dépend toujours du reporting, du traitement, du stockage de l’état et de l’information disponible au head-end. Aucun seuil universel n’est défini.

Les services existants et les protections préétablies doivent continuer à fonctionner lorsque le contrôleur devient indisponible. La redondance et les fonctions de secours des éléments de réseau sont souhaitables. Cela ne signifie pas que toute recomposition reste possible : une nouvelle optimisation inter-domaine peut nécessiter le MDSC.

Chaque entité a enfin besoin de politiques propres de gestion, confiance et sécurité. Les contrôleurs sont des points de grande valeur : authentification, autorisation, correction logicielle, supervision et protection sont donc indispensables.

RFC 9730 ne définit ni produit de télémétrie unique, ni cible universelle de convergence, ni format de preuve. Il ne faut pas non plus lui attribuer ce qui relève de RFC 9731 sur le modèle YANG de réseau virtuel, de RFC 9732 sur le partitionnement NRP ou de RFC 9889 sur la réalisation de tranches 5G. Certaines formes de récupération non-GMPLS restent hors de son champ.

Sources