EP4792557A1 - Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants - Google Patents

Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants

Info

Publication number
EP4792557A1
EP4792557A1 EP24789877.8A EP24789877A EP4792557A1 EP 4792557 A1 EP4792557 A1 EP 4792557A1 EP 24789877 A EP24789877 A EP 24789877A EP 4792557 A1 EP4792557 A1 EP 4792557A1
Authority
EP
European Patent Office
Prior art keywords
equipment
network
network slice
verification
verification message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24789877.8A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4792557A1 publication Critical patent/EP4792557A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement via au moins une tranche réseau, comprenant : - la réception (412), via au moins un canal sécurisé (50) entre ledit équipement et au moins un serveur de contrôle (45), d'informations relatives à au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement (41) via au moins une tranche réseau à exécuter, - la vérification (414) de l'exécution de ladite au moins une action en utilisant lesdites informations.

Description

DESCRIPTION
TITRE : Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants.
1. Domaine technique
Le domaine de l'invention est celui des communications au sein d'au moins un réseau de communication, et notamment le domaine des services IP à valeur ajoutée.
Plus précisément, l'invention concerne l'acheminement de données à destination d'un équipement qui utilise les ressources de tranches réseau (« network slice » ou « slice » en anglais).
En particulier, l'invention propose une solution pour vérifier l'accessibilité, encore appelée joignabilité, d'un équipement pour le trafic retour (c'est-à-dire le trafic à destination de l'équipement) via au moins une tranche réseau ou un type de tranche réseau.
2. Art antérieur
Une tranche réseau peut être définie comme une partition logique ou physique du réseau, telle qu'un réseau privé virtuel (RPV, ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure fixe, mobile, ou une combinaison des deux.
Les caractéristiques d'une tranche réseau sont principalement exprimées en termes de capacité (bande passante) et de qualité de service (par exemple latence ou temps de transit unidirectionnel), voire de sécurité (par exemple préservation de la confidentialité des informations transmises au sein du RPV moyennant l'utilisation de techniques de chiffrement) et de fonctions service (« Service Functions (SF) »).
A titre illustratif, l'organisme 3GPP a défini différents types de tranches réseau selon leurs caractéristiques, par exemple : un premier type de tranches réseau permettant d'offrir un service mobile large bande amélioré (« enhanced Mobile BroadBand » ou eMBB en anglais) ; un deuxième type de tranches réseau permettant d'offrir un service dans le cadre d'un déploiement (massif) de l'Internet des Objets (« massive Internet of Things » ou mloT en anglais) ; et un troisième type de tranches réseau permettant d'offrir un service de communication ultra fiable et à faible latence (« Ultra Reliable Low Latency Communications ou URLLC en anglais).
Le choix de concevoir et de déployer un type de tranche réseau est conditionné par la nature du trafic caractéristique des applications ou services utilisés ou souscrits par un utilisateur. Par exemple, un service dit « immersif » qui exploite des techniques de réalité augmentée ou virtuelle est généralement très exigeant en termes de latence et de fiabilité des échanges de données : l'utilisation de tranches de type URLLC est donc privilégiée pour un service immersif de ce type lorsqu'il est déployé sur une infrastructure réseau mobile 5G.
Les caractéristiques d'une tranche réseau sont par exemple présentées dans le document « A Framework for Network Slices in Networks Built from IETF Technologies » de A. Farrel et al., version 25 publiée le 14 septembre 2023.
Un exemple d'utilisation de tranches réseau déployées dans une infrastructure mobile 5G est présenté dans le document « A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies » de K. G. Szarkowicz et al., version 9 publiée le 23 mai 2023.
Classiquement, le trafic susceptible d'être acheminé au sein d'une tranche réseau fait l'objet d'une habilitation (aussi appelée contrôle d'accès) à emprunter le ou les chemins établis au sein de ladite tranche. Une telle habilitation repose typiquement sur l'application de règles de classification de trafic. Ces règles sont en général appliquées par un nœud situé en périphérie du réseau au sein duquel des tranches réseau ont été déployées. Un tel nœud de périphérie est généralement déployé en frontal des accès clients (il s'agit alors par exemple d'un routeur d'accès) ou bien utilisé pour connecter un réseau à d'autres réseaux voisins (il s'agit alors par exemple d'un routeur de bordure ou nœud de périphérie). Par exemple, un tel nœud de périphérie peut être situé à l'interface de raccordement d'une passerelle qui permet d'accéder au réseau Internet. Cette passerelle est désignée « Packet Gateway » pour les générations (4G, 5G) les plus récentes des réseaux mobiles. Dans ce cas, la fonction de classification de trafic peut être localisée à l'interface de raccordement d'une « Packet Gateway » au réseau Internet. Un nœud de périphérie peut également se situer à l'interface de raccordement d'un équipement mobile (ou « User Equipment » ou UE en anglais) au réseau d'accès radio (ou « Radio Access Network » ou RAN en anglais), de façon notamment à optimiser l'usage des ressources radio en fonction du type de la tranche réseau et du profil du trafic qu'elle est susceptible d'acheminer. Un profil de trafic est l'ensemble des caractéristiques propres au trafic. Ces caractéristiques peuvent refléter la sensibilité des applications à la latence, au délai de transit ou à la perte de paquets, mais également des pratiques d'usage, par exemple un trafic qui ne serait généré que sur une période donnée (tel qu'un trafic de gestion lié à l'exécution d'une opération de maintenance d'un équipement programmée pendant la nuit).
En résumé, les règles de classification et de contrôle d'admission de trafic sont appliquées à la périphérie du réseau, dans les nœuds de périphérie (routeur d'accès, routeur de bordure par exemple). L'application des règles de classification de trafic peut être complexe, car le niveau de granularité associé à l'ingénierie et au déploiement d'une tranche réseau peut être macroscopique (par exemple une tranche réseau déployée pour acheminer le trafic à destination de l'Internet), ou bien microscopique (par exemple une tranche réseau déployée pour le trafic applicatif échangé entre deux équipements mobiles).
Cette granularité génère une complexité globale de l'ingénierie des tranches réseau, par exemple une difficulté à optimiser l'usage des ressources mises en œuvre par une tranche réseau, par un ensemble de tranches réseau, ou par toutes les tranches réseau, ou une difficulté à garantir strictement l'isolation du trafic acheminé au sein d'une tranche réseau, ou encore une difficulté à garantir strictement le niveau de qualité ou de sécurité associé à une tranche réseau, voire le niveau de disponibilité et de résilience d'une tranche réseau donnée, etc.
En particulier, la complexité de la configuration et de l'application de règles de classification de trafic associées à la mise en place d'une tranche réseau donnée évolue avec la diversité des trafics, la richesse de l'organisation de la structure qui exploite la tranche réseau (par exemple un service de comptabilité, un service de R&D, un service de production) ou encore le mode d'usage de la tranche réseau (par exemple, gestion des surcharges de trafic lors des heures chargées, principes de répartition de la charge de trafic). Cette complexité peut notamment être aggravée par l'évolution des règles de classification de trafic au cours du temps (par exemple, dans le contexte du déploiement d'une tranche réseau pour la retransmission d'un événement sportif ou culturel, les règles de classification de trafic peuvent évoluer avec le nombre et le profil des utilisateurs de la tranche réseau).
En particulier, il existe des techniques permettant de vérifier la joignabilité (ou accessibilité) d'un équipement distant depuis un équipement connecté à un réseau, mais ces techniques ne garantissent pas que la requête et la réponse sont acheminées via une même tranche réseau. Par exemple, une requête ICMP (« Internet Control Message Protocol ») de type « Echo Request » (généralement appelée « Ping ») peut être envoyée par un équipement pour vérifier s'il peut se connecter à un site distant. En revanche, une telle requête ne permet pas de vérifier la joignabilité en sens retour, notamment si le chemin emprunté par les données en provenance de l'équipement (trafic « aller ») diffère du chemin emprunté par les données à destination de l'équipement (trafic « retour »). Une telle requête ICMP ne permet donc pas de déterminer le chemin emprunté par la réponse (ICMP « Echo Reply »).
A ce titre, les règles de classification du trafic « aller » qui permettent notamment d'emprunter un chemin au sein d'une tranche réseau, sont inadaptées au traitement du trafic « retour », qui est susceptible d'emprunter un chemin différent si le routage est asymétrique. En particulier, le trafic retour peut être acheminé au sein de la même tranche réseau que celle utilisée pour acheminer le trafic « aller », ou au sein d'une tranche réseau différente mais à laquelle l'équipement serait également connecté.
Le même problème concerne d'autres types de messages de vérification de connectivité (requête I0AM - en anglais « In-band Operations, Administration, and Maintenance », LSP Ping - en anglais « Label Switched Path », etc.).
De même, les règles de classification de trafic peuvent s'avérer inefficaces si le chemin emprunté par les données traverse un réseau qui ne comporte pas de tranches réseau, ou qui ne supporte pas un type spécifique de tranche réseau choisi pour acheminer les données.
Il existe donc un besoin pour une nouvelle technique contrôlée par un équipement et cherchant à vérifier la joignabilité dudit équipement depuis un site distant, via un ou plusieurs réseaux qui supportent des tranches réseau, pour l'acheminement du trafic à destination de l'équipement.
3. Exposé de l'invention
L'invention propose une solution cherchant à répondre à ce besoin, sous la forme d'un procédé de vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement via au moins une tranche réseau, comprenant :
- la réception, via au moins un canal sécurisé entre l'équipement et au moins un serveur de contrôle, d'informations relatives à au moins un message de vérification correspondant à au moins une action de « vérification de l'accessibilité dudit équipement via au moins une tranche réseau » à exécuter,
- la vérification de l'exécution de ladite au moins une action en utilisant lesdites informations.
Un tel procédé peut notamment être mis en œuvre par l'équipement dont on souhaite vérifier la joignabilité pour l'acheminement du trafic retour (i.e. à destination de l'équipement) via une ou plusieurs tranches réseau.
En particulier, selon ce procédé, l'équipement reçoit des informations relatives à au moins un message de vérification en provenance d'un serveur de contrôle (en anglais « Probing Server »), via un canal sécurisé. Un tel serveur de contrôle peut notamment générer au moins un message de vérification, sur la base d'instructions ou de consignes transmises par l'équipement vers le serveur de contrôle comme exposé ci-après, ou bien connues du serveur de contrôle. En particulier, un tel message de vérification correspond à au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter.
La réception de ces informations permet à l'équipement de savoir qu'un processus de vérification de sa joignabilité est lancé. Ainsi, l'équipement peut vérifier l'exécution de ladite au moins une action en utilisant lesdites informations. Par exemple, si l'équipement reçoit via au moins une tranche réseau un message de vérification correspondant à au moins une action à exécuter, il peut vérifier si le message de vérification reçu correspond aux informations relatives au message de vérification préalablement reçues via le canal sécurisé. Si tel est le cas, l'accessibilité de l'équipement pour l'acheminement de données vers l'équipement via ladite au moins une tranche réseau est confirmée.
A l'inverse, si l'équipement ne reçoit pas de message de vérification pour tout ou partie des tranches réseau sujettes à la vérification en cours, ou reçoit un message de vérification via au moins une tranche réseau qui ne correspond pas aux informations relatives au message de vérification préalablement reçues via le canal sécurisé, l'accessibilité de l'équipement pour l'acheminement de données vers l'équipement via au moins une tranche réseau sujette à la vérification en cours n'est pas confirmée.
Comme indiqué ci-dessus, selon un mode de réalisation particulier, le procédé comprend la transmission préalable par ledit équipement, via ledit canal sécurisé, d'instructions comprenant au moins une action de « vérification de l'accessibilité dudit équipement via au moins une tranche réseau » à exécuter et éventuellement au moins l'une des informations suivantes :
- des informations d'identification de tranche réseau permettant d'identifier au moins une tranche réseau ou un type de tranche réseau à tester pour l'acheminement de données à destination dudit équipement,
- des informations d'identification d'un segment réseau permettant d'identifier au moins une entité relais à solliciter pour tester l'acheminement de données à destination dudit équipement.
En particulier, si aucune information d'identification de tranches réseau n'est disponible, le serveur de contrôle peut tester toutes les tranches réseau auxquelles l'équipement est connecté ou auxquelles il est habilité à se connecter, en transmettant au moins un message de vérification via chacune de ces tranches réseau.
Dans un mode de réalisation particulier, les informations d'identification d'un segment réseau permettent par exemple de tester la joignabilité de l'équipement uniquement sur un réseau local, en transmettant au moins un message de vérification depuis au moins une entité relais connectée au réseau local. En variante, elles permettent de tester la joignabilité de l'équipement sur un réseau étendu, correspondant par exemple à un réseau dorsal régional, en transmettant au moins un message de vérification depuis au moins une entité relais connectée au réseau étendu. Les informations d'identification d'un segment réseau permettent encore de tester la joignabilité de l'équipement selon des réseaux mettant en œuvre des techniques de communication numérique différentes (Wi-Fi® ou 5G par exemple). Une ou plusieurs entités relais peuvent être sélectionnées pour émettre les messages de vérification, qui peuvent être émis concomitamment ou séquentiellement par ces entités relais.
Dans un mode de réalisation particulier, le procédé comprend une étape préalable de sélection dudit au moins un serveur de contrôle tenant compte d'une contrainte sur une entité relais destinée à émettre ledit au moins un message de vérification.
Par exemple, l'équipement sélectionne un serveur de contrôle connecté au même réseau que l'entité relais destinée à émettre ledit au moins un message de vérification. Ainsi, si l'équipement est connecté à un réseau local, on peut sélectionner au moins un serveur de contrôle interne au réseau local pour tester la joignabilité de l'équipement sur le réseau local. Pour tester la joignabilité de l'équipement sur un réseau étendu, on peut sélectionner au moins un serveur de contrôle externe au réseau local.
On note que l'équipement n'a pas à connaître directement l'identité de l'entité relais. Par exemple, l'équipement utilise des informations provenant du ou des serveurs de contrôle pour sélectionner un serveur de contrôle adéquat.
Un serveur de contrôle peut notamment indiquer le réseau auquel une entité relais est connectée en diffusant une information de type identifiant de système autonome (« Autonomous System Number »), nom de domaine du réseau, etc. L'équipement peut appliquer des filtres selon des consignes lui permettant de sélectionner un serveur de contrôle adéquat. Ces filtres sont appliqués par l'équipement globalement ou par requête. De telles consignes peuvent être communiquées en indiquant des paramètres qui caractérisent la portée des vérifications, par exemple « test ocal », « test_peer » (test depuis l'un ou l'ensemble des réseaux connectés au réseau local), « test_asn » (liste d'identifiants de systèmes autonomes), etc.
Dans un mode de réalisation particulier, ledit procédé comprend la réception dudit au moins un message de vérification correspondant à ladite au moins une action à exécuter et ladite vérification met en œuvre une comparaison dudit au moins un message de vérification reçu avec lesdites informations relatives audit au moins un message de vérification correspondantes.
Par exemple, une corrélation peut être effectuée entre le contenu d'un message de vérification reçu par l'équipement et les informations relatives à ce message de vérification préalablement reçues par l'équipement depuis ledit serveur de contrôle.
Dans un mode de réalisation particulier, le procédé comprend la transmission par ledit équipement d'une réponse audit au moins un message de vérification. Une telle réponse peut notamment être émise par l'équipement lorsque le message de vérification est une requête de vérification. Une telle réponse peut être transmise au serveur de contrôle émetteur du message de vérification, ou à l'entité relais émettrice du message de vérification. Dans un mode de réalisation particulier, au cours d'une phase de découverte ou lors de la phase d'autorisation, des informations peuvent être échangées entre l'équipement et au moins un serveur de contrôle.
Par exemple, le procédé comprend la transmission, via le canal sécurisé, d'au moins une information descriptive dudit équipement appartenant au groupe comprenant :
- au moins un type de tranche réseau supporté par ledit équipement,
- au moins un identifiant d'une tranche réseau supportée par ledit équipement,
- au moins un identifiant d'un réseau auquel ledit équipement est connecté.
Le procédé peut comprendre, également ou en variante, la réception, via ledit canal sécurisé, d'au moins une information descriptive dudit serveur de contrôle appartenant au groupe comprenant :
- au moins un type de tranche réseau supporté par ledit serveur de contrôle,
- au moins un identifiant d'une tranche réseau supportée par ledit serveur de contrôle,
- au moins un identifiant d'un réseau auquel ledit serveur de contrôle est connecté,
- au moins un indicateur spécifiant si ledit serveur de contrôle supporte un mode collaboratif avec le réseau auquel est connecté l'équipement,
- une liste d'identifiants de domaines réseau avec lesquels le serveur de contrôle supporte le mode collaboratif, et le stockage de ladite au moins une information descriptive dudit serveur de contrôle.
Dans un autre mode de réalisation, l'invention concerne un équipement adapté à mettre en œuvre le procédé de vérification de l'accessibilité décrit précédemment. Un tel équipement pourra bien sûr présenter les différentes caractéristiques relatives au procédé de vérification de l'accessibilité selon l'invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cet équipement sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
Par exemple, un tel équipement est un équipement utilisateur, un CPE (« Customer Premises Equipment » en anglais), une instance de service, un routeur, un serveur, etc.
L'invention concerne également un procédé de gestion de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, mis en œuvre par un serveur de contrôle, comprenant :
- l'obtention d'instructions comprenant au moins une action de « vérification de l'accessibilité dudit équipement via au moins une tranche réseau » à exécuter,
- la génération d'au moins un message de vérification à partir desdites instructions, - la transmission audit équipement, via un canal sécurisé entre l'équipement et ledit serveur de contrôle, d'informations relatives audit au moins un message de vérification.
Comme indiqué précédemment, de telles instructions peuvent être transmises par l'équipement, ou connues au préalable du serveur de contrôle.
En particulier, ces instructions sont utilisées pour construire au moins un message de vérification. Des messages de vérification peuvent ensuite être émis par le serveur de contrôle à destination de l'équipement, et/ou par au moins une entité relais à destination de l'équipement. En particulier, des messages de vérification distincts peuvent être générés pour une transmission par une même entité relais ou des entités relais distinctes.
Selon un premier mode de réalisation (ne reposant ni sur la participation d'un contrôleur réseau, ni sur la participation d'une entité relais), le procédé comprend la transmission, vers l'équipement, dudit au moins un message de vérification via au moins une tranche réseau ou un type de tranche réseau à tester.
Le serveur de contrôle peut ainsi transmettre directement un ou plusieurs messages de vérification à destination de l'équipement (par exemple un message de vérification par tranche réseau à tester).
En particulier, l'équipement peut répondre au message de vérification qu'il reçoit du serveur de contrôle, notamment si le message de vérification est une requête de vérification.
Dans ce cas, le procédé comprend :
- la réception, en provenance dudit équipement, d'une réponse audit au moins un message de vérification, et
- la transmission audit équipement, via le canal sécurisé entre ledit équipement et ledit serveur de contrôle, d'informations relatives à ladite réponse.
Notamment, si le serveur de contrôle transmet un message d'erreur à l'équipement, celui-ci peut relancer la procédure de vérification pour tester sa joignabilité via une autre tranche réseau par exemple.
Selon un deuxième mode de réalisation (ne reposant pas sur la participation d'un contrôleur réseau, mais reposant sur la participation d'au moins une entité relais), le procédé comprend :
- la sélection d'au moins une entité relais à partir des instructions,
- la transmission à ladite au moins une entité relais dudit au moins un message de vérification (ou éventuellement d'informations relatives audit au moins un message de vérification).
Le serveur de contrôle peut ainsi transmettre un ou plusieurs messages de vérification à destination de l'équipement par l'intermédiaire d'au moins une entité relais (par exemple pour tester la joignabilité de l'équipement sur un segment réseau entre l'entité relais et l'équipement). En particulier, l'équipement peut répondre au message de vérification qu'il reçoit d'une entité relais, notamment si le message de vérification est une requête de vérification.
Dans ce cas, le procédé comprend :
- la réception, en provenance de ladite au moins une entité relais, d'une réponse à au moins un message de vérification émis par ladite moins une entité relais, et
- la transmission audit équipement, via ledit canal sécurisé entre ledit équipement et ledit serveur de contrôle, d'informations relatives à ladite réponse.
A contrario, en l'absence de réception par l'entité relais d'une réponse de l'équipement à un message de vérification, ou sur réception par l'entité relais d'un code d'erreur suite à l'envoi d'un message de vérification, l'entité relais peut transmettre un message d'erreur au serveur de contrôle. Celui-ci peut alors relayer ledit message d'erreur vers l'équipement, et ce dernier peut relancer la procédure de vérification pour tester sa joignabilité via une autre entité relais par exemple.
Selon un troisième mode de réalisation (reposant sur la participation d'au moins un contrôleur réseau et d'au moins une entité relais), le procédé comprend :
- la sélection d'au moins une entité relais à partir desdites instructions,
- la sélection d'au moins un contrôleur réseau, tenant compte d'une contrainte sur ladite au moins une entité relais sélectionnée,
- la transmission, audit au moins un contrôleur réseau, dudit au moins un message de vérification (ou éventuellement d'informations relatives audit au moins un message de vérification).
Par exemple, la contrainte sur ladite au moins une entité relais peut être déduite des instructions de vérification.
Le serveur de contrôle peut ainsi transmettre un ou plusieurs messages de vérification à destination de l'équipement par l'intermédiaire d'au moins un contrôleur réseau et d'au moins une entité relais (par exemple pour tester la joignabilité de l'équipement sur un segment réseau entre l'entité relais et l'équipement).
En particulier, l'équipement peut répondre au message de vérification qu'il reçoit d'une entité relais, notamment si le message de vérification est une requête de vérification.
Dans ce cas, le procédé comprend :
- la réception, en provenance dudit au moins un contrôleur réseau, d'une réponse à au moins un message de vérification émis par ladite moins une entité relais, et
- la transmission audit équipement, via ledit canal sécurisé entre ledit équipement et ledit serveur de contrôle, d'informations relatives à ladite réponse. Dans un autre mode de réalisation, l'invention concerne un serveur de contrôle (« Probing Server ») apte à mettre en œuvre le procédé de gestion de l'accessibilité décrit précédemment. Un tel serveur de contrôle pourra bien sûr présenter les différentes caractéristiques relatives au procédé de gestion de l'accessibilité selon l'invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce serveur de contrôle sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
L'invention concerne par ailleurs un procédé de contrôle de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, mis en œuvre par un contrôleur réseau, comprenant :
- la réception d'au moins un message de vérification (ou d'informations relatives audit au moins un message de vérification) en provenance d'un serveur de contrôle, ledit message de vérification correspondant à au moins une action de « vérification de l'accessibilité dudit équipement via au moins une tranche réseau » à exécuter,
- la transmission à au moins une entité relais sélectionnée, dudit au moins un message de vérification (ou éventuellement d'informations relatives audit au moins un message de vérification).
Selon ce mode de réalisation, le serveur de contrôle peut sélectionner une entité relais destinée à relayer au moins un message de vérification, et par suite un contrôleur du réseau auquel est connectée l'entité relais sélectionnée.
En particulier, l'équipement peut répondre au message de vérification qu'il reçoit, notamment si le message de vérification est une requête de vérification.
Dans ce cas, le procédé mis en œuvre par le contrôleur réseau comprend la réception, en provenance de ladite au moins une entité relais sélectionnée, d'informations relatives à une réponse audit au moins un message de vérification.
Dans un autre mode de réalisation, l'invention concerne un contrôleur réseau (en anglais « Network Controller ») adapté à mettre en œuvre le procédé de contrôle de l'accessibilité décrit précédemment. Un tel contrôleur réseau peut présenter les différentes caractéristiques relatives au procédé de contrôle de l'accessibilité selon l'invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de ce contrôleur réseau sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
L'invention concerne par ailleurs un procédé d'exécution d'une vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, mis en œuvre par une entité relais, comprenant : - la réception d'au moins un message de vérification (ou d'informations relatives audit au moins un message de vérification) en provenance d'un serveur de contrôle, ou d'au moins un message de vérification (ou d'informations relatives audit au moins un message de vérification) en provenance d'un contrôleur réseau du réseau auquel ladite entité relais est connectée, ledit au moins un message de vérification correspondant à au moins une action de « vérification de l'accessibilité dudit équipement via au moins une tranche réseau » à exécuter par ladite entité relais,
- la transmission, vers ledit équipement, dudit au moins un message de vérification.
Notamment, le message de vérification émis par l'entité relais peut être construit à partir des informations relatives audit au moins un message de vérification transmises par le serveur de contrôle ou le contrôleur réseau.
En particulier, l'équipement peut répondre à un message de vérification qu'il reçoit, notamment si le message de vérification est une requête de vérification.
Dans ce cas, le procédé mis en œuvre par l'entité relais comprend :
- la réception d'une réponse audit au moins un message de vérification,
- la transmission, audit serveur de contrôle ou audit contrôleur réseau, d'informations relatives à ladite réponse.
Dans un autre mode de réalisation, l'invention concerne une entité relais adaptée à mettre en œuvre le procédé d'exécution de la vérification de l'accessibilité décrit précédemment. Une telle entité relais pourra bien sûr présenter les différentes caractéristiques relatives au procédé d'exécution de la vérification de l'accessibilité selon l'invention, qui peuvent être combinées ou considérées isolément. Ainsi, les caractéristiques et avantages de cette entité relais sont les mêmes que ceux du procédé et ne sont pas détaillés plus amplement.
Par exemple, une telle entité relais est un routeur de bordure.
Dans un mode de réalisation particulier, des canaux sécurisés sont établis entre deux entités (serveur de contrôle, contrôleur réseau et/ou entité relais).
Par exemple, les canaux sécurisés selon les différents procédés mettent en œuvre le protocole de transport sécurisé QUIC.
La mise en œuvre d'un canal sécurisé entre l'équipement et le serveur de contrôle, et éventuellement entre deux entités (serveur de contrôle, contrôleur réseau et/ou entité relais) contribue à assurer l'intégrité des données échangées via ce canal sécurisé.
Dans un mode de réalisation particulier, ledit au moins un message de vérification selon les différents procédés appartient au groupe comprenant :
- une requête ICMP « Echo Request », une requête IOAM,
- au moins un paquet UDP « Traceroute »,
- au moins un paquet LSP Ping,
- au moins un paquet SFC Ping.
Dans les différents modes de réalisation envisagés, au moins une desdites tranches réseau peut être composée d'au moins une tranche réseau locale déployée dans au moins un sous-réseau (par exemple dans un réseau d'accès, un réseau de collecte, un réseau cœur, et un réseau de transit).
L'invention concerne encore au moins un programme d'ordinateur comportant des instructions pour la mise en œuvre d'au moins un des procédés décrits ci-dessus, lorsque ce ou ces programmes sont exécutés par un processeur, ainsi qu'au moins un support d'informations lisible par un ordinateur comportant des instructions d'au moins un programme d'ordinateur tel que mentionné ci-dessus.
Le procédé selon l'invention peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle.
4. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre d'exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre un exemple de réseau de communication composé de plusieurs sous-réseaux ; la figure 2 illustre un exemple d'agrégation de plusieurs services au sein d'une même tranche réseau ; la figure 3 illustre un exemple de déploiement de plusieurs instances de service ; la figure 4 représente un système dans lequel l'invention peut être mise en œuvre ; la figure 5A illustre les principales étapes des procédés selon un premier mode de réalisation de l'invention ; la figure 5B illustre les messages échangés selon ce premier mode de réalisation ; la figure 6A illustre les principales étapes des procédés selon un deuxième mode de réalisation de l'invention ; la figure 6B illustre les messages échangés selon ce deuxième mode de réalisation ; la figure 7A illustre les principales étapes des procédés selon un troisième mode de réalisation de l'invention ; la figure 7B illustre les messages échangés selon ce troisième mode de réalisation ; la figure 8 illustre un exemple de mise en œuvre avec un serveur de contrôle interne au réseau auquel l'équipement est connecté ; la figure 9 illustre un exemple de mise en œuvre avec un serveur de contrôle externe au réseau auquel l'équipement est connecté ; la figure 10 illustre un exemple de mise en œuvre avec un contrôleur réseau ; la figure 11 présente la structure simplifiée des différentes entités selon un mode de réalisation particulier.
5. Description d'un mode de réalisation de l'invention
5.1 Généralités
On considère un réseau de communication (composé éventuellement de plusieurs réseaux ou sous- réseaux) qui supporte des tranches réseau. Une tranche réseau peut être associée à d'autres tranches réseau pour fournir des services à valeur ajoutée. Par exemple, un fournisseur de service peut s'appuyer sur des tranches mises en place dans différents sous-réseaux pour fournir un service dont le trafic est destiné à être acheminé dans la tranche réseau « globale » composée des tranches déployées dans les différents sous-réseaux. On parle alors de « tranche multi-domaines » (ou « stitched slices » ou « hierarchical slices » en anglais). Une telle tranche réseau peut en effet refléter une structure hiérarchique.
Par exemple, comme illustré par la figure 1, le réseau SSP (« Slice Service Provider » en anglais, ou fournisseur de services reposant sur des tranches réseau) 12 peut être composé de plusieurs sous- réseaux 121, 122 et 123. Chaque sous-réseau peut supporter une ou plusieurs tranches réseau. Par exemple, le premier sous-réseau 121 supporte quatre tranches réseau, le deuxième sous-réseau 122 supporte trois tranches réseau, et le troisième sous-réseau 123 supporte quatre tranches réseau. La première tranche réseau SI. #1 161 du réseau de communication est par exemple composée des tranches réseau SI. #3 déployée sur le sous-réseau 121, SI. #2 déployée sur le sous-réseau 122 et SI. #2 déployée sur le sous-réseau 123. Les interfaces de raccordement entre tranches adjacentes (« Attachment Circuits » en anglais) sont par exemple gérées en utilisant les mécanismes décrits dans le document « YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS) » de M. Boucadair et al., version 6 publiée le 3 mai 2023.
Par exemple, chaque sous-réseau peut être associé à un domaine distinct (par exemple, un réseau de communication peut être composé d'un réseau d'accès, d'un réseau de collecte, d'un réseau cœur et d'un réseau de transit). Chacun de ces domaines supporte des tranches réseau dont l'ingénierie et l'exploitation sont caractéristiques du domaine (par exemple, une tranche déployée sur un réseau cœur mobile 5G peut faire appel à des fonctions de traitement de trafic et d'exploitation caractéristiques d'un réseau cœur mobile 5G). Chaque domaine (accès, collecte, cœur, transit, etc.) peut exploiter différentes technologies pour la réalisation des tranches réseau. Ainsi, la réalisation d'une tranche réseau qui s'étend sur plusieurs domaines n'est pas conditionnée par la disponibilité ou l'activation des mêmes technologies utilisées pour la réalisation des tranches « locales » à chaque domaine.
Par exemple, en référence à la figure 1, un premier domaine associé au premier sous-réseau 121 met en place des tunnels IPsec qui sont exploités pour acheminer le trafic dans les tranches déployées dans ce domaine, alors qu'un deuxième domaine associé au deuxième sous-réseau 122 utilise une ingénierie de réseau privé virtuel de niveau réseau (« Layer 3 VPN » ou L3VPN en anglais) combiné avec des mécanismes d'ingénierie de trafic (« Traffic Engineering » ou TE en anglais) pour acheminer le trafic dans les tranches déployées dans ce domaine, tandis qu'un troisième domaine associé au troisième sous-réseau 123 utilise les ressources du routage par segments reposant sur le protocole IPv6 (« Segment Routing IPv6 » ou SRv6 en anglais) pour acheminer le trafic dans les tranches déployées dans ce domaine.
Selon un autre exemple, une tranche réseau dans un réseau mobile (5G par exemple) peut reposer sur la mise en place de tranches réseau dans les différents sous-réseaux/segments suivants : réseau d'accès radio (« Radio Access Network » ou RAN), réseau cœur (« Core Network » ou CN) et réseau de transport (« Transport Network » ou TN).
L'association d'une tranche réseau, par exemple une tranche réseau 5G dans le cas d'un réseau mobile de dernière génération, aux tranches réseau déployées dans chacun des segments / sous-réseaux composant le réseau mobile 5G est réalisée dans le plan de contrôle et à la périphérie de chacun des réseaux RAN, CN et TN. La tranche réseau déployée dans le réseau TN est parfois appelée « IETF Network Slice ».
Selon l'invention, aucune hypothèse n'est faite quant à la nature des tranches réseau déployées dans un réseau, leur nombre, et le « mapping » entre des tranches réseau de domaines voisins (par exemple RAN et TN, TN et CN).
Par exemple, les mécanismes décrits dans le document « A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies » précédemment cité sont mis en œuvre pour la réalisation des tranches réseau dans un réseau IP/MPLS (qui est un exemple de réseau de transport au sens du 3GPP).
On note par ailleurs qu'une même tranche réseau peut être utilisée pour agréger le trafic d'un ou plusieurs services. Ainsi, comme illustré par la figure 2, un premier service SI servi par une ou plusieurs instances de service 21 peut être fourni à un premier client UE1 via une tranche réseau SI. #3 du réseau SSP, un deuxième service S2 servi par une ou plusieurs instances de service 22 peut être fourni à un deuxième client UE2 via la même tranche réseau SI. #3 du réseau SSP, un troisième service S3 servi par une ou plusieurs instances de service 23 peut être fourni au deuxième client UE2 via la même tranche réseau SI. #3 du réseau SSP.
De plus, une tranche réseau peut impliquer une ou plusieurs fonctions service (ou « Service Functions » en anglais, selon la terminologie utilisée par le document RFC7665 - « Service Function Chaining (SFC) Architecture » de J. Halpern et al. publié en octobre 2015, ou « Network Functions » comme gNB (« gNodeB ») ou des fonctions UPF (« User Plane Function ») selon la terminologie utilisée par le 3GPP). Une même fonction service peut être fournie par une ou plusieurs instances de service.
La figure 3 illustre un exemple de déploiement d'instances de service. En particulier, une instance de service peut être hébergée par le SSP (par exemple les instances de service 33 et 34) ou au sein d'une autre infrastructure (par exemple l'instance de service 35).
Dans un mode de réalisation particulier, des chaînes de service (« Service Function Chain » ou SFC en anglais) peuvent être mises en place afin de faciliter l'acheminement de trafics de différentes natures et présentant des profils différents pour les besoins de la réalisation d'une tranche réseau ou au sein d'une tranche réseau.
Ces chaînes de services peuvent notamment utiliser une ou plusieurs instances de service hébergées par un premier réseau. Par exemple, la chaîne SFC#1 est formée par les instances de service 311, 312 et 313 hébergées par le SSP.
Ces chaînes de services peuvent également utiliser une ou plusieurs instances de services hébergées par un deuxième réseau. Par exemple, la chaîne SFC#2 est formée par les instances de service 311, 312 et 313 hébergées par le SSP et les instances de service 314 et 315 hébergées par un autre réseau.
On considère par ailleurs un équipement, connecté à au moins un réseau. Un équipement peut être un équipement utilisateur (« User Equipment » en anglais), une instance de service, un CPE, un serveur, un routeur, etc. L'équipement peut être mobile, fixe, etc.
Des applications (ou clients applicatifs) peuvent être utilisées pour accéder à un service depuis un équipement. Ces applications peuvent solliciter, via des API exposées par le système d'exploitation (« Operating System » ou OS en anglais) de l'équipement, des traitements spécifiques.
5.2 Principe général
Le principe général de l'invention repose sur l'échange de messages entre un équipement et au moins un serveur de contrôle dédié, de façon à vérifier l'accessibilité de l'équipement via au moins une tranche réseau, plus précisément lorsque l'équipement est destinataire du trafic.
Notamment, des instructions ou « consignes de contrôle » (en anglais « Probing CTL ») peuvent être échangées via un canal sécurisé entre l'équipement et un serveur de contrôle dédié. De telles instructions comprennent notamment au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter. Lorsque cette action est exécutée, l'équipement peut vérifier s'il existe un lien entre des informations relatives à au moins un message de vérification généré par le serveur de contrôle à partir des instructions, ces informations ayant été transmises du serveur de contrôle à l'équipement via le canal sécurisé, et le(s) message(s) de vérification reçu(s) par l'équipement.
Une telle procédure est appelée ci-après « Slicing and trAcing over LArge scale Managed networks for A La cartE Communications », ou SALAMALEC, pour procédure de joigna bi lité à grande échelle via des tranches réseau.
La figure 4 illustre un exemple de système dans lequel l'invention peut être mise en œuvre.
On considère par exemple que l'équipement est un équipement utilisateur UE 41 (« User Equipment » en anglais) connecté à un réseau SSP 42 mettant en œuvre des tranches réseau, par exemple deux tranches réseau SI. #1 421 et SI. #2 422 (« Slice » en anglais).
L'équipement UE 41 peut éventuellement être connecté au réseau SSP 42 via un routeur intermédiaire, par exemple un CPE.
Le service peut être fourni par au moins une instance de service, par exemple par deux instances de services SFI #1 431 et SFI #2 432. Une instance de service peut être connectée au réseau 42 par l'intermédiaire d'un routeur de bordure du réseau. Par exemple, l'instance 431 est connectée au réseau 42 par l'intermédiaire du premier routeur de bordure BR 441 (« Border Router » en anglais), et la deuxième instance 432 est connectée au réseau 42 par l'intermédiaire du deuxième routeur de bordure BR 442. Les instances de service ne sont pas nécessairement directement connectées aux routeurs de bordure. Elles peuvent être hébergées par le réseau SSP 42 ou au sein d'un autre réseau. Au moins un serveur de contrôle 45, également appelé « Probing Server » ou SPS pour « SALAMALEC Probing Server », peut être déployé dans le réseau auquel est connecté l'équipement UE 41 (réseau SSP 42) ou dans un réseau distinct. Un tel serveur de contrôle permet notamment d'assister l'équipement UE 41 dans l'exécution du processus de vérification de disponibilité par tranche réseau, comme expliqué par la suite. Notamment, un tel serveur de contrôle peut sélectionner une ou plusieurs entités relais destinées à relayer des messages de vérification correspondant à au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter. Au moins un contrôleur réseau 46, également appelé NC pour « Network Controller », peut être déployé dans le réseau auquel est connecté l'équipement (SSP 42) ou dans un réseau distinct. Il peut notamment contrôler le réseau auquel au moins une entité relais est connectée. Par exemple, le contrôleur réseau 46 peut contrôler les routeurs de bordure 441 et 442. On présente désormais, en relation avec les figures 5A, 6A et 7 A, les principales étapes mises en œuvre par les différentes entités selon un mode de réalisation de l'invention.
On cherche par exemple à vérifier l'accessibilité de l'équipement 41 pour l'acheminement de données à destination de cet équipement 41 via au moins une tranche réseau.
Au moins un canal sécurisé 50 est établi entre l'équipement 41 et au moins un serveur de contrôle. Un serveur de contrôle peut être connecté au réseau auquel l'équipement 41 est lui-même connecté ou être connecté à un réseau distinct. Un tel canal est appelé ci-après canal SALAMALEC.
Le serveur de contrôle, par exemple le serveur SPS 45, obtient (451) des instructions comprenant au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter.
Dans un mode de réalisation, de telles instructions sont connues du serveur SPS. Par exemple, le serveur SPS dispose d'informations sur les conditions d'attachement de l'équipement 41 aux différentes tranches réseau parce qu'il est connecté au même réseau que l'équipement.
En variante, l'équipement 41 peut transmettre (411) au serveur SPS 45, via le canal sécurisé SALAMALEC 50 entre l'équipement 41 et le serveur SPS 45, de telles instructions comprenant au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter. Dans ce cas, le serveur SPS 45 reçoit les instructions transmises via le canal sécurisé 50 en provenance de l'équipement 41.
Dans un mode de réalisation, de telles instructions comprennent au moins l'une des informations suivantes : des informations d'identification de tranche réseau permettant d'identifier au moins une tranche réseau ou un type de tranche réseau à tester pour l'acheminement de données vers l'équipement, des informations d'identification d'un segment réseau permettant d'identifier au moins une entité relais à solliciter pour tester l'acheminement de données vers l'équipement. Une telle entité relais correspond par exemple à un point d'injection, c'est-à-dire à un endroit où des messages de vérification peuvent être injectés dans le réseau, comme décrit par la suite.
En particulier, si aucune information d'identification de tranche réseau n'est transmise, toutes les tranches réseau auxquelles l'équipement est connecté (ou tous les types de tranche réseau) peuvent être testé(e)s.
Le serveur SPS 45 peut alors générer (452), à partir des instructions (reçues de l'équipement 41 ou préalablement connues du serveur SPS 45), au moins un message de vérification correspondant à ladite au moins une action à exécuter. On note que différents messages de vérification peuvent être générés pour tester différentes tranches réseau (ou types de tranche réseau) ou différents segments/entités relais.
Le serveur SPS 45 peut ensuite transmettre (453) à l'équipement 41, via le canal sécurisé 50, des informations relatives audit au moins un message de vérification. De telles informations peuvent être le message de vérification lui-même, ou une information permettant de faire le lien avec le message de vérification.
L'équipement peut ainsi recevoir (412), via le canal sécurisé 50, des informations relatives audit au moins un message de vérification, transmises par le serveur SPS 45. Le serveur SPS notifie ainsi l'équipement du lancement des opérations de vérification. Le cas échéant, le serveur SPS peut notifier l'équipement de l'échéance de l'exécution des tests (par ex. dans 30 secondes) ainsi que la fin des tests.
Les éléments échangés entre l'équipement 41 et le serveur SPS 45 (instructions comprenant la ou les actions à effectuer, éventuelles informations d'identification, informations relatives à au moins un message de vérification) sont également appelées « Probing CTL », ou consignes de contrôle.
Ces étapes peuvent être réitérées avec différents SPS auxquels l'équipement est connecté.
Selon un premier mode de réalisation illustré par la figure 5A, on considère que le serveur SPS 45 peut directement envoyer un message de vérification, généré à partir des instructions, à destination de l'équipement 41. Pour ce faire, le serveur SPS 45 émet (456) le message de vérification, par exemple une requête ICMP « Echo Request », une requête I0AM, au moins un paquet UDP « Traceroute », au moins un paquet LSP Ping, ou au moins un paquet « SFC Ping » vers l'équipement 41, via au moins une tranche réseau ou un type de tranche réseau à tester pour l'acheminement de données à destination de l'équipement. Une telle transmission n'est pas effectuée via le canal sécurisé 50.
Si l'équipement 41 reçoit (413) le message de vérification, il peut vérifier (414) si le message de vérification qu'il reçoit est en adéquation (c'est-à-dire cohérent) avec les informations relatives audit au moins un message de vérification transmises via le canal sécurisé au cours de l'étape 453. Par exemple, une corrélation peut être effectuée entre le contenu d'un message de vérification reçu par l'équipement 41 et les informations relatives audit au moins un message de vérification reçues par l'équipement 41. Si tel est le cas, cela signifie que l'équipement est joignable via la ou les tranche(s)réseau ou type(s) de tranche réseau testé(e)(s).
Éventuellement, l'équipement 41 peut envoyer au serveur SPS 45 une réponse au message de vérification qu'il a reçu. Des informations relatives à la ou aux réponses reçues par le serveur SPS peuvent être transmises à l'équipement via le canal sécurisé 50, par exemple dans un message de réponse.
Le message de réponse peut notamment comporter un code d'erreur si une erreur de transmission est détectée ou si aucune réponse n'est reçue par le serveur SPS au bout d'un temps prédéterminé. Ainsi, en l'absence de réception par le serveur SPS d'une réponse de l'équipement à un message de vérification, ou sur réception par le serveur SPS d'un code d'erreur suite à l'envoi d'un message de vérification, le serveur SPS peut transmettre un message d'erreur vers l'équipement, et ce dernier peut relancer la procédure de vérification pour tester sa joignabilité via un autre SPS par exemple.
51 l'équipement 41 ne reçoit pas le message de vérification (par exemple après un délai déterminé, typiquement après l'expiration d'un délai à compter du lancement des tests de vérification, de l'ordre de 60 secondes par exemple), alors qu'il a reçu les informations relatives audit au moins un message de vérification, cela signifie que l'équipement n'est pas joignable via la ou les tranche(s) réseau ou type(s) de tranche réseau testé(e)(s). L'équipement peut le cas échéant déclencher une procédure pour notifier son fournisseur de réseau de ce problème de joignabilité ou réinitialiser son raccordement à la tranche réseau testée afin de rétablir le service via une ou plusieurs tranche(s) réseau ou type(s) de tranche réseau.
La figure 5B illustre un exemple de messages échangés entre un équipement 41 et deux serveurs de contrôle, par exemple un serveur 51 interne au réseau auquel l'équipement est connecté et un serveur
52 externe au réseau auquel l'équipement est connecté.
Un canal sécurisé 510 (respectivement 520) est établi entre l'équipement 41 et le serveur de contrôle 51 (respectivement 52). Les instructions comprenant au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter, les éventuelles informations d'identification et les informations relatives à au moins un message de vérification (« Probing CTL »), peuvent être échangées entre l'équipement 41 et le serveur de contrôle 51 via le canal sécurisé 510, et entre l'équipement 41 et le serveur de contrôle 52 via le canal sécurisé 520. Les consignes de contrôle transmises dans les différents canaux sécurisés peuvent être différentes (par exemple pour tester différentes tranches réseau).
Le serveur de contrôle 51, respectivement 52, peut alors exécuter la ou les actions correspondantes, par exemple en envoyant un ou plusieurs messages de vérification « Probing Messages » 511, respectivement 521.
Selon un deuxième mode de réalisation illustré par la figure 6A, on souhaite qu'au moins un message de vérification à destination de l'équipement, généré à partir des instructions, soit émis par une entité relais.
Les étapes 411 et 412 mises en œuvre par l'équipement 41, et 451 à 453 mises en œuvre par le serveur SPS 45 sont similaires à celles décrites en relation avec la figure 5A et ne sont pas répétées ici.
Selon ce mode de réalisation, le serveur SPS 45 sélectionne (454) au moins une entité relais à partir des instructions. Par exemple, une telle entité relais correspond à un point d'injection d'un message de vérification permettant de vérifier la joignabilité de l'équipement 41 sur un segment localisé entre l'entité relais et l'équipement 41. En particulier, une ou plusieurs entités relais peuvent être utilisées pour vérifier la joignabilité de l'équipement 41 sur un réseau local, sur un réseau dorsal régional, etc. Dans l'exemple illustré, l'entité relais sélectionnée est par exemple le routeur de bordure 441 ou tous les routeurs de bordure d'un réseau.
Un contrôleur réseau peut également être sélectionné (455) en tenant compte d'une contrainte sur l'entité relais sélectionnée. Par exemple, on sélectionne le contrôleur réseau du réseau auquel est connectée l'entité relais sélectionnée.
Dans l'exemple illustré, le contrôleur réseau sélectionné est par exemple le contrôleur réseau NC 46.
Un canal 61, par exemple un canal sécurisé, est établi entre le contrôleur réseau sélectionné (par exemple NC 46) et le serveur SPS 45, et un canal 62, par exemple un canal sécurisé, est établi entre le contrôleur réseau sélectionné (par exemple NC 46) et l'entité relais sélectionnée (par exemple BR 441). Au moins un message de vérification (ou des informations relatives audit au moins un message de vérification) peut alors être transmis (456') du serveur SPS 45 au contrôleur réseau 46 via le canal 61. Une fois ledit au moins un message de vérification reçu (461) par le contrôleur réseau 46, ce dernier peut envoyer ledit au moins un message de vérification (ou des informations relatives audit au moins un message de vérification) au routeur de bordure 441, via le canal 62.
Le message de vérification (ou des informations relatives audit au moins un message de vérification) peut ainsi être reçu (4411) par ledit routeur de bordure 441 (c'est-à-dire par au moins une entité relais).
Le routeur de bordure 441 peut alors émettre (4412) le message de vérification (éventuellement après construction dudit message de vérification à partir desdites informations relatives audit au moins un message de vérification), par exemple une requête ICMP « Echo Request », une requête I0AM, au moins un paquet UDP « Traceroute », au moins un paquet LSP Ping, ou au moins un paquet SFC Ping, vers l'équipement 41, via au moins une tranche réseau ou un type de tranche réseau à tester pour l'acheminement de données depuis le routeur de bordure 441 vers l'équipement 41.
Si l'équipement 41 reçoit (413') le message de vérification, il peut vérifier (414') si le contenu du message de vérification qu'il a reçu est en adéquation (c'est-à-dire cohérent) avec les informations relatives audit au moins un message de vérification transmises via le canal sécurisé 50 au cours de l'étape 453. Par exemple, une corrélation peut être effectuée entre le contenu du message de vérification reçu par l'équipement 41 et les informations relatives audit au moins un message de vérification reçues par l'équipement 41 depuis le serveur SPS 45. Si tel est le cas, cela signifie que l'équipement 41 est joignable depuis l'entité relais 441 via la ou les tranche(s)réseau ou type(s) de tranche réseau testé(e)(s).
Éventuellement, l'équipement 41 peut envoyer à l'entité relais 441 une réponse au message de vérification qu'il a reçu. Des informations relatives à la réponse reçue par l'entité relais 441 peuvent être transmises au contrôleur réseau 46 via le canal 62. Les informations reçues par le contrôleur réseau 46 peuvent être transmises au serveur SPS 45 via le canal 61. Les informations reçues par le serveur SPS peuvent être transmises à l'équipement 41 via le canal sécurisé 50, par exemple dans un message de réponse. Le message de réponse peut notamment comporter un code d'erreur si une erreur de transmission est détectée ou si aucune réponse n'est reçue par l'entité relais au bout d'un temps prédéterminé. Ainsi, en l'absence de réception par l'entité relais d'une réponse de l'équipement à un message de vérification, ou sur réception par l'entité relais d'un code d'erreur suite à l'envoi d'un message de vérification, l'entité relais peut transmettre un message d'erreur au serveur SPS 45, directement ou par l'intermédiaire du contrôleur réseau 46. Le serveur SPS 45 peut alors relayer ledit message d'erreur vers l'équipement, et ce dernier peut relancer la procédure de vérification pour tester sa joignabilité via un autre serveur SPS ou le même serveur SPS mais via une autre entité relais par exemple.
Si l'équipement 41 ne reçoit pas le message de vérification (par exemple après un délai déterminé, typiquement après l'expiration d'un délai à compter du lancement des tests de vérification, de l'ordre de 60 secondes par exemple), alors qu'il a reçu les informations relatives audit au moins un message de vérification, cela signifie que l'équipement 41 n'est pas joignable depuis l'entité relais 441 via la ou les tranche(s) réseau ou type(s) de tranche réseau testé(e)(s). A noter que si des messages de vérification ont été envoyés par le serveur SPS via tous les points d'interconnexion (routeurs ASBR (« Autonomous System Border Routers »), typiquement) d'un réseau, alors cela signifie que l'équipement 41 n'est pas joignable via la ou les tranche(s) réseau ou type(s) de tranche réseau testé(e)(s).
La figure 6B illustre un exemple de messages échangés entre un équipement 41, au moins un serveur de contrôle, par exemple le serveur SPS 45, au moins un contrôleur du réseau, par exemple le contrôleur réseau 46, et au moins une entité relais, par exemple le routeur de bordure 441.
Comme indiqué précédemment, un canal sécurisé 50 est établi entre l'équipement 41 et le serveur SPS 45. Un canal 61, par exemple un canal sécurisé, est également établi entre le serveur SPS 45 et le contrôleur réseau 46. Enfin, un canal 62, par exemple un canal sécurisé, est établi entre le contrôleur réseau 46 et le routeur de bordure 441.
Les instructions comprenant au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter, les éventuelles informations d'identification et les informations relatives à au moins un message de vérification (« Probing CTL ») peuvent être échangées entre l'équipement 41 et le serveur SPS 45 via le canal sécurisé 50. Le ou les messages de vérification générés à partir de ces instructions peuvent être transmis au contrôleur réseau 46 via le canal 61, puis au routeur de bordure 441 via le canal 62. On note que différents messages de vérification peuvent être générés pour les différentes entités relais.
Le routeur de bordure 441 peut alors exécuter la ou les actions correspondantes, par exemple en envoyant un ou plusieurs messages de vérification « Probing Messages » 63.
Selon un troisième mode de réalisation illustré par la figure 7A, on souhaite à nouveau qu'au moins un message de vérification à destination de l'équipement 41, généré à partir des instructions, soit émis par une entité relais.
Les étapes 411 et 412 mises en œuvre par l'équipement, et 451 à 453 mises en œuvre par le serveur SPS 45 sont similaires à celles décrites en relation avec la figure 5A et ne sont pas répétées ici. Selon ce troisième mode de réalisation, un serveur de contrôle peut s'interfacer directement avec au moins une entité relais, sans passer par un contrôleur réseau.
Selon ce mode de réalisation, le serveur SPS 45 sélectionne (454') au moins une entité relais à partir des instructions. Dans l'exemple illustré, l'entité relais sélectionnée est par exemple le routeur de bordure 441.
Un canal 71, par exemple un canal sécurisé, est établi entre au moins une entité relais sélectionnée, par exemple le routeur de bordure 441, et le serveur SPS 45.
Au moins un message de vérification (ou des informations relatives audit au moins un message de vérification) peut alors être transmis (456") du serveur SPS 45 au routeur de bordure 441 via le canal 71.
Une fois le message de vérification reçu (4411') par le routeur de bordure 441 (c'est-à-dire par au moins une entité relais), le routeur de bordure 441 peut alors émettre (44121) le message de vérification (éventuellement construit à partir des informations relatives audit au moins un message de vérification), par exemple une requête ICMP « Echo Request », une requête I0AM, au moins un paquet UDP « Traceroute », au moins un paquet LSP Ping, ou au moins un paquet SFC Ping, vers l'équipement 41, via au moins une tranche réseau ou un type de tranche réseau à tester pour l'acheminement de données depuis le routeur de bordure 441 vers l'équipement 41.
Si l'équipement 41 reçoit (413') le message de vérification, il peut vérifier (414") si le contenu dudit message de vérification qu'il reçoit est en adéquation (c'est-à-dire cohérent) avec les informations relatives audit au moins un message de vérification transmises via le canal sécurisé 50 au cours de l'étape 453. Comme déjà indiqué, une corrélation peut être effectuée entre le contenu du message de vérification reçu par l'équipement 41 et les informations relatives audit au moins un message de vérification reçues par l'équipement 41. Si tel est le cas, cela signifie que l'équipement est joignable depuis l'entité relais via la ou les tranche(s) réseau ou type(s) de tranche réseau testé(e)(s).
Éventuellement, l'équipement 41 peut envoyer à l'entité relais une réponse au message de vérification qu'il a reçu. Des informations relatives à la réponse reçue par l'entité relais peuvent être transmises au serveur SPS 45 via le canal 71. Les informations reçues par le serveur SPS peuvent être transmises à l'équipement 41 via le canal sécurisé 50, par exemple dans un message de réponse.
Le message de réponse peut notamment comporter un code d'erreur si une erreur de transmission est détectée ou si aucune réponse n'est reçue au bout d'un temps prédéterminé. Ainsi, en l'absence de réception par l'entité relais d'une réponse de l'équipement à un message de vérification, ou sur réception par l'entité relais d'un code d'erreur suite à l'envoi d'un message de vérification, l'entité relais peut transmettre un message d'erreur au serveur SPS 45. Le serveur SPS 45 peut alors relayer ledit message d'erreur vers l'équipement, et ce dernier peut relancer la procédure de vérification pour tester sa joignabilité via une autre entité relais ou via un autre serveur SPS par exemple.
Si l'équipement 41 ne reçoit pas le message de vérification (par exemple après un délai déterminé, typiquement après l'expiration d'un délai à compter du lancement des tests, de l'ordre de 60 secondes par exemple), alors qu'il a reçu les informations relatives audit au moins un message de vérification, cela signifie que l'équipement 41 n'est pas joignable depuis l'entité relais via la ou lestranche(s) réseau ou type(s) de tranche réseau testé(e)(s).
La figure 7B illustre un exemple de messages échangés entre un équipement 41, au moins un serveur de contrôle, par exemple le serveur SPS 45, et au moins une entité relais, par exemple le routeur de bordure 441.
Comme indiqué précédemment, un canal sécurisé 50 est établi entre l'équipement 41 et le serveur SPS 45. Un canal 71, par exemple un canal sécurisé, est également établi entre le serveur SPS 45 et le routeur de bordure 441.
Les instructions comprenant au moins une action de « vérification de l'accessibilité de l'équipement via au moins une tranche réseau » à exécuter, les éventuelles informations d'identification et les informations relatives à au moins un message de vérification (« Probing CTL ») peuvent être échangées entre l'équipement 41 et le serveur SPS 45 via le canal sécurisé 50. Le ou les messages de vérification générés à partir de ces instructions peuvent être transmis au routeur de bordure 441 via le canal 71. On note que différents messages de vérification peuvent être générés pour une même entité relais ou pour les différentes entités relais. Le routeur de bordure 441 peut alors exécuter la ou les actions correspondantes, par exemple en envoyant un ou plusieurs messages de vérification « Probing Messages » 72.
5.3 Exemple de mise en œuvre
On présente désormais un exemple de mise en œuvre de l'invention, selon lequel les différents canaux sécurisés mettent en œuvre un protocole de transport sécurisé comme le protocole QUIC (tel que décrit dans le standard RFC 9000). Dans d'autres exemples, au moins un canal sécurisé peut mettre en œuvre un protocole applicatif sécurisé tel que le protocole CoAP (en anglais « Constrained Application Protocol », tel que décrit dans le standard RFC 7252) sur DTLS (en anglais « Datagram Transport Layer Security », tel que décrit dans le standard RFC 9147), ou le protocole PCP (en anglais « Port Control Protocol », tel que décrit dans le standard RFC 6887), etc.
Selon l'exemple décrit ci-après, un message de vérification est par exemple une requête de vérification encapsulée dans une trame QUIC appelée « PROBING_REQUEST ». Une réponse à cette requête peut être encapsulée dans une trame QUIC appelée « PROBING_REPLY ».
5.3.1 Équipement
Dans cet exemple, on considère que l'équipement pour lequel on souhaite vérifier la joignabilité du trafic retour est un équipement utilisateur. Dans d'autres modes de réalisation, un tel équipement peut être un CPE, une instance de service, un serveur, un routeur, etc.
L'équipement selon cet exemple de mise en œuvre est raccordé à au moins une tranche supportée par un réseau. Par exemple, l'équipement maintient au moins l'une des informations descriptives suivantes pour au moins l'une des tranches auxquelles il est connecté : un type de tranche réseau (« Slice Type » ou ST) : ce paramètre peut être choisi de façon à pouvoir être interprété de la même façon par les différents SSP qui fournissent ce type de tranche. Des types standardisés ou spécifiques (par exemple, selon des accords de gré-à-gré établis entre différents SSP) peuvent être envisagés. Par exemple, le paramètre ST peut être obtenu par un équipement lors de sa connexion à une tranche réseau fournie par un SSP ou par configuration (dans le cas où l'équipement est une instance de service, par exemple). Dans un mode de réalisation particulier, plusieurs types de tranches peuvent être associés à une même tranche réseau. Ceci est notamment utile lorsqu'une même tranche réseau est conçue pour agréger plusieurs tranches déployées dans différents sous-réseaux (« hierarchical slices »). un identifiant de tranche réseau (« Slice Identifier » ou SID). Ce paramètre peut être obtenu par un équipement lors de sa connexion à une tranche réseau fournie par un SSP ou par configuration (dans le cas où l'équipement est une instance de service, par exemple). un identifiant de réseau (« Network Identifier » ou NID). Ce paramètre peut être utilisé pour déterminer si deux entités sont connectées à un même réseau. Dans ce cas, il sera possible d'utiliser l'identifiant de tranche réseau SID pour marquer les paquets d'une connexion acheminée via la tranche réseau identifiée par le SID. Le NID peut aussi être utile dans certains cas pour faciliter la corrélation entre les SID des équipements source et destination. Par exemple, ce paramètre peut être obtenu par un équipement lors de sa connexion à une tranche réseau fournie par un SSP ou par configuration (dans le cas où l'équipement est une instance de service, par exemple).
5.3.2 Serveurs de contrôle
Afin de vérifier l'accessibilité d'un équipement via au moins une tranche réseau pour l'acheminement du trafic retour (c'est-à-dire à destination de l'équipement), au moins un serveur de contrôle SPS (« SALAMALEC Probing server ») dédié est déployé, dans le réseau auquel l'équipement est connecté ou dans un réseau distinct.
On note qu'un serveur de contrôle SPS peut être géré par un fournisseur de services de vérification SALAMALEC (SPP, « SALAMALEC Probing Provider »).
Un fournisseur de services de vérification SPP peut négocier avec un fournisseur SSP de services reposant sur des tranches réseau l'activation de la procédure SALAMALEC. Une API dédiée peut être utilisée à cet effet, comme l'API « Network Exposure Function » (NEF). Cette API permet par exemple d'enregistrer une liste de serveurs SPS habilités à contacter un contrôleur réseau (ou NC, par exemple un contrôleur SDN). Un tel contrôleur réseau peut notamment contacter différentes entités relais pour vérifier la joignabilité d'un équipement pour l'acheminement de données via au moins une tranche réseau entre la ou les entités relais et l'équipement. Une telle entité relais correspond donc à un point d'injection spécifique, c'est-à-dire à un endroit où des messages de vérification peuvent être injectés dans le réseau (par exemple pour tester tout ou partie des nœuds de périphérie d'un réseau local, d'un réseau régional, ou un lien d'interconnexion).
Ladite API peut aussi être utilisée pour communiquer au fournisseur SPP des informations descriptives d'au moins un contrôleur réseau, comme les informations de joignabilité du contrôleur réseau, notamment. Le contrôleur réseau peut alors se charger de relayer les messages de vérification destinés à l'équipement vers des points de passage négociés (par exemple tout ou partie des routeurs de type ASBR. Par exemple, au moins une adresse IP et des informations d'authentification d'un contrôleur réseau sont exposées au fournisseur SPP. Ce dernier fournit ces informations à au moins un serveur SPS. De même, des informations d'identification du réseau peuvent être fournis à au moins un serveur SPS (par exemple, un identifiant de réseau NID ou des plages d'adresses). Dans la suite, on suppose que le NID est utilisé. Dans une variante, un serveur SPS peut s'interfacer directement avec une entité relais.
5.3.3 Phase de découverte ou d'autorisation
Au cours d'une première phase, l'équipement procède à la découverte d'un ou plusieurs serveurs SPS. Un serveur SPS peut être annoncé en utilisant l'infrastructure DNS, une page Web, une configuration explicite, etc.
Sur découverte d'un serveur SPS, l'équipement établit un canal SALAMALEC avec le serveur SPS, par exemple en utilisant une connexion QUIC. Comme indiqué, d'autres protocoles peuvent toutefois être envisagés pour l'établissement d'un canal sécurisé.
De nouvelles trames QUIC peuvent être définies pour échanger des consignes de contrôle (« Probing CTL ») entre l'équipement et au moins un serveur SPS.
Par exemple, de telles trames sont :
SLICE_TYPE : une trame SLICE_TYPE renseigne le ou les types des tranches réseau supportées par un équipement ou un serveur SPS. La trame SLICE_TYPE peut aussi être utilisée pour imposer le type des tranches réseau à tester pour vérifier l'accessibilité d'un équipement. Par exemple, la valeur « 0 » indique qu'on peut tester l'accessibilité de l'équipement pour tous les types de tranche réseau.
SLICEJD : une trame SLICEJD renseigne le ou les identifiants des tranches réseau supportées par un équipement ou un serveur SPS. La trame SLICEJD peut aussi être utilisée pour imposer les tranches réseau à tester pour vérifier l'accessibilité d'un équipement. Par exemple, la valeur « 0 » indique qu'on peut tester l'accessibilité de l'équipement pour toutes les tranches réseau connues du serveur SPS.
NID : une trame NID renseigne le ou les identifiants des réseaux auxquels l'équipement ou le serveur SPS sont connectés. La trame NID peut aussi être utilisée pour imposer le réseau qui héberge les tranches réseau à tester pour vérifier l'accessibilité d'un équipement.
COMO : une trame COMO indique si le serveur SPS supporte un mode collaboratif (désigné par COMO) avec le réseau auquel est connecté l'équipement ; en d'autres termes, une telle trame indique qu'une procédure permettant au serveur SPS de contrôler les points d'injection des messages de vérification a été mise en place.
PROBING_REQUEST : une trame PROBING_REQUEST peut comporter un message de vérification. Par exemple, une trame PROBING_REQUEST encapsule une requête de vérification (« Request »). Cette trame PROBING J QUEST peut être décapsulée, et la requête de vérification envoyée par une entité relais par exemple (routeur en périphérie du réseau). PROBING_REPLY : une trame PROBING_REPLY peut porter un message de réponse. Par exemple, une trame PROBING_REPLY encapsule une réponse (« Reply »). Cette réponse peut être encapsulée par une entité relais par exemple.
Par exemple, la structure d'une trame PROBING_REQUEST est la suivante :
PROBING_REQUEST Frame {
Type (i),
Request_type (i),
Request,
} avec :
Type (i) : un identifiant unique de la trame PROBING_REQUEST.
Request_type (i) : le type de la requête de vérification encapsulée. Par exemple, les valeurs suivantes peuvent être définies : 0 (ICMP), 1 (UDP), 2 (IOAM), 3 (LSP Ping), ... L'information « Request_type (i) » est facultative, notamment si un type par défaut est défini (par exemple, toutes les requêtes de vérification sont de type ICMP « Echo Request »).
Request : la requête de vérification correspondant à au moins une action à exécuter. Avantageusement, la requête de vérification indique également l'adresse destination d'au moins une entité relais à solliciter pour tester l'acheminement de données à destination dudit équipement et éventuellement un numéro de port. Un exemple de requête ICMPv6 est : (Dst@: 2001:db8 ::2 ICMPv6 126 Echo Request id=0xl234, seq=l, hop limit=64).
Un exemple de format de trame « PROBING_REQUEST » qui encapsule une requête de type ICMP est fourni ci-après :
Les métadonnées associées aux tranches réseau, ou « slice metadata », comprennent des indications relatives aux tranches réseau. Ces indications peuvent notamment être utilisées par un nœud pour marquer des paquets de données. De cette façon, la classification de la requête de vérification pour l'associer à une tranche donnée de façon non ambiguë est simplifiée. La description des autres champs est similaire à celle documentée dans les standards RFC 792 pour ICMPv4 (« Internet Control Message Protocol », J. Postel, Septembre 1981) et RFC 4443 pour ICMPv6 (« Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification », A. Conta et al., mars 2006).
Un exemple de format de trame « PROBING_REQUEST » qui encapsule une requête de type I0AM est fourni ci-après :
La description des champs I0AM est identique à celle décrite dans les documents RFC 9452 (« Network Service Header (NSH) Encapsulation for In Situ OAM (I0AM) Data », F. Brockners et al., août 2023) et RFC 9197 (« Data Fields for In Situ Operations, Administration, and Maintenance (I0AM) », F. Brockners et al., mai 2022).
La requête de vérification (« Request ») encapsulée dans une trame « PROBING_REQUEST » peut être un message ICMP (par exemple un message ICMP « Echo Request ») ou un tout autre message permettant de vérifier si les règles de classification de trafic à l'entrée du réseau sont convenablement configurées pour associer un trafic donné à une tranche.
Par exemple, la requête de vérification appartient au groupe comprenant :
- une requête ICMP « Echo Request »,
- une requête I0AM,
- au moins un paquet UDP « Traceroute »,
- au moins un paquet LSP Ping,
- au moins un paquet SFC Ping.
Une telle requête de vérification peut également servir au fournisseur de services utilisant des tranches réseau SSP pour lui permettre de vérifier les règles de classification de trafic qu'il a mis en œuvre.
Un message de réponse peut être généré en réponse à une requête de vérification.
La structure d'une trame PROBING_REPLY est par exemple la suivante : PROBING_ REPLY Frame {
Type (i),
Request_type (i),
Reply,
} avec :
Type (i) et Request_type (i) comme définis précédemment relation avec la trame PROBING-REQUEST
Reply : la réponse à la requête de vérification.
Ainsi, au cours de la phase d'autorisation, différents messages peuvent être échangés entre l'équipement et au moins un serveur SPS, sur le canal sécurisé établi entre l'équipement et le serveur SPS considéré. Ces messages permettent notamment au serveur SPS d'obtenir au moins une information descriptive de l'équipement appartenant au groupe comprenant :
- au moins un type de tranche réseau supporté par l'équipement (ST),
- au moins un identifiant d'une tranche réseau supportée par l'équipement (SID),
- au moins un identifiant d'un réseau auquel l'équipement est connecté (NID).
Ces messages permettent également à l'équipement d'obtenir au moins une information descriptive du serveur SPS appartenant au groupe comprenant :
- au moins un type de tranche réseau supporté par le serveur SPS (ST),
- au moins un identifiant d'une tranche réseau supportée par le serveur SPS (SID),
- au moins un identifiant d'un réseau auquel le serveur SPS est connecté (NID),
- au moins un indicateur spécifiant si le serveur SPS supporte un mode collaboratif avec le réseau
SSP (COMO),
- une liste d'identifiants de domaines réseau avec lesquels le serveur SPS supporte le mode collaboratif COMO.
A l'issue de ces échanges, l'équipement peut enregistrer les informations descriptives du ou des serveurs SPS. En particulier, l'identifiant de réseau permet à l'équipement d'identifier les serveurs SPS hébergés par le même réseau que celui auquel l'équipement est connecté.
L'équipement peut alors clôturer la connexion sécurisée, en fermant le canal SALAMALEC.
5.3.4 Vérification de la joignabilité
Au cours d'une deuxième phase, l'équipement peut vérifier sa joignabilité via une tranche réseau donnée depuis une entité relais connectée au même réseau que celui auquel est connecté l'équipement, ou connectée à un réseau différent, par exemple au réseau Internet. L'équipement peut éventuellement sélectionner le ou les serveurs SPS à solliciter pour tester sa joignabilité. Par exemple, l'équipement peut ne retenir que les serveurs SPS internes au réseau auquel est connecté l'équipement, ou uniquement les serveurs SPS externes au réseau auquel est connecté l'équipement, ou encore les serveurs SPS qui supportent le mode collaboratif, tel qu'indiqué dans l'attribut COMO. Cette sélection peut éventuellement être effectuée par l'utilisateur de l'équipement, par exemple selon une demande de confirmation de sélection, selon une liste de serveurs SPS à cocher moyennant des indications géographiques, etc.
On note que l'équipement peut solliciter concomitamment ou séquentiellement plusieurs serveurs SPS sélectionnés lors de l'étape précédente.
L'équipement peut alors établir un canal SALAMALEC avec chacun des serveurs SPS qu'il a sélectionnés (ou avec l'ensemble des serveurs SPS qu'il a découvert lors de la phase d'autorisation si l'équipement ne met pas en œuvre un procédé de sélection des serveurs SPS).
L'équipement peut alors transmettre aux serveurs SPS, via les différents canaux SALAMALEC, des instructions comprenant au moins une action/commande à exécuter par le serveur SPS ou par au moins une entité relais (par exemple, génération d'une requête ICMP « Echo Request », de paquets UDP « Traceroute », de paquets LSP Ping, de paquets SFC Ping).
En variante, le serveur SPS dispose directement de ces instructions.
Ces instructions peuvent également identifier la ou les tranches réseau, ou type de tranche réseau, à tester. Par exemple, un équipement peut demander à un serveur SPS de procéder à des vérifications pour tout ou partie des tranches réseau disponibles. Pour ce faire, l'équipement utilise les trames QUIC idoines, par exemple les trames SLICEJD et PROBING_REQUEST. En variante, aucune tranche réseau n'est spécifiée. Dans ce cas, le serveur SPS peut procéder à des vérifications pour toutes les tranches réseau disponibles.
Le serveur SPS peut notamment extraire de ces instructions la ou les action(s)/commande(s) à exécuter pour vérifier la joignabilité de l'équipement, des informations d'identification de tranche réseau permettant d'identifier au moins une tranche réseau ou un type de tranche réseau à tester, des informations d'identification d'un segment réseau permettant d'identifier au moins une entité relais à solliciter pour tester l'acheminement de données (par exemple l'adresse destination correspondant à une entité relais à solliciter).
Dans un premier mode de réalisation, correspondant à celui illustré par les figures 5A et 5B, on considère que les demandes de vérification peuvent être émises directement par le serveur SPS.
Dans ce cas, le serveur SPS peut émettre au moins une requête de vérification (ICMP « Echo Request », I0AM, etc.) à destination de l'équipement, générée à partir des instructions reçues de l'équipement ou selon une logique propre au serveur SPS. Une telle requête de vérification est également appelée requête de « probing ».
La ou les réponses reçues par le serveur SPS peuvent être transmises à l'équipement dans un message de réponse (par exemple dans une trame PROBING_REPLY).
Dans un deuxième mode de réalisation, correspondant à celui illustré par les figures 6A et 6B, on considère que les demandes de vérification sont contraintes et doivent être émises depuis un autre point d'injection correspondant à une entité relais, selon des instructions formulées par un équipement, son utilisateur ou par un SSP. Par exemple, une telle entité relais peut être identifiée par le serveur SPS à partir d'une adresse destination présente dans les instructions transmises par l'équipement.
A réception des instructions, le serveur SPS peut notamment générer une ou plusieurs requêtes de vérification (« Request ») correspondant à une ou plusieurs actions/commandes à exécuter. De telles requêtes de vérification peuvent être encapsulées dans au moins une trame PROBING_REQUEST.
Le serveur SPS peut transmettre la ou les trames PROBING_REQUEST à au moins une entité relais sélectionnée à partir des instructions, soit directement soit par l'intermédiaire d'un contrôleur réseau. Par exemple, le serveur SPS peut transmettre la ou les trames PROBING_REQUEST au contrôleur réseau connecté au même réseau que celui auquel est connecté l'équipement (par exemple identifié par le même NID que celui du réseau auquel est connecté l'équipement), ou au contrôleur réseau d'un réseau distinct de celui auquel est connecté l'équipement (par exemple identifié par un NID différent de celui du réseau auquel est connecté l'équipement).
Si un contrôle réseau intervient, la ou les trames PROBING_REQUEST sont transmises via un canal sécurisé établi entre le serveur SPS et le contrôleur réseau.
Une ou plusieurs entités relais, par exemple un routeur en périphérie du réseau (Border Router ou BR), peuvent être sollicités par le contrôleur réseau pour exécuter les demandes de vérification selon les instructions d'un serveur SPS.
Ainsi, un contrôleur réseau recevant une trame PROBING_REQUEST peut faire suivre la trame PROBING_REQUEST à une ou plusieurs entités relais (par exemple identifiée(s) par l'adresse destination présente dans la requête de vérification « Request » de la trame PROBING_REQUEST). De tels échanges sont effectués sur un canal sécurisé établi entre le contrôleur réseau et l'entité relais.
Une entité relais recevant une trame PROBING_REQUEST peut décapsuler la trame PROBING_REQUEST pour récupérer la requête de vérification « Request ». La requête de vérification peut ainsi être envoyée par l'entité relais (un routeur en périphérie du réseau par exemple). Une telle entité relais peut notamment utiliser sa propre adresse source pour émettre la ou les requêtes de vérification.
La ou les réponses reçues par l'entité relais peuvent être transmises au contrôleur réseau dans une trame PROBING_REPLY. Le contrôleur réseau peut faire suivre la trame PROBING_REPLY au serveur SPS, qui peut à son tour la faire suivre à l'équipement.
Dans un troisième mode de réalisation, correspondant à celui illustré par les figures 7A et 7B, on considère également que les demandes de vérification sont contraintes et doivent être émises depuis un autre point d'injection correspondant à une entité relais. Selon ce mode de réalisation, le serveur SPS peut notamment générer une ou plusieurs requêtes de vérification (« Request ») et les encapsuler dans au moins une trame PROBING_REQUEST, pour transmission à une entité relais identifiée par exemple à partir de l'adresse destination présente dans la requête de vérification. Selon ce mode de réalisation, le serveur SPS peut communiquer directement avec les entités relais, sans nécessiter l'intervention d'un contrôleur réseau.
Dans ces différents modes de réalisation, le serveur SPS peut notifier l'équipement du lancement des opérations de vérification ou l'échéance d'une telle vérification (par ex. mode différé). Pour ce faire, le serveur SPS peut notamment communiquer à l'équipement, via le canal sécurisé, des informations relatives aux requêtes de vérification qu'il a générées. Une échéance peut éventuellement être communiquée pour contrôler le délai au-delà duquel l'équipement met fin à l'étape de vérification.
L'équipement peut, le cas échéant, effectuer les opérations nécessaires pour permettre le traitement des requêtes de vérification reçues (par exemple configurer un pare-feu pour qu'il accepte l'acheminement des trames PROBING_REQUEST ou instancier un état dans un CGN « Carrier-Grade NAT »).
Si l'équipement reçoit des requêtes de vérification envoyées par le serveur SPS ou par une entité relais (par exemple s'il reçoit une requête de vérification ICMP « Echo Request » encapsulée dans une trame PROBING_REQUEST) et que ces requêtes de vérification correspondent aux informations reçues via le canal sécurisé établi entre le serveur SPS et l'équipement, ce dernier conclut que le chemin « retour » via une ou plusieurs tranches réseau est opérationnel. Le message de vérification peut inclure des indications sur le chemin emprunté par la réponse au sein de la tranche réseau (intra-tranche) si cette fonction a été activée par le serveur SPS.
Si aucune requête de vérification envoyée par le serveur SPS ou par une entité relais n'est reçue par l'équipement (par exemple si l'équipement ne reçoit pas la requête de vérification ICMP « Echo Request »), typiquement après expiration d'une échéance donnée, le serveur SPS peut communiquer à l'équipement le message d'erreur qu'il a reçu le cas échéant. Par exemple, le serveur SPS reçoit une réponse suite à la requête de vérification qu'il a émise. Une telle réponse peut être un message d'erreur ICMP qui est envoyé par un routeur sur le chemin de la requête. Le serveur SPS peut encapsuler la réponse reçue dans un message de réponse (trame PROBING_REPLY), et transmettre ce message de réponse à l'équipement. En variante, l'entité relais reçoit une réponse à la requête de vérification qu'elle a émise. L'entité relais peut encapsuler la réponse reçue dans un message de réponse (trame PROBING_REPLY), et transmettre le message de réponse au serveur SPS (directement ou par l'intermédiaire d'un contrôleur réseau) qui peut à son tour transmettre ce message de réponse à l'équipement.
En particulier, le message d'erreur encapsulé dans une trame PROBING_REPLY transmise à l'équipement permet à ce dernier de détecter et d'identifier le problème de joignabilité au sein d'une tranche réseau.
A titre d'exemples, les figures 8 à 10 illustrent l'exécution d'une procédure de vérification SALAMALEC selon ces différents modes de réalisation.
Des applications (ou clients applicatifs) peuvent être utilisées pour accéder à un service depuis un équipement. Ces applications peuvent solliciter, via des API exposées par le système d'exploitation (« OS ») de l'équipement, des traitements spécifiques. Par exemple, une application APP1 utilise l'API de l'équipement pour vérifier la joignabilité de l'équipement via une tranche réseau Sl#l et une application APP2 utilise l'API de l'équipement pour vérifier la joignabilité de l'équipement via une tranche réseau Sl#2.
Selon l'exemple illustré par la figure 8, on considère un serveur SPS 85 interne au réseau SSP 82 auquel un équipement 81 est connecté. L'équipement 81 sollicite le serveur SPS 85 pour qu'il exécute une procédure de vérification n'impliquant pas de contrôleur réseau. La figure 8 illustre un exemple où la joignabilité via une tranche du réseau est confirmée.
Ainsi, l'équipement 81 envoie des instructions au serveur SPS 85. Celui-ci génère une requête de vérification et envoie à l'équipement 81 des informations relatives à la requête de vérification via un canal sécurisé (par exemple dans une trame PROBING_REQUEST encapsulant la requête de vérification). Le serveur SPS 85 exécute également l'action correspondant à la requête de vérification, par exemple en émettant une requête ICMP « Echo Request ». Selon l'exemple illustré, l'équipement 81 reçoit la requête ICMP « Echo Request » via le routeur de bordure BR 841. L'équipement 81 peut comparer la requête ICMP « Echo Request » reçue et les informations relatives à la requête de vérification. Si ces informations sont identiques ou liées, la joignabilité est confirmée via la tranche réseau Sl#l 821.
Selon l'exemple illustré par la figure 9, on considère un serveur SPS 95 externe au réseau SSP 92 auquel un équipement 91 est connecté. L'équipement 91 sollicite le serveur SPS 95 pour qu'il exécute une procédure de vérification n'impliquant pas de contrôleur réseau. La figure 9 illustre un exemple où la joignabilité via une tranche du réseau n'est pas confirmée.
Ainsi, l'équipement 91 envoie des instructions au serveur SPS 95, via un routeur de bordure 942. Le serveur SPS 95 génère une requête de vérification et envoie à l'équipement 91 des informations relatives à la requête de vérification via un canal sécurisé (par exemple dans une trame PROBING_REQUEST encapsulant la requête de vérification). Le serveur SPS 95 exécute également l'action correspondant à la requête de vérification, par exemple en émettant une requête ICMP « Echo Request ». Selon l'exemple illustré, l'équipement 91 ne reçoit pas la requête ICMP « Echo Request », alors qu'il s'attend à recevoir une telle requête, telle que spécifiée dans les informations relatives à la requête de vérification. La requête ICMP « Echo Request » est dans cet exemple filtrée par le routeur de bordure 942 et n'est pas transmise à l'équipement 91. L'échec de joignabilité est par exemple lié à l'inadéquation des règles de classification de trafic.
Selon l'exemple illustré par la figure 10, on considère un serveur SPS 105 interne au réseau SSP 102 auquel un équipement 101 est connecté. L'équipement 101 sollicite le serveur SPS 105 pour qu'il exécute une procédure de vérification impliquant un contrôleur réseau 106. La figure 10 illustre un exemple où la joignabilité via une tranche du réseau est confirmée depuis un ou plusieurs routeurs de bordure (par exemple un premier routeur de bordure 1041 et un deuxième routeur de bordure 1042). Ainsi, l'équipement 101 envoie des instructions au serveur SPS 105, via le premier routeur de bordure 1041. Le serveur SPS 105 génère une requête de vérification et envoie à l'équipement 101 des informations relatives à la requête de vérification (par exemple une trame PROBING_REQUEST encapsulant la requête de vérification). Le serveur SPS 105 envoie également la requête de vérification ou la trame PROBING_REQUEST au contrôleur réseau 106. Ce dernier l'envoie au deuxième routeur de bordure 1042.
Le deuxième routeur de bordure 1042 peut décapsuler la trame PROBING_REQUEST pour extraire la requête de vérification. Le deuxième routeur de bordure 1042 peut alors exécuter l'action correspondant à la requête de vérification, par exemple en émettant une requête ICMP « Echo Request ».
Selon l'exemple illustré, l'équipement 101 reçoit la requête ICMP « Echo Request » via le routeur de bordure BR 1041. L'équipement 101 peut comparer la requête ICMP « Echo Request » reçue avec les informations relatives à la requête de vérification préalablement reçues. Si ces informations sont identiques ou corrélées, la joignabilité de l'équipement est confirmée via la tranche réseau testée Sl#2 1022.
5.4 Variantes On a décrit ci-dessus différents exemples selon lesquels l'équipement est un équipement utilisateur. Dans d'autres modes de réalisation, mettant en œuvre des étapes similaires, l'équipement peut être un CPE, une instance de service, un serveur, un routeur, etc.
En particulier, la procédure SALAMALEC peut être déclenchée depuis un équipement connecté au réseau via un CPE. Les mêmes étapes que celles décrites précédemment sont mises en place par l'équipement. Cependant, l'équipement peut dans ce cas instruire le CPE afin qu'il ne filtre pas les messages de vérification émis depuis un serveur SPS. Pour ce faire, l'équipement peut utiliser une interface de configuration du CPE ou invoquer un protocole de gestion des ACL (« Access Control List ») tel que PCP ou RESTCONF, tels que décrit dans les documents RFC8040 (« RESTCONF Protocol »,
A. Bierman et al. Janvier 2017) ou RFC8519 (« YANG Data Model for Network Access Control Lists (ACLs) », M. Jethanandani et al., mars 2019).
On a également décrit le cas où un serveur de contrôle est un serveur dédié. En variante, le serveur SPS peut être embarqué dans un serveur qui fournit un service. Les messages de vérification peuvent alors être encapsulés dans les messages qui font partie du service (c'est-à-dire, les messages d'invocation du service tels que des messages http ou SIP).
5.5 Structure simplifiée des entités correspondantes
On présente finalement, en relation avec la figure 11, les structures simplifiées d'une entité, par exemple un équipement, un serveur de contrôle, un contrôleur réseau, ou une entité relais selon un mode de réalisation de l'invention.
Comme illustré par la figure 11, une telle entité comprend au moins une mémoire 111 comprenant une mémoire tampon, au moins une unité de traitement 112, équipée par exemple d'une machine de calcul programmable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 113, mettant en œuvre des étapes d'au moins un procédé selon au moins un mode de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur 113 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 112.
Si l'entité est un équipement, le processeur de l'unité de traitement 112 met en œuvre des étapes du procédé de vérification de l'accessibilité de l'équipement pour l'acheminement de données à destination de l'équipement via au moins une tranche réseau, décrit précédemment, selon les instructions du programme d'ordinateur 113, pour :
- recevoir, via au moins un canal sécurisé entre l'équipement et au moins un serveur de contrôle, des informations relatives à au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter, - vérifier l'exécution de ladite au moins une action en utilisant lesdites informations.
Si l'entité est un serveur de contrôle, le processeur de l'unité de traitement 112 met en œuvre des étapes du procédé de gestion de l'accessibilité d'un équipement pour l'acheminement de données à destination de l'équipement via au moins une tranche réseau, décrit précédemment, selon les instructions du programme d'ordinateur 113, pour :
- obtenir des instructions comprenant au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter,
- générer au moins un message de vérification à partir desdites instructions,
- transmettre audit équipement, via un canal sécurisé entre ledit équipement et ledit serveur de contrôle, des informations relatives audit au moins un message de vérification.
Si l'entité est un contrôleur réseau, le processeur de l'unité de traitement 112 met en œuvre des étapes du procédé de contrôle de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, décrit précédemment, selon les instructions du programme d'ordinateur 113, pour :
- recevoir au moins un message de vérification en provenance d'un serveur de contrôle, ledit au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter,
- transmettre à au moins une entité relais sélectionnée ledit au moins un message de vérification. Si l'entité est une entité relais, le processeur de l'unité de traitement 112 met en œuvre des étapes du procédé d'exécution d'une vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement via au moins une tranche réseau, décrit précédemment, selon les instructions du programme d'ordinateur 113, pour :
- recevoir au moins un message de vérification en provenance d'un serveur de contrôle ou en provenance d'un contrôleur réseau du réseau auquel ladite entité relais est connectée, ledit au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement, via au moins une tranche réseau, à exécuter par ladite entité relais, transmettre, vers ledit équipement, ledit au moins un message de vérification.

Claims

REVENDICATIONS
1. Procédé de vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement via au moins une tranche réseau, comprenant :
- la réception (412), via au moins un canal sécurisé (50) entre ledit équipement et au moins un serveur de contrôle (45), d'informations relatives à au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement (41) via au moins une tranche réseau à exécuter,
- la vérification (414) de l'exécution de ladite au moins une action en utilisant lesdites informations.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend également la transmission (411), via ledit canal sécurisé (50), d'instructions comprenant au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter, et au moins l'une des informations suivantes :
- des informations d'identification de tranche réseau permettant d'identifier au moins une tranche réseau ou un type de tranche réseau à tester pour l'acheminement de données à destination dudit équipement,
- des informations d'identification d'un segment réseau permettant d'identifier au moins une entité relais à solliciter pour tester l'acheminement de données à destination dudit équipement.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend une étape préalable de sélection dudit au moins un serveur de contrôle tenant compte d'une contrainte sur une entité relais destinée à émettre ledit au moins un message de vérification.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend la réception (413) dudit au moins un message de vérification correspondant à ladite au moins une action à exécuter et en ce que ladite vérification met en œuvre une comparaison dudit au moins un message de vérification reçu avec lesdites informations relatives audit au moins un message de vérification correspondantes.
5. Procédé de gestion de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, mis en œuvre par un serveur de contrôle, comprenant :
- l'obtention (451) d'instructions comprenant au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter,
- la génération (452) d'au moins un message de vérification à partir desdites instructions, - la transmission (453) audit équipement, via un canal sécurisé (50) entre ledit équipement et ledit serveur de contrôle, d'informations relatives audit au moins un message de vérification.
6. Procédé selon la revendication 5, caractérisé en ce que ledit procédé comprend la transmission (456), vers ledit équipement, dudit au moins un message de vérification via au moins une tranche réseau ou un type de tranche réseau à tester.
7. Procédé selon la revendication 5, caractérisé en ce que ledit procédé comprend :
- la sélection (454') d'au moins une entité relais à partir desdites instructions,
- la transmission (456") à ladite au moins une entité relais dudit au moins un message de vérification.
8. Procédé selon la revendication 5, caractérisé en ce que ledit procédé comprend :
- la sélection (454) d'au moins une entité relais à partir desdites instructions,
- la sélection (455) d'au moins un contrôleur réseau, tenant compte d'une contrainte sur ladite au moins une entité relais à sélectionner,
- la transmission (456'), audit au moins un contrôleur réseau dudit au moins un message de vérification.
9. Procédé d'exécution d'une vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, mis en œuvre par une entité relais, comprenant :
- la réception (4411) d'au moins un message de vérification en provenance d'un serveur de contrôle, directement ou via un contrôleur réseau du réseau auquel ladite entité relais est connectée, ledit au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement, via au moins une tranche réseau, à exécuter par ladite entité relais,
- l'exécution de ladite au moins une action de vérification de l'accessibilité dudit équipement comprenant la transmission (4412), vers ledit équipement, dudit au moins un message de vérification.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ledit au moins un message de vérification appartient au groupe comprenant :
- une requête ICMP « Echo Request »,
- une requête I0AM,
- au moins un paquet UDP « Traceroute »,
- au moins un paquet LSP Ping,
- au moins un paquet SFC Ping.
11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que ledit canal sécurisé met en œuvre un protocole de transport sécurisé QUIC.
12. Équipement apte à vérifier son accessibilité pour l'acheminement de données à sa destination via au moins une tranche réseau, comprenant au moins un processeur configuré pour :
- recevoir, via au moins un canal sécurisé entre l'équipement et au moins un serveur de contrôle, des informations relatives à au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter,
- vérifier l'exécution de ladite au moins une action en utilisant lesdites informations.
13. Serveur de contrôle apte à gérer l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, comprenant au moins un processeur configuré pour :
- obtenir des instructions comprenant au moins une action de vérification de l'accessibilité dudit équipement via au moins une tranche réseau à exécuter,
- générer au moins un message de vérification à partir desdites instructions,
- transmettre audit équipement, via un canal sécurisé entre ledit équipement et ledit serveur de contrôle, des informations relatives audit au moins un message de vérification.
14. Entité relais apte à exécuter une vérification de l'accessibilité d'un équipement pour l'acheminement de données à destination dudit équipement, via au moins une tranche réseau, comprenant au moins un processeur configuré pour :
- recevoir au moins un message de vérification en provenance d'un serveur de contrôle directement ou via un contrôleur réseau du réseau auquel ladite entité relais est connectée, ledit au moins un message de vérification correspondant à au moins une action de vérification de l'accessibilité dudit équipement, via au moins une tranche réseau, à exécuter par ladite entité relais,
- exécuter ladite au moins une action de vérification de l'accessibilité dudit équipement en transmettant, vers ledit équipement, ledit au moins un message de vérification.
EP24789877.8A 2023-10-12 2024-10-11 Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants Pending EP4792557A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2310989A FR3154268A1 (fr) 2023-10-12 2023-10-12 Procédés de vérification, de gestion, de contrôle, d’exécution d’une vérification de l’accessibilité d’un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d’ordinateur correspondants.
PCT/EP2024/078682 WO2025078600A1 (fr) 2023-10-12 2024-10-11 Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4792557A1 true EP4792557A1 (fr) 2026-08-19

Family

ID=89321876

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24789877.8A Pending EP4792557A1 (fr) 2023-10-12 2024-10-11 Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants

Country Status (4)

Country Link
EP (1) EP4792557A1 (fr)
CN (1) CN122070717A (fr)
FR (1) FR3154268A1 (fr)
WO (1) WO2025078600A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200079352A (ko) * 2016-02-16 2020-07-02 아이디에이씨 홀딩스, 인크. 네트워크 슬라이싱 동작
CN110463245B (zh) * 2017-03-17 2022-04-22 华为技术有限公司 用于基于切片的网络中的无线接入网络(ran)配置的技术

Also Published As

Publication number Publication date
CN122070717A (zh) 2026-05-19
FR3154268A1 (fr) 2025-04-18
WO2025078600A1 (fr) 2025-04-17

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE