Réseaux sans contrainte : la transition vers des opérations autonomes basées sur l'intention

Le secteur des télécommunications, pilier de la connectivité mondiale, connaît depuis quelque temps une renaissance technologique, stimulée par des innovations telles que la 5G, l'IdO, le cloud computing et l'intelligence artificielle. En conséquence, les réseaux sont devenus de plus en plus difficiles à gérer. L’automatisation est nécessaire pour gérer les tâches de routine, surveiller l’état du réseau et résoudre les problèmes en temps réel. Cependant, les compétences dont disposent les fournisseurs de services de communication (CSP) peuvent ne pas correspondre à l'évolution des exigences de cet environnement dynamique. Pour réussir dans le monde moderne, les CSP ont besoin d’équipes polyvalentes, notamment des data scientists pour l’interprétation des données et les opérations, des développeurs de logiciels pour l’automatisation via des interfaces de programmation d’application et des ingénieurs d’assurance pour la conception de boucles fermées afin d'assurer la fiabilité du service.

Si les CSP comblent le fossé en constituant des équipes dotées d’une expérience diversifiée, ils profitent en même temps d’avancées significatives sur une tendance concurrente. Les langages de programmation ont évolué vers des paradigmes low-code/no-code et, avec l’émergence de l’IA générative, nous sommes à un point où les modèles de base peuvent générer du code formel basé sur les descriptions en langage naturel des tâches. Cela a donné une nouvelle perspective au concept de réseau basé sur l'intention (IBN), où des administrateurs humains expriment des objectifs réseau de haut niveau en langage naturel, appelés « intentions », et où ces intentions humaines sont automatiquement traduites dans les politiques et les configurations réseau. L'IBN a le potentiel d'améliorer la gestion des réseaux et pourrait changer la donne en comblant le déficit de talents dans le secteur des télécommunications. Pour aller plus loin, les réseaux autonomes (AN) promettent d’utiliser les intentions comme entrées pour auto-configurer, auto-optimiser et auto-réparer les réseaux de manière autonome à mesure que leurs conditions évoluent.

Bien que nous puissions envisager un avenir prometteur pour l'IBN et l'AN, des préoccupations persistent quant à leur faisabilité et à leurs applications, notamment en ce qui concerne l'expression des intentions, la traduction précise dans la configuration du réseau, la transparence du système et sa complexité, entre autres. Dans cet article de blog, nous explorons les domaines où leur application pratique est potentielle et analysons les défis qu’ils peuvent rencontrer en cours de route.

Pour comprendre la nécessité de rationaliser les interactions entre les équipes CSP et le réseau, nous utiliserons le déploiement d'un nouveau service comme exemple.

Nous supposons que le fonctionnement du réseau CSP est automatisé conformément aux spécifications décrites dans le Guide d'introduction TMF 1230 (IG1230) sur l'architecture technique des réseaux autonomes. Dans ce contexte, l'OSS du CSP dispose (1) d'un orchestrateur pour le provisionnement automatisé des services, le provisionnement automatisé et les tests automatisés, (2) d'un système d'assurance avec inventaire du réseau qui collecte des données, crée des informations sur l'état du réseau et facilite ainsi la prise de décision fondée sur les données. dans le contexte du contrôle en boucle fermée et (3) un gestionnaire de règles qui oriente le comportement du réseau à l'aide de règles prédéfinies, garantissant ainsi l'alignement avec les politiques plus larges du CSP. En résumé, les opérations automatisées s'articulent autour d'un couplage étroit entre les services et les descripteurs de services TOSCA conçus par l'homme qui leur sont attribués, les configurations, les politiques et les workflows impératifs dans lesquels l'intelligence et la prise de décision sont ajoutées par les concepteurs de services pendant la phase de conception. Les concepteurs de services doivent anticiper de manière proactive un large éventail de conditions susceptibles de se produire sur le réseau et fournir des instructions détaillées sur la manière de les traiter. Une expérience sans intervention est possible dès lors que les conditions futures ont été anticipées et que des politiques sont en place pour les gérer.

Nous utilisons les termes Jour 0, Jour 1 et Jour 2 pour différentes étapes du cycle de vie des services, à savoir la conception des services, l’instanciation des services et l’assurance des services.

• La conception de services comprend le développement de divers actifs de service, comme indiqué dans la figure 1. C'est la mission de l'équipe de conception des services, qui doit comprendre le fonctionnement du service les jours 1 et 2 et produire les workflows et les scripts nécessaires. Les lignes rouges de la figure 2 représentent le processus d'application des accès d'un nouveau service, garantissant que le service peut désormais être commandé.

Figure 1 : Processus de conception de service Jour 0 – Conception des actifs de service

