Du Maillage de service au Service Communication Proxy SCP

  1. Introduction : du SOA aux micro-services

L’évolution majeure entre le réseau 4G-CUPS et le réseau 5G repose sur le choix d’une architecture orientée service (demandeur de services/fournisseur de services). Les fonctions réseaux sont des composantes logicielles (NF : Network Function) ré-utilisables, qui échangent des informations les unes vers les autres à travers une interface de service SBI (Service Based Interface).

Les services sont exposés en utilisant des protocoles standards (SOAP, Thrift, JSON) permettant d’imposer le format des messages échangés. Dans le cas de la 5G, le format des données est le JSON et le protocole d’échange se fait en HTTP2. Chaque service récupère, crée ou modifie une ressource. L’écriture se fait en utilisant les commandes POST ou PUT et la lecture en utilisant la commande WGET.

 

Une composante réseau logicielle (NF) est une unité autonome qui réalise une ou plusieurs tâches.

 

Chaque fonction est conçue pour réaliser une tâche ou des tâches précises comme récupérer des informations (exemple : l’identité du mobile lors de son attachement) ou exécuter une opération (exemple : mettre en œuvre un tunnel). Une fonction contient le code logiciel et les données nécessaire pour réaliser la liste des tâches associées à cette fonction.

 

Dans une architecture orientée services, les services communiquent entre eux via un système de couplage faible. Le couplage faible permet de réduire la dépendance entre les éléments du réseau, ce qui permet d’accélérer les mises à jour de fonctionnalité du réseau pour répondre à de multiples cas d’usages (Segments verticaux du marché).

