Réseaux déchaînés : la transition vers des opérations autonomes basées sur l'intention – IBM Blog

L’industrie des télécommunications, pierre angulaire de la connectivité mondiale, connaît depuis un certain temps une renaissance technologique, portée par des innovations telles que la 5G, l’IoT, le cloud computing et l’IA. En conséquence, les réseaux sont devenus de plus en plus difficiles à gérer. Il existe un besoin d'automatisation pour gérer les tâches de routine, surveiller l'état du réseau et répondre aux problèmes en temps réel. Cependant, les compétences existantes au sein des fournisseurs de services de communication (CSP) peuvent ne pas correspondre aux exigences changeantes de ce paysage dynamique. Pour réussir à l'ère moderne, les CSP ont besoin d'équipes polyvalentes, comprenant des data scientists pour l'interprétation et les opérations des données, des développeurs de logiciels pour l'automatisation via les interfaces de programmation d'application (API) des fournisseurs et des ingénieurs d'assurance de services pour concevoir des boucles fermées afin de garantir la fiabilité du service.

Si les CSP comblent le fossé en constituant des équipes possédant une expérience diversifiée, ils bénéficient également simultanément 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 en sommes à un point où les modèles fondamentaux peuvent générer du code formel basé sur des descriptions en langage naturel des tâches. Cela a donné une nouvelle perspective au concept de mise en réseau basée sur l'intention (IBN), où les administrateurs humains expriment des objectifs réseau de haut niveau dans un langage naturel appelé « intentions » et où ces intentions humaines sont automatiquement traduites en politiques et configurations réseau. IBN a le potentiel d’améliorer la gestion des réseaux et pourrait changer la donne en comblant le manque de talents au sein des sociétés de télécommunications. En allant plus loin, réseaux autonomes (AN) promettent d'utiliser les intentions comme entrées pour s'auto-configurer, s'auto-optimiser et s'auto-réparer de manière autonome à mesure que leurs conditions évoluent.

Bien que nous puissions envisager un avenir brillant pour l'IBN et l'AN, des préoccupations persistent quant à leur faisabilité et à leurs applications programmatiques, notamment l'expression des intentions, la traduction précise en configuration réseau, la transparence et la complexité du système, entre autres. Dans ce blog, nous explorons les domaines dans lesquels leur application pratique présente un potentiel et analysons les défis qu'ils pourraient rencontrer en cours de route.

Un cas motivant : introduire de nouveaux services sans intentions

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

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 la fourniture de services, la fourniture automatisée et les tests automatisés, (2) d'un système d'assurance avec un 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 basée sur les données. dans le contexte d'un contrôle en boucle fermée et (3) un gestionnaire de politiques qui pilote le comportement du réseau à l'aide de politiques prédéfinies, garantissant ainsi l'alignement avec les politiques plus larges du CSP. En un mot, les opérations automatisées s'articulent autour d'un couplage étroit de services avec leurs descripteurs de services TOSCA, configurations, politiques et flux de travail impératifs conçus par l'homme, dans lesquels l'intelligence et la prise de décision sont ajoutées par les concepteurs de services pendant la période de conception. Les concepteurs de services doivent prévoir de manière proactive un large éventail de conditions pouvant survenir sur le réseau et fournir des instructions détaillées sur la manière dont elles doivent être traitées : une expérience sans contact est obtenue tant que les conditions futures ont été prévues et qu'il existe des politiques pour les gérer.

Nous utilisons les termes Jour 0, Jour 1 et Jour 2 pour différentes étapes du cycle de vie du service, à savoir conception de service, instanciation de service ainsi que le garantie de service, Respectivement.

• La conception de services comprend le développement de divers actifs de service, comme illustré dans la figure 1. Il s'agit de la tâche de l'équipe de conception de services, qui doit comprendre les opérations des jours 1 et 2 du service et produire les flux de travail et les scripts requis. Les lignes rouges de la figure 2 représentent le processus de fourniture d'un nouveau service, garantissant que le service peut désormais être commandé.