• L'instanciation du service a lieu lorsque la commande de service arrive, à la suite d'une demande de l'abonné. Aujourd’hui, dans les CSP, la commande de service arrive généralement par l’interface TMF 641 en provenance du gestionnaire de commande de service (SOM). Lorsque l'orchestrateur de services reçoit la commande de service, il s'assure que les workflows sont exécutés et que les configurations de surveillance, les modèles PM/FM et les politiques demandés sont déployés et en cours d'exécution. Nous illustrons l’instanciation de service dans la figure 2 par des lignes vertes.

• L'assurance de service suit une approche en boucle fermée dans laquelle les conditions des services déployés font l'objet d'une surveillance continue et d'actions automatisées tout au long du cycle de vie. Nous illustrons la boucle fermée d'assurance dans la figure 2 à l'aide de lignes bleues.

Figure 2 : Interactions Jour 0/Jour 1/jour 2

En résumé, il s'agit de la phase de conception qui implique une quantité importante de travail manuel, car il est nécessaire de fournir au réseau des instructions pour le nouveau service.

Dans l'IBN, les intentions désignent les objectifs de haut niveau que le CSP souhaite atteindre dans son réseau. Au lieu de gérer des configurations réseau complexes de bas niveau pendant les opérations du jour 0, comme indiqué ci-dessus, les équipes d'ingénieurs expriment les objectifs à l'aide d'intentions, et la logique qui sous-tend ces intentions les traduit en configuration réseau requise pour atteindre l'objectif visé.

Une fois les configurations appliquées au réseau, l’AN surveille en permanence les services déployés et adapte la configuration pour s’assurer que l’opération reste conforme aux intentions spécifiées. L’AN étend l’utilisation des intentions aux opérations de jour 2.

Voici quelques-uns des aspects pour lesquels les intentions pourraient potentiellement révolutionner les pratiques établies de l’ère des pré-intentions :

• Opérations du jour 0 :
  • Préparation de nouveaux services : tirez parti de l'IA générative pour traiter l'entrée en langage naturel et répondre aux exigences de service de manière autonome.
  • Introduction de nouveaux services : définissez de nouveaux services en langage naturel, tels que « fournir une solution de connectivité sur mesure pour une communication sécurisée au sein des établissements de santé » ou « permettre la communication des appareils IdO sur l’infrastructure intelligente de la ville », et exploitez l’IA générative pour générer automatiquement les actifs de service nécessaires.
  • Génération automatisée de pilotes de ressources spécifiques aux fournisseurs : utilisez l'IA générative pour créer des pilotes de ressources spécifiques aux fournisseurs, en fonction de la documentation du fournisseur.
• Opérations de jour 1 :
  • Simplification de la commande de service : permet aux clients de demander des services en utilisant le langage naturel. Cette approche intuitive permet une nouvelle expérience de commande de services, qui permet par exemple de combiner les offres du catalogue.
  • Contrôles de faisabilité : rationalise les contrôles de validation à mesure que les clients expriment leurs intentions en évaluant efficacement des facteurs critiques tels que la disponibilité des lignes de fibre critique. Il en résulte une charge réduite pour les ingénieurs réseau, une validation plus rapide des services et un déploiement plus agile et réactif.
• Opérations du jour 2 :
  • Assurance de service dynamique : permet aux réseaux de répondre intelligemment à l'évolution des conditions et des besoins des utilisateurs. Les politiques flexibles basées sur l’intention améliorent l’agilité, garantissant la fiabilité et la réactivité en temps réel des services réseau.

Il y a deux défis principaux à relever :

1. Comment exprimer et transmettre une intention ?
2. Comment exécuter une intention : à quoi ressemble le gestionnaire d’intention ?

TM Forum a lancé l’API TMF921 Intent-based Networking (mise en réseau basée sur l'intention), qui offre un cadre pour définir des intentions réseau de haut niveau. TM Forum définit l’intention comme suit : « L’intention est la spécification formelle de toutes les attentes, y compris les exigences, les objectifs et les contraintes donnés à un système technique ». Cependant, la partie spécification formelle soulève une préoccupation : les ingénieurs réseau devraient se familiariser avec ce langage formel pour exploiter pleinement le potentiel du concept d'intention. De plus, les intentions ayant une spécification formelle ne réduisent pas nécessairement le nombre de paramètres qui doivent être fournis avec elles. Cet aspect remet en question la rationalisation anticipée de la gestion du réseau que l’on associe généralement à IBN.

De plus, en formalisant la spécification de l'intention, le gestionnaire d'intentions, le composant central de l'IBN qui contient la logique d'interprétation des intentions, devient simplement un interprète déterministe du langage formel de l'intention. La question se pose de savoir comment faire évoluer le gestionnaire d’intention pour en faire un système autonome avec un mode de fonctionnement déclaratif, dans lequel les humains ne sont pas nécessaires pour anticiper chaque condition potentielle du réseau et fournir des instructions spécifiques pour sa résolution. Sinon, l'opération système ne peut pas passer de l'état automatisé à l'autonomie (TMF IG1230).

Dans les futurs articles de blog, nous aborderons plus en détail les défis et les opportunités liés à l’IBN et à l’AN. Vous souhaitez en savoir plus ?