Ainsi, par rapport aux entités fonctionnelles monolithiques du cœur de réseau 4G (cf. https://blogs.univ-poitiers.fr/f-launay/2021/02/26/architecture-sba-du-reseau-5g-microservices-et-soa/), l’architecture basée sur les services permet :

  • Une plus grande flexibilité et une innovation plus rapide : la ré-utilisation des fonctions accélère la mise en production d’une application car les développeurs utilisent des lignes de codes déjà exploitables
  • Une ouverture vers des nouveaux segments (agriculture, entreprise, …) par le biais d’exposition de service (API ouvertes)
  • Une maintenance et une évolution facile : les services étant autonomes (couplage lâche), il est plus facile de les modifier sans impacter le réseau, ou de créer des fonctions évoluées pour des solutions innovantes tout en maintenant les précédentes versions.

Le concept SOA est un des pilier du Cloud Computing. Le Cloud Computing porte l’architecture SOA à une échelle plus importante (en comparaison, le Cloud Computing est au WAN ce que le SOA est au LAN).

Plus précisément, le Cloud Computing exploite des composantes logicielles pouvant communiquer entre eux sans états (stateless) nommées micro-services. Le langage de programmation d’un micro-service est indépendant des autres micro-services.

L’usage des micro-services est grandement facilité par les techniques de conteneurisation. Les micro-services faiblement couplés sont déployés dans des conteneurs et connectés via des API ou via un réseau de services maillé (MESH Service) pour le routage des messages.

Lorsque le nombre de micro-service augmente, la gestion des communications entre chaque micro-service se complexifie. Le premier rôle du maillage de service (MESH Service) est de gérer l’échange très important des données entre les micro-services.

L’architecte 5G est une architecture basée sur le service (SBA : Service Base Architecture). L’architecture SBA fournit une architecture orientée services (SOA) pour héberger des composants de plan de contrôle distincts de différents fournisseurs avec des cycles de développement disparates qui pourraient facilement inter fonctionner et interagir pour fournir un sous-système 5G complet ou une offre de services.

Avec l’architecture SOA et SBA, de nombreuses fonctions réseaux sont lancées, avec un nombre d’instances permettant de prendre en charge le trafic de signalisation. A la différence du SOA, l’architecture SBA introduit la fonction NRF qui est un annuaire listant les instances déployées : chaque instance d’une fonction de réseau annonce sa disponibilité à la fonction NRF avant d’initier une connexion est-ouest et participer à la livraison d’une application ou d’un service plus important.

Figure 1 : L’architecture SBA et la fonction de découverte NRF

Toutefois, à l’instar du SOA, la difficulté est la répartition de charge de trafic de signalisation entre les fonctions.

 

2. Le maillage de service – Service MESH

Un service MESH a pour objectif de contrôler l’échange des données de services partagées entre les instances logicielles (micro-service ou fonctions NF).

Un micro-service est conçu pour échanger des données au niveau applicatif. Le service MESH introduit une couche d’infrastructure dédiée en intégrant dans l’application des PROXYS nommés SIDECAR (imaginez le sidecar d’une moto pour prendre en charge non pas une personne mais un service) afin d’optimiser l’échange de données.

Avec le maillage de service, les requêtes s’effectuent à travers des PROXYS implémentés en sortie des micro-services.

Figure 2 : Modèle SideCar [1]

Sans Sidecar, la composante logicielle devait compiler une bibliothèque de communication spécifique au langage pour gérer la découverte de services, les routages et les exigences de communication non fonctionnelles au niveau applicatif (couche 7).

Figure 3 : De kubernetes au Maillage de services [2]

Le maillage de service permet de plus de réaliser de la surveillance réseau en fournissant des statistiques sur les performances des communications entre les services. Ces performances permettent ainsi de mettre en œuvre des fonctionnalités d’équilibrage de charge, de modification de route (exemple : la réponse d’une instance à un service met trop de temps par rapport à une autre instance pour le même service, le proxy va donc choisir cette dernière instance).

La solution de maillage de service OpenSource ISTIO [3,4] permet ainsi :

  • La gestion de trafic par une configuration des règles de services entre les micro-services
  • La sécurité en introduisant des fonctions d’authentification, d’autorisation (OAuth2) et de chiffrement des communications
  • Observabilité

Figure 4 : La journalisation des messages

3. SCP : Service Communication Proxy

Le service side-car ne fait pas nécessairement partie de l’application, mais il est connecté à celle-ci. Il est présent partout où l’application parente est présente.

Figure 5 : Le principe du maillage de service [5]

Le service n’a pas connaissance du réseau, mais ne connait que le proxy sur lequel il est connecté.

Le proxy réalisant les fonctions suivantes :

  • La découverte de services
  • Le routage
  • L’équilibrage de charges
  • L’authentification et l’autorisation
  • L’observabilité (statistique, log, traces)
  • Le bon fonctionnement (et éventuellement le transfert via une réponse 3XX ou une erreur de service 5XX)

Le standard 3GPP a introduit le proxy SCP dans la R16 [6]. De ce fait, l’architecture SBA n’a pas besoin du proxy SCP dans son principe de fonctionnement. Mais dans le cas de fonction NF multi-distribués, le SCP va résoudre les problématiques de trafic de signalisation en fournissant un point d’entrée unique pour un groupe de fonctions réseau (qui sont enregistrées dans la fonction NRF). Cela permet au SCP de devenir le point de découverte délégué dans un centre de données, déchargeant le NRF des nombreux maillages de services distribués. Les règles de routage du SCP peuvent s’appuyer sur une ressource, un numéro de téléphone ou un identifiant IMSI. Dans le monde des Télécom, par comparaison (et abus de langage), le SCP joue un rôle similaire au proxy et routeur DIAMETER. Il s’agit d’une simple comparaison, le SCP permet l’échange de signalisation dans le réseau d’un opérateur, les agents DIAMETER DRA permettaient de mettre en relation tous les HSS/MME inter-opérateurs (et auparavant, le routage de la signalisation était géré par le réseau SS7 et les points sémaphores STP).

Figure 6 : SS7 -> DIAMETER -> HTTP2 – SCP

Le SCP est un sidecar centralisé, il a pour rôle de gérer la communication de services à services s’il est impliqué. En ce sens le SCP est attaché à chaque NF. Le rôle du SCP inclut l’interfonctionnement entre NF, la segmentation des services, le contrôle d’accès centré sur les services et l’équilibrage de charge. Le SCP apporte donc une abstraction réseau ce qui permet aux développeurs d’applications d’être indépendants de l’infrastructure.

Le SCP n’est pas une fonction réseau, il n’expose pas de service contrairement aux NF. Deux fonctions NF peuvent s’échanger des services directement ou indirectement en passant par le proxy SCP.

Figure 7 : Communication directe/indirecte de deux NF [6 – Fig 7.1.1.1]

Les rôles du SCP sont :

  • D’apporter une fiabilité des services NF.

[6] 5.21.3.4 Reliability of NF Services Si une défaillance de l’instance de service NF est détectée ou notifiée par la NRF (exemple plus disponible), le consommateur de service NF ou SCP sélectionne un autre NF Service Instance de service du même ensemble de services NF dans l’instance NF.

  • De sélectionner la fonction NF adéquate : une fonction NF (consommateur de service) interroge le SCP en transmettant les attributs souhaités de la fonction NF (producteur de service). A partir de ces informations suivantes permettent au SCP de trouver la fonction SMF (DNN, capacité UE, localisation)
  • Le transfert et le routage de message de signalisation
  • Les services de sécurités (ex : autorisation qu’un consommateur de service puisse accéder à l’API d’un producteur de service)
  • L’équilibrage de charge et contrôle de surcharge de trafic
  • Surveillance du réseau
  • Optionnellement interagit avec la base de donnée unifiée UDR pour la résolution de nom (IMSI, IMPI/IMPU, Identité UDM/HSS

 

Figure 8 : Implémentation du maillage de service via le SCP

Le maillage de service et le proxy SCP ajoute de la latence. Dans le cas du service MESH, au moins deux sauts de réseau supplémentaires sont ajoutés lorsqu’un service communique avec un autre service (le premier provient du proxy qui gère la connexion sortante de la source et le second provient du proxy qui gère la connexion entrante de la destination).

Pour l’architecture SBA, la communication entre service peut être directe ou indirecte, c’est-à-dire en passant par le SCP. Quoiqu’il en soit, la latence est sur le plan de contrôle et non le plan de transport.

 

Pour en savoir plus :

  • Linkerd, Istio, Consul, Kuma et Maesh.
  • https://www.infoq.com/fr/articles/service-mesh-ultimate-guide/
  • https://carrier.huawei.com/~/media/cnbgv2/download/products/core/strategy-analytics-5g-signaling-en.pdf

Références :

[1] https://docs.microsoft.com/fr-FR/azure/architecture/patterns/sidecarTS23.501 – System architecture

[2] https://jimmysong.io/en/blog/service-mesh-the-microservices-in-post-kubernetes-era/

[3] https://istio.io/

[4]  https://www.redhat.com/fr/topics/microservices/what-is-istio

[5] https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc

[6]  TS 23.501(3GPP  version 16.6.0)  System Architecture for the 5G System.

[7] https://www.metaswitch.com/blog/the-service-communication-proxy-5g-caught-up-in-a-service-mesh