• L'instanciation du service se produit lorsque la commande de service arrive, suite à une demande de l'abonné. Aujourd'hui, dans les CSP, l'ordre de service arrive généralement via l'interface TMF 641 depuis le gestionnaire d'ordres de service (SOM). Lorsque l'orchestrateur de services reçoit la commande de service, il garantit que les flux de travail 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 exécutés. Nous montrons l'instanciation du service dans la figure 2 en lignes vertes.

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

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

Que sont les intentions ?

Dans IBN, les intentions font référence aux objectifs de haut niveau que CSP souhaite atteindre dans son réseau. Au lieu de gérer des configurations de réseau complexes de bas niveau pendant les opérations du jour 0, comme indiqué ci-dessus, les équipes d'ingénierie expriment les objectifs avec des intentions et la logique qui sous-tend les intentions les traduit en configuration réseau requise qui répond à l'objectif de l'intention.

Après l'application des configurations au réseau, l'AN surveille ensuite en permanence les services déployés et adapte la configuration pour garantir que l'opération reste conforme aux intentions spécifiées. L'AN étend l'utilisation des intentions aux opérations du jour 2.

Perspectives d’IBN et d’AN

Ensuite, nous présentons certains des aspects dans lesquels les intentions pourraient potentiellement révolutionner les pratiques établies de l’ère pré-intention :

• Opérations du jour 0 :
  • Préparation aux nouveaux services – Tirez parti de l’IA générative pour traiter la saisie en langage naturel afin de compléter de manière autonome les exigences de service.
  • Introduction de nouveaux services – Définir de nouveaux services en utilisant le 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 IoT à travers l’infrastructure des villes intelligentes » et tirer parti de l’IA générative pour la génération automatique des actifs de service nécessaires.
  • Génération automatisée de pilotes de ressources spécifiques au fournisseur– Utiliser l'IA générative pour créer des pilotes de ressources spécifiques au fournisseur, basés sur la documentation du fournisseur.
• Opérations du jour 1 :
  • Simplification de la commande de service – Permet aux clients de demander des services en langage naturel. Cette approche conviviale permet une nouvelle expérience de commande de services, telle que le mélange et la mise en correspondance des offres du catalogue.
  • Contrôles de faisabilité – Rationalise les contrôles de validation à mesure que les clients expriment leurs intentions en évaluant efficacement les facteurs critiques tels que la disponibilité des lignes de fibre optique. Le résultat est une charge réduite pour les ingénieurs réseau, une validation des services plus rapide 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 aux conditions changeantes et aux besoins des utilisateurs. Des 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.

Les défis avec IBN et AN

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 présenté l'API de mise en réseau basée sur l'intention TMF921, offrant un cadre structuré pour définir des intentions de 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 imposées à un système technique.». Cependant, la partie spécification formelle introduit une préoccupation : les ingénieurs réseau devraient se familiariser avec ce langage formel pour exploiter tout le potentiel du concept d'intention. De plus, les intentions avec 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 attendue de la gestion du réseau que l’on associerait généralement à l’IBN.

De plus, en formalisant la spécification de l'intention, le gestionnaire d'intention, le composant central de l'IBN qui contient la logique de l'interprétation de l'intention, 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'intentions vers un système autonome avec un mode de fonctionnement déclaratif dans lequel les humains ne sont pas tenus d'anticiper chaque condition potentielle du réseau et de fournir des instructions spécifiques pour sa résolution. Sinon, le fonctionnement du système ne peut pas réussir la transition d'automatique à autonome (TMF IG1230).

Dans les prochains blogs, nous aborderons plus en détail les défis et les opportunités d’IBN et d’AN. Vous voulez en savoir plus ? Contactez-nous à maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com ainsi que le tmtattis@ae.ibm.com.

Transformez-vous pour l’avenir
avec les télécommunications