FR3140501A1

FR3140501A1 - Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d’ordinateur correspondants.

Info

Publication number: FR3140501A1
Application number: FR2210007A
Authority: FR
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2022-09-30
Filing date: 2022-09-30
Publication date: 2024-04-05
Also published as: WO2024068725A1

Abstract

Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d’ordinateur correspondants. L’invention concerne un procédé de gestion du trafic de données entre une entité source (11) et une entité destinataire (12), mettant en œuvre : la sélection (13), pour ladite entité source et ladite entité destinataire, d’au moins une politique d’ordonnancement de paquets de données applicatives échangés entre ladite entité source et ladite entité destinataire, tenant compte d’au moins une caractéristique d’une application associée auxdites données applicatives, l’établissement (14) d’au moins une connexion entre ladite entité source et ladite entité destinataire, sur laquelle est mise en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée. Figure pour l’abrégé : figure 1

Description

Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d’ordinateur correspondants.

1. Domaine de l’invention

Le domaine de l’invention est celui des communications au sein d’un réseau, par exemple un réseau informatique mettant en œuvre le protocole IP tel qu’un réseau WAN (pour « Wide Area Network » en anglais).

Plus précisément, l’invention propose une solution pour améliorer l’échange de données entre une entité source et une entité destinataire connectées audit réseau.

L’invention trouve notamment, mais non exclusivement, une application dans un réseau reposant sur une architecture SD-WAN (en anglais « Software-Defined Wide Area Network »).

2. Art antérieur

Un réseau WAN peut notamment être utilisé pour interconnecter les différents sites d’une entreprise, chaque site hébergeant au moins un réseau local (en anglais LAN, pour « Local Area Network »). Classiquement, un tel réseau WAN repose sur l’utilisation du protocole MPLS (en anglais « Multi Protocol Label Switching », en français « commutation multi protocolaire par labels »), qui supporte les communications établies entre les différents sites et permet par exemple l’accès à des applications locales hébergées dans un serveur de l’entreprise depuis l’un ou l’autre des sites distants.

Des phénomènes de congestion peuvent apparaître dans le réseau WAN en fonction des usages, des comportements des utilisateurs ou encore de la nature des applications ou contenus auxquels les utilisateurs souhaitent accéder. Ces applications ou contenus peuvent être hébergés dans des infrastructures « cloud ».

De nouvelles techniques d’automatisation des procédures de production et d’exploitation des ressources réseau ont été récemment introduites. En particulier, des architectures de réseaux SDN (en anglais « Software-Defined Networks ») ont été déployées, dans lesquelles une logique de calcul, typiquement centralisée (par exemple un contrôleur SDN), est responsable de l’allocation dynamique des ressources impliquées dans l’acheminement du trafic ou dans la fourniture du ou des services de communication supportés par le réseau. Ces techniques d’automatisation permettent en particulier d’améliorer significativement la flexibilité de l’usage des ressources et de leur adaptabilité aux besoins des utilisateurs.

Une telle souplesse permet ainsi de faciliter l’allocation de ressources réseau à la demande, de gérer les flux applicatifs d’une entreprise ou encore de préserver la continuité d’un service de communication en cas de rupture d’une ressource de transmission, par exemple.

Des services de communication tels que des services de réseaux privés virtuels (VPN, en anglais « Virtual Private Network ») peuvent notamment être déployés sur des infrastructures SD-WAN qui facilitent l’établissement de tunnels IPsec entre les sites d’une entreprise interconnectés au travers du VPN, par exemple.

De la même façon, les architectures SD-WAN permettent une gestion facilitée des flux applicatifs d’une entreprise dont certaines des ressources peuvent être hébergées dans des infrastructures cloud privées, publiques ou hybrides.

Toutefois, la gestion du trafic à destination ou en provenance d’un site d’une entreprise est souvent conditionnée par l’évolution des conditions d’accès au réseau, la disponibilité d’un ou plusieurs chemins d’accès au réseau, l’évolution de la volumétrie de trafic au cours du temps, les conditions tarifaires d’accès au(x) réseaux ou d’établissement des facilités de transport des données, la confidentialité des informations échangées entre sites, etc.

Or, de tels paramètres ne sont pas toujours connus de la logique de calcul exploitée par l’opérateur de l’infrastructure SD-WAN, ce qui peut notamment conduire à des ingénieries non optimisées pour l’acheminement du trafic des données.

Des solutions ont ainsi été proposées pour une gestion dite prédictive de la qualité d’expérience (« Predictive management of Quality of Expérience », en anglais). Ces solutions reposent sur l’utilisation de techniques d’intelligence artificielle (IA) telles que l’apprentissage machine (« Machine Learning » en anglais) et font généralement intervenir des entités externes à un réseau, telles qu’un contrôleur SDN.

Toutefois, ces solutions supposent l’échange d’une volumétrie de données de télémétrie importante, qui pourraient être utilisées à des fins malveillantes. De plus, du fait de l’utilisation d’entités externes notamment, l’agrégation et la centralisation des données présentent également des failles de sécurité qui pourraient être exploitées à des fins de piratage ou de profilage. Ces ingénieries présentent ainsi des problèmes de sécurité et de confidentialité.

Il existe donc un besoin pour une nouvelle technique de gestion du trafic de données, pouvant notamment être appliquée à la gestion du trafic acheminé sur une infrastructure SD-WAN, et qui permet de s’affranchir d’au moins certains inconvénients de l’art antérieur.

3. Exposé de l’invention

L’invention propose une solution sous la forme d’un procédé de gestion du trafic de données entre une entité source et une entité destinataire, mettant en œuvre :

la sélection, pour ladite entité source et ladite entité destinataire, d’au moins une politique d’ordonnancement (« scheduling » en anglais) de paquets de données applicatives échangés entre ladite entité source et ladite entité destinataire, tenant compte d’au moins une caractéristique d’une application associée auxdites données applicatives,

ladite au moins une politique d’ordonnancement de paquets sélectionnée étant supportée par ladite entité source et par ladite entité destinataire,

l’établissement d’au moins une connexion entre ladite entité source et ladite entité destinataire, sur laquelle est mise en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.

Un tel procédé de gestion du trafic de données selon au moins un mode de réalisation de l’invention permet ainsi de prendre en compte la nature des applications ou des flux de données échangés entre une entité source et une entité destinataire pour choisir la politique d’ordonnancement de paquets à mettre en place pour une connexion donnée (dite de référence) établie entre cette entité source et cette entité destinataire. Cette approche est différente de l’état de l’art où la configuration de la politique d’ordonnancement de paquets est locale à un équipement et ne peut pas être négociée par connexion ni à l’échelle du réseau reliant l’entité source et l’entité destinataire.

En effet, de telles applications peuvent avoir des caractéristiques particulières, par exemple un type d’applications, des contraintes ou besoins en termes de qualité de service ou d’expérience, ou en termes de sécurité (délai de transit maximal entre deux réseaux locaux associé chacun à un site d’une entreprise par exemple, taux de perte de paquets, préservation de la confidentialité des informations échangées entre certains sites, etc.). Elles peuvent également avoir des contraintes ou besoins en termes de tarifs ou de consommation (optimisation tarifaire par accès, suivi de consommation, etc.).

Ainsi, la prise en compte d’au moins une caractéristique liée à une application permet de sélectionner une politique d’ordonnancement de paquets adaptée au profil de trafic caractéristique de ladite application, et destinée à optimiser l’acheminement des données caractéristiques de cette application entre l’entité source et l’entité destinataire.

On note que la solution proposée est également applicable aux connexions point-à-multipoints (par exemple dans le cas d’un service de diffusion de programmes télévisés reposant sur le mode transmission multicast), ou multipoints-à-multipoints (par exemple dans le cas d’un service de visioconférence). Dans ce cas, la connexion de référence peut être établie entre au moins une entité source et au moins une entité destinataire.

Selon un mode de réalisation particulier, des politiques d’ordonnancement de paquets locales à chaque réseau sont sélectionnées (et non une politique commune appliquée à l’ensemble des trafics acheminés sur un réseau étendu de type WAN), ce qui permet de conserver une certaine maîtrise de l’acheminement des données et des routes sélectionnées pour les acheminer entre les différents sites. Ces politiques d’ordonnancement de paquets locales peuvent ainsi trouver une résonance dans les choix d’ingénierie liés à l’établissement des ressources de transport inter-sites.

Par exemple, de telles politiques d’ordonnancement de paquets appartiennent au groupe comprenant :

une politique de gestion des chemins disponibles (« Path management », en anglais),
une politique de gestion de la congestion (« Congestion management », en anglais),
une politique de réassemblage des paquets (« Packet reassembly », en anglais),
une politique de réordonnancement des paquets (« Packet reordering », en anglais),
etc.

On note qu’un tel procédé selon l’invention peut être mis en œuvre indifféremment par l’entité source et/ou par l’entité destinataire.

Plus généralement, un tel procédé est applicable à tout réseau de communication justifiant la mise en place de politiques d’ordonnancement de paquets (destinées à optimiser l’acheminement des paquets) capables de prendre en compte les contraintes ou besoins applicatifs évoqués précédemment. En particulier, un tel procédé peut être appliqué par un réseau étendu reposant sur une architecture SD-WAN.

Un tel procédé de gestion de trafic, permettant par exemple d’améliorer la qualité d’expérience utilisateur, est appelé SCHEMATICS (« Procedure for SCHEdule Management for Technically-advanced InfrastruCtureS ») dans la suite de la description.

Une politique d’ordonnancement de paquets de données est par la suite appelée PSS (pour « Packet Schedule SCHEMATICS »).

Dans un mode de réalisation particulier, l’entité source peut transmettre à l’entité destinataire une liste d’au moins une politique d’ordonnancement de paquets supportée par ladite entité source.

Dans un autre mode de réalisation (qui peut être combiné au mode de réalisation particulier ci-dessus), l’entité source reçoit, en provenance de l’entité destinataire, une liste d’au moins une politique d’ordonnancement de paquets supportée par ladite entité destinataire.

L’entité source et/ou l’entité destinataire peuvent ainsi vérifier si elles supportent au moins une politique d’ordonnancement de paquets commune. Les deux entités peuvent aussi indiquer une préférence qui peut être prise en compte pour la sélection d’une politique d’ordonnancement pour une connexion en cours.

Par exemple, selon un mode de réalisation particulier, l’entité source peut vérifier si l’entité destinataire supporte une politique d’ordonnancement de paquets privilégiée par l’entité source. Si ce n’est pas le cas, l’entité source peut vérifier si l’entité destinataire supporte au moins une politique d’ordonnancement de paquets supportée par l’entité source. Si tel n’est pas le cas, le procédé de gestion selon l’invention ne peut pas être mis en œuvre.

L’entité source, resp. destinataire, peut ainsi stocker dans une mémoire une table consignant l’ensemble des politiques d’ordonnancement de paquets supportées par l’entité destinataire, resp. source. Cette table est maintenue par l’entité source (resp. destinataire).

De telles listes peuvent notamment être transmises en utilisant un protocole de la couche transport entre l’entité source et l’entité destinataire. Par exemple, les protocoles QUIC, TCP (avec ou sans l’option MPTCP) peuvent être utilisés. Ces paramètres peuvent également être échangés en utilisant un protocole tel que GRE, GTP, IKE, etc.

Si le protocole QUIC est utilisé, une nouvelle trame QUIC est définie pour inclure les informations PSS. Cette nouvelle trame QUIC, appelée trame PSS, peut être envoyée par l’entité source, en utilisant une connexion sécurisée entre l’entité source et l’entité destinataire, pour déclencher l’envoi par l’entité destinataire de la liste de la ou des PSS supportées par l’entité destinataire.

Dans un mode de réalisation particulier, ladite entité source, resp. destinataire, transmet un paramètre signalant à l’entité destinataire, resp. source, qu’elle est apte à mettre en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.

Par exemple, un tel paramètre prend une première valeur pour indiquer que l’entité qui transmet ce paramètre (entité source ou entité destinataire) supporte la procédure de sélection d’au moins une politique d’ordonnancement de paquets, et une deuxième valeur pour indiquer que l’entité qui transmet ce paramètre (entité source ou entité destinataire) ne supporte pas la procédure de sélection d’au moins une politique d’ordonnancement de paquets.

En variante, l’absence d’un tel paramètre signifie que la procédure de sélection d’au moins une politique d’ordonnancement de paquets n’est pas supportée par l’entité ayant émis le message.

Un tel paramètre peut notamment être transmis en utilisant un protocole de la couche transport entre l’entité source et l’entité destinataire. Le même protocole parmi ceux évoqués précédemment à titre d’exemples et utilisés pour transmettre les listes proposées ci-dessus peut être exploité.

Si le protocole QUIC est utilisé, un tel paramètre peut être un paramètre de transport QUIC appelé ici « Customized_PSS », valorisé par exemple à « 0x1 » pour indiquer que l’entité émettrice de la trame QUIC PSS comportant un tel paramètre supporte le procédé selon l’invention. Le paramètre « Customized_PSS » peut être valorisé par exemple à « 0x0 » pour indiquer que l’entité émettrice de la trame QUIC PSS ne supporte pas le procédé selon l’invention.

Dans un mode de réalisation particulier, ladite connexion comprend au moins deux sous-connexions associées chacune à un chemin distinct entre ladite entité source et ladite entité destinataire, et ladite entité source envoie lesdites données applicatives sur au moins une desdites sous-connexions en tenant compte de ladite au moins une politique d’ordonnancement de paquets sélectionnée pour ladite connexion.

Selon ce mode de réalisation particulier, l’établissement de sous-connexions correspondant à la connexion de référence établie entre les entités source et destinataire, également appelée connexion à multi-chemins, permet de basculer ou de rediriger tout ou partie du trafic vers un chemin ou un autre, par exemple en fonction des objectifs de qualité de service ou de qualité d’expérience fixés/observés pour une application, ou en fonction de l’évolution des conditions d’acheminement des données applicatives (dégradation du temps de transit, etc.).

Par exemple, selon la politique d’ordonnancement de paquets sélectionnée, différentes procédures pour le traitement des paquets de données applicatives peuvent être mises en œuvre lors de l’établissement de la connexion, permettant d’envoyer le trafic sur l’un et/ou l’autre des chemins.

Dans un mode de réalisation particulier, le procédé de gestion du trafic de données comprend la réception, par l’entité source et/ou l’entité destinataire, d’au moins une information de classification de trafic permettant d’associer au moins une politique d’ordonnancement de paquets à un type d’application.

De telles informations de classification permettent notamment d’associer une application, ou plus généralement un type d’application, à au moins une politique d’ordonnancement de paquets qui permet de satisfaire les besoins et/ou contraintes d’un tel type d’application (par exemple en termes de qualité de service ou d’expérience). L’étape de sélection d’une politique d’ordonnancement de paquets peut notamment tenir compte de telles informations de classification. Une application peut communiquer via une API transport dédiée pour faciliter la sélection d’une politique PSS à mettre en œuvre pour l’établissement d’une connexion de transport sous-jacente.

Selon une caractéristique particulière, le mode d’application de ladite au moins une politique d’ordonnancement de paquets sélectionnée (c'est-à-dire la façon de traiter les paquets de données applicatives, par exemple la configuration et gestion de files d’attente) est mis à jour périodiquement et/ou en fonction d’une évolution des conditions d’acheminement des données applicatives échangées entre ladite entité source et ladite entité destinataire.

De cette façon, il est possible d’exécuter des actions conformes à la politique d’ordonnancement de paquets sélectionnée, par exemple pour basculer ou rediriger le trafic vers un chemin ou un autre, ou marquer certains paquets de données applicatives, notamment en fonction des objectifs de qualité de service ou de qualité d’expérience fixés pour l’application considérée.

Selon un premier exemple de mise en œuvre, l’entité source est un premier équipement connecté à un réseau local, et l’entité destinataire est un deuxième équipement connecté à un réseau externe. En variante, l’entité source est un deuxième équipement connecté à un réseau externe et l’entité destinataire est un premier équipement connecté à un réseau local.

Selon ce premier exemple, la solution proposée est directement mise en œuvre par le premier équipement, par exemple un terminal, et le deuxième équipement, par exemple un serveur distant.

Selon un deuxième exemple de mise en œuvre, l’entité source est un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant les données applicatives en provenance d’un premier équipement connecté au réseau local, et l’entité destinataire est un deuxième équipement connecté à au moins un réseau externe. En variante, l’entité source est un deuxième équipement connecté à au moins un réseau externe et l’entité destinataire est un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant les données applicatives vers un premier équipement connecté au réseau local. On note que l’entité source et l’entité destinataire peuvent être connectées à des réseaux externes distincts.

Selon ce deuxième exemple, la solution proposée est mise en œuvre par un équipement d’accès (connecté au même réseau que le premier équipement) et le deuxième équipement, par exemple un serveur distant, un autre équipement d’accès, un autre terminal, etc. Ce deuxième exemple peut notamment être mis en œuvre lorsque le premier équipement ne supporte pas la procédure de sélection d’au moins une politique d’ordonnancement de paquets.

Selon un troisième exemple de mise en œuvre, l’entité source est un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant les données applicatives en provenance d’un premier équipement connecté audit réseau local, et l’entité destinataire est un concentrateur, acheminant les données applicatives vers un deuxième équipement connecté à au moins un réseau externe. En variante, l’entité source est un concentrateur, acheminant les données applicatives en provenance d’un deuxième équipement connecté à au moins un réseau externe et l’entité destinataire est un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant les données applicatives vers un premier équipement connecté audit réseau local. A nouveau, l’entité source et l’entité destinataire peuvent être connectées à des réseaux externes distincts.

Selon ce troisième exemple, la solution proposée est mise en œuvre par un équipement d’accès (connecté au même réseau que le premier équipement, par exemple un terminal) et un concentrateur en communication avec un deuxième équipement, par exemple un serveur distant, un autre terminal, etc. Un tel concentrateur permet notamment d’agréger les sous-connexions entre l’équipement d’accès et le concentrateur, et de terminer ces sous-connexions. Ce troisième exemple peut notamment être mis en œuvre lorsque ni le premier équipement, ni le deuxième équipement ne supportent la procédure de sélection d’au moins une politique d’ordonnancement de paquets.

Selon encore un autre exemple, la solution proposée est mise en œuvre par un concentrateur et un serveur distant.

En particulier, si l’équipement d’accès maintient une connexion de longue durée avec une entité destinataire, les étapes de transmission et/ou réception de listes de PSS, et par suite de sélection d’au moins une PSS, peuvent être mises en œuvre lors d’un changement d’application, ou de façon régulière (par exemple toutes les 24h), ou en tenant compte d’une évolution des conditions d’acheminement des données applicatives échangées entre l’entité source et l’entité destinataire, etc.

Selon un mode de réalisation particulier, l’équipement d’accès établit au moins deux connexions entre ladite entité source et ladite entité destinataire, mettant chacune en œuvre une politique d’ordonnancement de paquets distincte sélectionnée en tenant compte d’au moins une caractéristique d’une application.

Selon ce mode de réalisation particulier, l’équipement d’accès peut ainsi établir une connexion pour une application, avec une unique politique d’ordonnancement de paquets pour la connexion considérée. En variante, l’équipement d’accès peut établir une connexion pour plusieurs applications, avec différentes politiques d’ordonnancement de paquets pour la connexion considérée. En d’autres termes, plusieurs flux applicatifs distincts peuvent être acheminés selon une même connexion entre entités source et destinataire, tout en faisant l’objet de politiques d’ordonnancement distinctes.

Dans un mode de réalisation particulier, l’équipement d’accès reçoit des informations relatives à au moins un desdits réseaux externes en provenance d’au moins un autre équipement d’accès connecté au réseau local et ayant établi une connexion avec le serveur distant ou le concentrateur.

De cette façon, l’équipement d’accès selon un mode de réalisation de l’invention peut collecter des informations caractéristiques du trafic transitant par les autres équipements d’accès. De telles informations peuvent notamment être utilisées par l’équipement d’accès selon un mode de réalisation de l’invention pour influencer la procédure (ou le mode) d’application de la politique d’ordonnancement de paquets sélectionnée pour l’équipement d’accès et le serveur – si le serveur supporte la procédure de sélection d’au moins une politique d’ordonnancement de paquets, ou le concentrateur – si le serveur ne supporte pas la procédure de sélection d’au moins une politique d’ordonnancement de paquets.

On considère par exemple que les différents équipements d’accès connectés au même réseau local peuvent exploiter un canal « point-à-multipoint » établi par exemple selon un mode de transmission multicast, pour partager entre eux les informations relatives aux différents réseaux externes.

Dans un autre mode de réalisation, l’équipement d’accès transmet à un contrôleur des informations relatives à au moins un desdits réseaux externes, ledit contrôleur recevant des informations relatives à au moins un desdits réseaux externes en provenance d’au moins un autre équipement d’accès connecté audit réseau local et ayant établi une connexion avec le serveur distant ou le concentrateur.

De cette façon, un contrôleur peut collecter des informations caractéristiques du trafic transitant par les autres équipements d’accès.

On considère par exemple que les différents équipements d’accès connectés au même réseau local établissent une connexion avec le contrôleur pour partager les informations relatives aux différents réseaux externes. Un tel contrôleur est par exemple un contrôleur SDN.

Dans un mode de réalisation particulier, le procédé selon l’invention sélectionne un desdits équipements d’accès pour acheminer lesdites données applicatives en provenance dudit premier équipement, resp. vers ledit premier équipement, en tenant compte desdites informations relatives à au moins un desdits réseaux externes.

Une telle étape peut notamment être mise en œuvre par un équipement d’accès connecté au réseau local ou par le contrôleur, par exemple lorsque plusieurs équipements d’accès supportent la procédure de sélection d’au moins une politique d’ordonnancement de paquets selon un mode de réalisation de l’invention.

En particulier, la sélection d’un desdits équipements d’accès tient également compte d’un identifiant associé auxdites données applicatives.

Par exemple, un identifiant d’application est associé aux données applicatives liées à une application d’un certain type, présentant des contraintes particulières (par exemple faible latence). Ainsi et par exemple, toutes les données applicatives identifiées par le même identifiant d’application transiteront par le même équipement d’accès.

Dans d’autres modes de réalisation, l’invention concerne une entité source et/ou destinataire correspondante.

Une telle entité dite source, resp. destinataire, apte à communiquer avec une entité destinataire, resp. source, comprend au moins un processeur configuré pour :

sélectionner, pour ladite entité source et ladite entité destinataire, au moins une politique d’ordonnancement de paquets de données applicatives échangés entre ladite entité source et ladite entité destinataire, tenant compte d’au moins une caractéristique d’une application associée auxdites données applicatives,

établir au moins une connexion entre ladite entité source et ladite entité destinataire mettant en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.

Une telle entité est notamment adaptée pour mettre en œuvre le procédé de gestion de trafic de données décrit précédemment. L’entité source, resp. destinataire, pourra bien sûr supporter les différentes caractéristiques relatives au procédé selon l’invention, qui peuvent être combinées ou prises isolément. Ainsi, les caractéristiques et avantages de l’entité source, resp. destinataire sont les mêmes que ceux du procédé selon au moins un mode de réalisation de l’invention décrit précédemment. Par conséquent, ils ne sont pas détaillés plus amplement.

Un mode de réalisation de l’invention vise aussi à protéger un ou plusieurs programmes d’ordinateur comportant des instructions adaptées à la mise en œuvre d’au moins une étape du procédé selon au moins un mode de réalisation de l’invention tel que décrit 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.

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 illustre les principales étapes mises en œuvre par une entité source et/ou destinataire selon au moins un mode de réalisation de l’invention ;
la illustre un exemple de réseau WAN dans lequel peut être mise en œuvre l’invention ;
la illustre un exemple de canal point-à-multipoint établi pour partager des informations entre différents équipements d’accès connectés à un même réseau local,
les figures 4A à 4B illustrent la sélection d’un équipement d’accès comme point de sortie en tenant compte d’informations transportées dans le canal de la ,
la illustre la sélection d’un équipement d’accès comme point de sortie en tenant d’un identifiant d’application,
la illustre un exemple de canal point-à-point établi pour partager des informations entre deux équipements d’accès connectés à un même réseau local,
les figures 7A à 7B illustrent la sélection d’un équipement d’accès comme point de sortie en tenant compte des informations transportées dans le canal de la ,
la présente la structure simplifiée d’une entité source et/ou destinataire selon un mode de réalisation particulier de l’invention.

5. Description d’un mode de réalisation de l’invention

5.1 Principe général

Le principe général de l’invention repose sur la mise en œuvre d’une politique d’ordonnancement de paquets spécifique sur une connexion établie entre une entité source et une entité destinataire, dite connexion de référence. Cette politique d’ordonnancement repose sur un mécanisme de gestion de paquets de données et de contrôle de congestion (proche d’un « scheduler » en anglais). Une telle politique d’ordonnancement de paquets est choisie en tenant compte d’une application générant du trafic de données applicatives entre l’entité source et l’entité destinataire.

On note que de telles données applicatives représentent les données échangées entre un client (par exemple un terminal, un équipement d’accès) et un serveur distant. L’échange de ces données applicatives repose donc sur l’établissement d’une connexion spécifique, également appelée connexion « applicative », qui peut être différente de la connexion de référence selon l’invention.

L’approche proposée repose notamment sur l’utilisation d’une politique d’ordonnancement de paquets activée pour une connexion de référence établie entre l’entité source et l’entité destinataire. Grâce à cette approche, les politiques d’ordonnancement de paquets sont caractéristiques des différentes applications qui font l’objet d’un échange de données entre les entités source et destinataire, ce qui permet un niveau de granularité adapté à la variété de ces applications et des profils de trafic. Cette configuration n’est donc pas « globale », c’est-à-dire qu’elle n’est pas générique (c’est-à-dire quels que soient le nombre et la nature des applications qui motivent l’échange de données entre des entités source et destinataire), ni systémique (c’est-à-dire que l’application des politiques d’ordonnancement est caractéristique de la nature de ces différentes applications, mais également des conditions d’accès aux réseaux et de l’évolution de ces conditions). En d’autres termes, différentes politiques d’ordonnancement de paquets peuvent être dynamiquement négociées et mises en œuvre pour différentes connexions de référence établies entre entités connectées à au moins un réseau. En particulier, différentes politiques d’ordonnancement de paquets peuvent être mises en œuvre pour différentes applications générant du trafic entre une même entité source et une même entité destinataire, et qui est acheminé selon différentes routes qui connectent les entités source et destinataire.

Si l’on se place dans le contexte d’un réseau WAN interconnectant plusieurs réseaux locaux hébergés dans des sites distincts d’une entreprise par exemple, la solution proposée contribue à l’optimisation de l’usage des ressources intra- et inter-sites, de sorte que l’acheminement du trafic puisse refléter la mise en place dynamique de politiques d’ordonnancement de paquets en adéquation avec les caractéristiques des différentes applications susceptibles de générer un trafic intra- ou inter-sites (notamment en adéquation avec les exigences en termes de qualité de service et/ou de sécurité de ces applications).

Selon au moins un mode de réalisation, la solution proposée contribue à l’amélioration de la qualité d’expérience telle que perçue par un utilisateur d’un service de connectivité. Cette solution permet en particulier de détecter (et par conséquent d’anticiper) d’éventuelles dégradations de la qualité d’expérience qui pourraient par exemple être provoquées par des défaillances du réseau (rupture ou surcharge de liens de communication, surcharge d’équipement de commutation, etc.). De plus, la solution proposée ne remet pas en cause l’intégrité d’informations sensibles et respecte leur confidentialité. En effet, aucune information n’est partagée avec une entité externe pour la gestion de la qualité d’expérience perçue par un utilisateur localisé dans un site donné.

La illustre les principales étapes mises en œuvre par une entité source 11 et/ou une entité destinataire 12 selon au moins un mode de réalisation de l’invention, pour la gestion du trafic de données entre l’entité source 11 et l’entité destinataire 12.

Une telle technique de gestion du trafic de données met en œuvre une sélection 13, pour l’entité source 11 et l’entité destinataire 12, d’au moins une politique d’ordonnancement de paquets (notée par exemple PSS pour « Packet Scheduler SCHEMATICS ») de données applicatives, échangés entre l’entité source 11 et l’entité destinataire 12, en tenant compte d’au moins une caractéristique d’une application associée aux données applicatives. Par exemple, une telle caractéristique est de type délai de transit maximal, taux de perte de paquet maximal, préservation de la confidentialité des informations échangées, etc.

En particulier, ladite au moins une politique d’ordonnancement de paquets sélectionnée est supportée par l’entité source 11 et par l’entité destinataire 12. Par exemple, une étape préalable de vérification des capacités de l’entité source 11 et/ou de l’entité destinataire 12 peut être mise en œuvre pour déterminer la ou les politiques d’ordonnancement de paquets supportées par l’entité source 11 et par l’entité destinataire 12.

La technique de gestion du trafic de données selon l’invention met également en œuvre l’établissement 14 d’au moins une connexion de référence entre l’entité source 11 et l’entité destinataire 12. Une telle connexion de référence est notamment configurée, établie et exploitée pour mettre en œuvre la ou les politiques d’ordonnancement de paquets sélectionnées. La mise en œuvre de ces politiques peut être réalisée au niveau de la couche responsable de l’établissement de ladite connexion de référence (par ex. TCP, QUIC) ou à d’autres niveaux (par ex. gestion des files d’attente dans les cartes d’interfaces réseau, gestion des chemins IP). Lorsque des politiques d’ordonnancement sont configurées pour une connexion de référence mais leur mise en œuvre ne relève pas (exclusivement) de la responsabilité de la couche responsable de l’établissement de ladite connexion de référence, les identifiants de ces politiques peuvent être exposés via des API dédiées à l’accès aux modules responsables de l’application de ces politiques.

Par exemple, une telle connexion de référence utilise un protocole de la couche transport, comme le protocole QUIC qui permet d’améliorer la sécurité des échanges entre l’entité source et l’entité destinataire. Dans d’autres modes de réalisation, la connexion de référence peut reposer sur l’utilisation d’un autre protocole (par exemple, TCP (avec ou sans l’option MPTCP), GRE, GTP, IKE).

Comme indiqué précédemment, selon un premier exemple, l’entité source (resp. destinataire) peut être un premier équipement, par exemple un terminal, connecté à un réseau local, et l’entité destinataire (resp. source) peut être un deuxième équipement, connecté à au moins un réseau externe, par exemple un serveur distant, un deuxième terminal, etc. Selon un deuxième exemple, l’entité source (resp. destinataire) peut être un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant des données applicatives en provenance de (resp. vers) un premier équipement connecté au réseau local, et l’entité destinataire (resp. source) peut être un deuxième équipement connecté à au moins un réseau externe, par exemple un serveur distant, un deuxième terminal, etc. Selon un troisième exemple, l’entité source (resp. destinataire) peut être un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant les données applicatives en provenance de (resp. vers) un premier équipement connecté au réseau local, et l’entité destinataire (resp. source) peut être un concentrateur, acheminant les données applicatives vers (resp. en provenance de) un deuxième équipement connecté à au moins un réseau externe.

Par la suite, aucune hypothèse n’est faite quant à la nature des entités impliquées (terminaux fixes, terminaux mobiles, CPE (en anglais « Customer Premises Equipment »), STB (en anglais « Set-Top Box » ou décodeur TV), point d’accès (« hotspot » par exemple), etc.), quant à l’architecture d’au moins un réseau local auquel au moins l’une de ces entités est connectée, quant à l’architecture d’un réseau étendu qui connecte au moins un réseau local auquel au moins l’une de ces entités est connectée (infrastructure fixe ou mobile, infrastructure publique ou privée, etc.), quant à la nature du réseau support des communications établies entre réseaux locaux ou des communications établies sur le réseau Internet, etc. Par exemple, le réseau local ou étendu peut être un réseau domestique, un réseau d’entreprise, un réseau d’un campus universitaire, un réseau industriel qui connecte les robots d’un site ou qui interconnecte plusieurs sites de production, etc. De même, aucune hypothèse n’est faite quant à la nature de la ou des applications. Une connectivité IP peut notamment être fournie via un réseau filaire, ou sans fil (par exemple 5G, Beyond 5G (B5G), 6G), ou les deux.

5.2 Exemple de mise en œuvre

5.2.1 Réseau étendu

On présente ci-après un exemple détaillé de mise en œuvre de l’invention.

On considère par exemple un réseau WAN tel qu’illustré en interconnectant au moins un réseau LAN 21 (associé par exemple à un site d’entreprise #i) et un ou plusieurs réseaux externes 221, 222, 22j, également appelés réseaux d’accès.

Un ou plusieurs terminaux, ou hôtes, H1, H2, H3 sont connectés au LAN 21. Un ou plusieurs équipements d’accès, ou « Customer Equipment », CE1, CEk sont également connectés au LAN 21. Ces équipements d’accès permettent de raccorder le LAN 21 à l’un au moins des réseaux externes 221, 222, 22j, auquel peut être connecté un serveur S.

Par exemple :

un ou plusieurs équipements d’accès peuvent être utilisés pour connecter un réseau local à un même réseau externe : par exemple les équipements d’accès CE1 et CEk permettent de raccorder le réseau local 21 au réseau externe Net. #2 222,
un même équipement d’accès peut être utilisé pour connecter un réseau local à plusieurs réseaux d’accès : par exemple l’équipement d’accès CE1 permet de raccorder le réseau local 21 aux réseaux externes Net. #1 221 et Net. #2 222,
un ou plusieurs équipements d’accès peuvent être utilisés pour connecter un réseau local à plusieurs réseaux d’accès : par exemple les équipements d’accès CE1 et CEk permettent de raccorder le réseau local 21 aux réseaux externes Net. #1 221, Net. #2 222 et Net. #j 22j.

Par la suite, le terme « CE » est utilisé pour dénoter tout équipement connecté à un réseau local et qui permet de raccorder ledit réseau local à au moins un réseau (d’accès) externe. Un CE peut notamment être un routeur, ou un équipement qui se contente d’acheminer le trafic à destination (« forwarder », en anglais) ou en provenance du réseau local.

Un CE peut notamment être placé sous la responsabilité d’exploitation de l’administrateur du réseau local ou celle d’un opérateur de l’un des réseaux externes, etc.

Dans un mode de réalisation particulier, au moins l’un des réseaux externes 221, 222, 22j peut être un réseau d’accès filaire, un réseau d’accès cellulaire (5G, B5G, 6G, etc.), un réseau de transit, etc.

En particulier, les réseaux externes peuvent notamment fournir une connectivité IP globale (permettant notamment d’accéder à Internet) ou une connectivité restreinte (par exemple aux seuls sites d’une même entreprise, à l’accès aux ressources hébergées dans des infrastructures « cloud » privées ou publiques, etc.). Parmi ces différents accès, un ou plusieurs peuvent être dédiés au raccordement d’un seul site (c’est le cas fréquent d’entreprises qui souhaitent bénéficier d’une connectivité exclusive et non partagée avec d’autres entités). On note par ailleurs que ces différents accès peuvent être exploités par un même opérateur ou par des opérateurs distincts.

Si l’on considère un réseau WAN qui connecte plusieurs réseaux LAN hébergés sur des sites distincts d’une même entreprise, les communications entre les sites de l’entreprise peuvent être de différents types :

« any-to-any » : les différents sites peuvent communiquer entre eux sans aucune restriction,
« hub-and-spoke » : les sites dits « Spoke » peuvent communiquer seulement avec des sites dits « Hub » alors que les sites « Hub » peuvent communiquer directement entre eux,
« hub-spoke-disjoint » : ce mode est similaire au mode « hub-and-spoke » excepté que les « Hub » ne peuvent pas communiquer entre eux.

Ces choix d’ingénierie peuvent être déformés selon la nature du trafic susceptible d’être échangé entre les sites, des politiques de priorisation de trafic, l’ingénierie d’accès aux ressources internes de l’entreprise lorsqu’un utilisateur est en déplacement, etc.

L’invention trouve notamment des applications dans ces différents contextes.

Dans un mode de réalisation particulier, un CE peut communiquer via tout ou partie de ces différents réseaux externes avec au moins un élément réseau, appelé « concentrateur réseau » ou « concentrateur », via des connexions de référence dédiées reposant typiquement sur l’établissement de tunnels.

Aucune hypothèse n’est faite quant à la localisation d’un concentrateur.

A titre d’exemple, au moins un concentrateur 23 peut être déployé dans au moins l’un des réseaux externes 221, 222, 22j.

On considère par exemple que le premier équipement est un terminal H1, qui requiert l’exécution d’une application hébergée par le serveur S. Les données applicatives échangées entre le terminal H1 et le serveur S sont transportées sur une connexion « applicative » entre le terminal H1 et le serveur S, illustrée en pointillés sur la .

Si le terminal H1 et le serveur S supportent tous les deux la procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention, alors la répartition du trafic entre les différents réseaux externes peut être gérée par le terminal H1 et/ou le serveur S. Une connexion de référence selon l’invention peut alors être établie entre le terminal H1 et le serveur S. Dans ce cas, la connexion applicative et la connexion de référence peuvent être une même connexion.

Si le terminal H1 ne supporte pas la procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention mais que le serveur S supporte une telle procédure, alors la répartition du trafic peut être gérée par au moins un équipement d’accès CE1, CEk du réseau local et/ou le serveur S. Une connexion de référence selon l’invention peut alors être établie entre l’équipement d’accès et le serveur. Une telle connexion de référence peut notamment être associée à la connexion applicative pour l’acheminement des données applicatives entre le terminal et le serveur via l’équipement d’accès.

Si ni le terminal H1, ni le serveur S ne supportent la procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention, alors la répartition du trafic peut être gérée par au moins un équipement d’accès CE1, CEk du réseau local et/ou par au moins un concentrateur 23. Une connexion de référence selon l’invention peut alors être établie entre l’équipement d’accès et le concentrateur. Une telle connexion de référence peut notamment être associée à la connexion applicative pour l’acheminement des données applicatives entre le client et le serveur via l’équipement d’accès et le concentrateur.

Un exemple de connexion de référence 24 entre l’équipement d’accès et le concentrateur est notamment illustré en trait plein en .

5.2.2 Fonctionnement d’un équipement d’accès et d’un concentrateur

Par souci de simplification, on se place ci-après dans le contexte où ni le terminal H1, ni le serveur S ne supportent la procédure de sélection d’au moins une politique d’ordonnancement de paquets. La répartition du trafic entre les différents réseaux externes est donc gérée et exécutée par au moins un équipement d’accès CE1, CEk du réseau local et/ou au moins un concentrateur 23, et la ou les politiques d’ordonnancement de paquets sélectionnées mises en œuvre sur une connexion de référence entre un équipement d’accès et un concentrateur, qui diffère donc de la connexion applicative établie entre le terminal H1 et le serveur S.

On note toutefois qu’il s’agit d’un simple exemple, et les étapes décrites ci-dessous pour un CE peuvent plus généralement être mises en œuvre par une entité source et les étapes décrites ci-dessous pour un concentrateur par une entité destinataire, pour un trafic de données du LAN vers un réseau externe. Pour un trafic de données du réseau externe vers le LAN, l’entité source peut être un concentrateur et l’entité destinataire un CE.

Selon l’exemple considéré, un CE peut être configuré avec au moins une information permettant d’identifier ou de joindre au moins un concentrateur. Plusieurs concentrateurs peuvent être déclarés auprès d’un même CE, par exemple au moyen d’une configuration statique ou d’une configuration dynamique en utilisant un protocole comme DHCP ou CWMP ou NETCONF, pour fournir les informations d’identification / joignabilité du ou des concentrateurs.

En particulier, si le réseau support des communications inter-sites est un réseau SD-WAN, c’est-à-dire un réseau dont les ressources sont contrôlées et exploitées par une intelligence de calcul logiquement centralisée, typiquement appelée contrôleur SDN, le concentrateur peut être une passerelle « SD-WAN GW » (« SD-WAN Gateway » en anglais).

Les informations permettant d’identifier un concentrateur comprennent par exemple une ou plusieurs adresses IP (IPv4 et/ou IPv6), un ou plusieurs numéros de port, et/ou un identifiant d’authentification, etc.

Selon un premier exemple, un identifiant d’authentification peut notamment être utilisé pour vérifier l’habilitation d’un concentrateur à établir une connexion de référence avec un CE. Cet identifiant peut être vérifié lors de l’établissement d’une première connexion de référence entre le CE et ce concentrateur. Une telle connexion est typiquement établie en utilisant des tunnels dédiés par chemin d’accès disponible établis entre le CE et le concentrateur.

Selon un deuxième exemple, les adresses et/ou numéros de port peuvent notamment être utilisés comme adresses et/ou numéros de port destination des connexions de référence pour identifier un concentrateur.

Comme décrit ci-dessus, un concentrateur est notamment configuré pour pouvoir acheminer les données reçues d’un CE vers un autre CE, vers (resp. en provenance) un serveur localisé dans un « cloud » public ou privé, ou plus généralement, vers (resp. en provenance) un serveur connecté à Internet. De plus, un concentrateur peut maintenir des entrées dans une table, par exemple une BIB (« Binding Information Base », en anglais), dont les entrées permettent au concentrateur de sélectionner le CE pertinent vers lequel le trafic retour sera acheminé.

5.2.3 Politique d’ordonnancement de paquets de données

Comme indiqué ci-dessus, notamment en relation avec le principe général de l’invention, au moins une politique d’ordonnancement de paquets de données (PSS) peut être sélectionnée pour un couple entité source / entité destinataire. Une telle politique d’ordonnancement de paquets de données peut notamment supporter tout ou partie des fonctions suivantes :

gestion des chemins disponibles,
gestion de la congestion,
réassemblage des paquets,
réordonnancement des paquets,
etc.

Une PSS peut éventuellement prendre en compte d’autres paramètres pour l’exécution des fonctions précédemment décrites, tels que :

des conditions tarifaires, renseignées par exemple dans les contrats établis avec les opérateurs des différents réseaux externes,
des instructions de l’utilisateur, par exemple une minimisation des coûts induits, un équilibrage de l’utilisation des chemins, etc.),
l’expérience de l’utilisation (passée, historique) des ressources associées à chaque réseau externe, qui permet par exemple de qualifier la stabilité de certaines ressources à l’usage et de mettre en place des politiques de maintenance adaptées.

Une entité mettant en œuvre l’invention (par exemple un CE ou un concentrateur) peut notamment prendre en compte différents paramètres pour sélectionner au moins une PSS de données applicatives échangées entre l’entité source et l’entité destinataire, en tenant compte d’au moins une caractéristique d’une application associée aux données applicatives. Par exemple, une entité mettant en œuvre l’invention peut sélectionner au moins une PSS permettant d’adapter l’utilisation des ressources, et/ou d’optimiser la latence, et/ou de maximiser l’usage des ressources, et/ou d’améliorer leur disponibilité, etc.

Une entité mettant en œuvre l’invention (par exemple un CE ou un concentrateur) peut notamment établir au moins une connexion de référence entre l’entité source et l’entité destinataire, sur laquelle est mise en œuvre la PSS sélectionnée. Dans certains modes de réalisation, une telle connexion de référence repose au moins sur deux sous-connexions associées chacune à un chemin distinct entre l’entité source et l’entité destinataire. Le choix de la ou des sous-connexions utilisées pour acheminer les données applicatives peut dépendre notamment du mode d’application de la PSS sélectionnée.

Une entité mettant en œuvre l’invention (par exemple un CE ou un concentrateur) peut notamment maintenir des informations caractéristiques d’au moins un réseau externe, qui alimentent par exemple une fonction locale de suivi et de détection de symptômes caractéristiques de la détérioration de la qualité de service ou de la qualité d’expérience (QoE, « Quality of Experience ») pour une application donnée. Une telle fonction repose par exemple sur l’exploitation de données qui peuvent être traitées par des techniques d’intelligence artificielle telles que l’apprentissage machine (« Machine Learning » en anglais) et l’utilisation d’algorithmes d’apprentissage spécifiques (par exemple un algorithme d’apprentissage par renforcement, ou « Reinforcement Learning » en anglais) et est exécutée localement (typiquement supportée par un CE). Une telle fonction permet par exemple de surveiller :

le taux de remplissage des files d’attente : suivi des files d’attente observées sur chaque interface utilisée par un CE pour se connecter à un réseau externe. Le taux de remplissage des files d’attente peut renseigner un CE sur la qualité de la transmission via l’interface concernée. Cette information peut être utilisée pour décider des interfaces à utiliser pour acheminer des données en fonction des besoins de qualité de service ou de QoE d’une application donnée, par exemple,
un délai de transit (« One-way transit delay ») tel qu’observé sur un chemin,
un temps de trajet aller-retour RTT (« Round-Trip Time » en anglais) tel qu’observé sur un chemin, et notamment un chemin permettant d’accéder à un concentrateur,
une perte de paquets observée sur un chemin,
une variation d’un délai inter-paquets (« Inter-Packet Delay Variation ») ou gigue,
des paramètres applicatifs avancés calculés par des robots qui émulent certaines applications (par exemple de type robot VoIP, robot Webex®),
un historique des congestions observées sur un chemin,
etc.

Le suivi de la qualité de service ou de la QoE pour une application donnée, par exemple, à partir de la fonction de suivi permet notamment de mettre à jour le mode d’application de la PSS sélectionnée. En d’autres termes, ces différentes informations peuvent être utilisées par un CE (resp. un concentrateur) pour exécuter plusieurs actions caractéristiques de l’application d’une PSS, en fonction des contraintes de qualité de service ou de QoE des applications, par exemple. De telles actions peuvent consister à exécuter certains algorithmes tels que :

algorithme de type « Round-robin » : les chemins (également appelés « liens ») sont invoqués de façon cyclique en fonction d’un point de sortie (CE, pour un trafic du LAN vers un réseau externe), associé à chaque chemin. Par exemple, le poids de chaque chemin peut être fixé par un administrateur ou être calculé (dynamiquement) en fonction de plusieurs paramètres (par exemple optimisation des coûts de la connexion de référence),
optimisation du temps de stockage des paquets dans les files d’attente au moyen d’une gestion d’intervalles temporels,
« Priority-based » : des priorités sont affectées à chaque chemin, par exemple en tenant compte d’une politique PBR (« Policy-Based Routing » en anglais),
un seuil RTT (« RTT threshold » en anglais) : les chemins sont utilisés jusqu’à ce qu’un certain seuil RTT soit atteint. Par exemple, le seuil est fixé de sorte que l’application de la PSS puisse garantir que les chemins utilisés ne présentent pas une RTT non-conforme aux attentes des applications. Le ou les algorithmes impliqués (algorithmes de gestion de files d’attente, notamment) dans l’application de la PSS permet notamment une gestion proactive de la détérioration de la latence,
une priorité affectée aux chemins présentant le plus faible RTT (« Lowest RTT first » en anglais) : de tels chemins sont par exemple privilégiés pour acheminer le trafic à destination d’un concentrateur
etc.

Différents histogrammes et distributions statistiques peuvent aussi être maintenus pour la gestion proactive des paramètres de qualité de service et de QoE. Le trafic peut alors être distribué entre différents chemins selon un objectif de QoE par exemple, et pas seulement en fonction la QoE observée à un instant donné. Par exemple, un CE peut procéder :

à la réplication d’une partie des paquets de données (exprimé par exemple en pourcentage du trafic total) entre plusieurs chemins pendant une durée déterminée,
au basculement de tout ou partie du trafic vers une ou plusieurs entités source selon l’observation du taux de remplissage des files d’attente, de l’évolution du paramètre RTT, ou selon d’autres critères ou symptômes observés par l’entité source.

Dans un mode de réalisation particulier, une politique d’ordonnancement de paquets de données PSS peut être identifiée par un identifiant unique. Par exemple, une PSS peut être identifiée par un entier, un nom, etc. Les PSS par « couple » entité source/ entité destinataire peuvent notamment être référencées dans un registre (par exemple PSS1 entre un CE donné et un concentrateur donné, PSS2 entre un concentrateur donné et un serveur donné, PSS3 entre un terminal donné et un serveur donné).

5.2.4 Sélection et mise en œuvre d’une politique d’ordonnancement de paquets de données

On revient à la et à l’exemple selon lequel ni le terminal H1, ni le serveur S ne supportent la procédure de sélection d’au moins une politique d’ordonnancement de paquets.

Lors de l’établissement d’une première connexion de référence d’un CE à un concentrateur, le CE (par exemple le CE1) vérifie si le concentrateur 23 supporte la procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention. En variante, le CE peut utiliser une connexion dédiée pour vérifier si le concentrateur supporte ladite procédure. Cette connexion est ensuite clôturée et n’est donc pas utilisée pour transporter des données applicatives.

Par exemple, une première connexion de référence utilisant un protocole de la couche transport, par exemple QUIC, est établie entre le CE1 et le concentrateur 23.

Selon un mode de réalisation particulier, le CE peut utiliser un nouveau paramètre de transport QUIC appelé ici « Customized_PSS », pour signaler que l’entité émettrice du paramètre (CE1 ou concentrateur 23 par exemple) supporte la procédure de sélection d’au moins une politique d’ordonnancement de paquets.

Par exemple, un paramètre « Customized_PSS » valorisé à « 0x1 » indique que la procédure de sélection d’au moins une politique d’ordonnancement de paquets est supportée par l’entité émettrice du paramètre, et un paramètre « Customized_PSS » valorisé à « 0x0 » (ou l’absence d’un tel paramètre) de transport indique que la procédure de sélection d’au moins une politique d’ordonnancement de paquets n’est pas supportée par l’entité émettrice (CE1 ou concentrateur 23 par exemple).

Si l’entité source (CE1 par exemple) reçoit le paramètre « Customized_PSS » valorisé à « 0x1 » en provenance de l’entité destinataire (concentrateur 23 par exemple), l’entité source peut envoyer à l’entité destinataire une liste de la ou des politiques d’ordonnancement de paquets supportées par l’entité source.

SI le protocole QUIC est utilisé sur la première connexion (dédiée ou de référence) établie entre l’entité source et l’entité destinataire, l’entité source peut utiliser une nouvelle trame QUIC, appelée ici trame QUIC PSS, pour informer l’entité destinataire de la ou des politiques d’ordonnancement de paquets supportée par l’entité source. L’entité destinataire peut conserver en mémoire la liste des PSS supportées par l’entité source, notamment pour la gestion du trafic retour.

L’entité destinataire peut envoyer à l’entité source une liste de la ou des politiques d’ordonnancement de paquets supportées par l’entité destinataire (notamment si l’entité source n’a pas communiqué à l’entité destinataire les PSS supportées par l’entité source), ou une sélection des politiques d’ordonnancement de paquets supportées par l’entité source et l’entité destinataire.

Par exemple, l’entité source reçoit une liste des PSS supportées par l’entité destinataire dans une trame QUIC PSS : PSS#1, …, PSS#i.

L’entité source peut notamment garder en mémoire la liste des PSS supportées par l’entité destinataire.

Par exemple, la transmission de l’entité destinataire vers l’entité source de la liste des PSS supportées par l’entité destinataire peut être mise en œuvre de façon régulière, par exemple toutes les 24h, pour rafraichir la liste des PSS conservée dans une mémoire de l’entité source.

On considère par la suite qu’au moins une PSS commune est supportée par l’entité source et l’entité destinataire. On suppose également que l’entité source et l’entité destinataire supportent également au moins un même mode d’application de la PSS.

Parmi les PSS supportées par l’entité source et l’entité destinataire, au moins une PSS est sélectionnée en tenant compte des caractéristiques d’une application associée aux données applicatives échangées entre l’entité source et l’entité destinataire. De telles caractéristiques peuvent inclure notamment des contraintes de l’application en question.

Au moins une connexion de référence, sur laquelle est mise en œuvre au moins une PSS sélectionnée, est établie entre l’entité source et l’entité destinataire (par exemple au démarrage ou redémarrage de l’entité source, ou lors de l’établissement de la communication caractéristique de l’application utilisée – par exemple au moment de l’établissement d’une connexion (applicative) HTTP à partir d’un terminal connecté au réseau local dans lequel sont déployés un ou plusieurs CE selon l’invention, également appelée connexion applicative).

Une telle connexion de référence repose par exemple sur le protocole QUIC.

Dans un mode de réalisation, la sélection d’au moins une PSS est effectuée préalablement à l’établissement de la connexion de référence. Par exemple, l’entité source sélectionne une PSS à activer pour la connexion de référence (associée à une application ou un groupe d’applications de même type) et communique l’identifiant PSS à l’entité destinataire. L’entité source et l’entité destinataire activent alors la même PSS pour cette connexion de référence. Dans un autre mode de réalisation, la sélection d’au moins une PSS est effectuée simultanément à l’établissement de la connexion de référence. On note que l’application d’une même PSS peut être effectuée pour une ou plusieurs connexions de référence établies entre l’entité source et l’entité destinataire.

En particulier, la connexion de référence est acceptée par l’entité destinataire si la PSS est supportée par l’entité destinataire. Cette étape de vérification de capacité (à supporter ladite PSS) n’est pas requise si la négociation de la PSS est effectuée au préalable entre l’entité source et l’entité destinataire, et non lors de l’établissement de la connexion de référence. La demande d’établissement de connexion de référence est refusée si la PSS indiquée par l’entité source n’est pas supportée par l’entité destinataire ou si le paramètre « Customized_PSS » valorisé à un « 0x1 » n’a pas été échangé entre l’entité source et l’entité destinataire.

L’entité source, par exemple le CE, peut notamment établir une connexion de référence comprenant plusieurs sous-connexions (également appelée connexion multi-chemins) avec l’entité destinataire (par exemple le concentrateur). Comme déjà indiqué, l’établissement de sous-connexions permet de pouvoir basculer/rediriger le trafic vers un chemin ou un autre, par exemple en fonction des objectifs de QoE fixés par une application ou selon l’évolution des conditions de transmission (dégradation du temps de transit par exemple).

Pour ce faire, pour une connexion de référence pour laquelle au moins une PSS a été sélectionnée, l’entité source négocie avec le concentrateur le mode d’application de la PSS à mettre en place pour les flux applicatifs transportés sur cette connexion de référence. Éventuellement, la négociation est effectuée lors de l’établissement de la communication caractéristique de l’application utilisée entre le terminal et le serveur, également appelée connexion applicative. Les paquets de données transmis sur la connexion de référence sont alors répartis entre les différents chemins en fonction du mode d’application de la PSS activée et selon les conditions de qualité de service et de QoE observées par l’entité source.

5.2.5 Variantes

Dans un mode de réalisation particulier, des informations de classification de trafic peuvent être fournies à l’entité source et/ou à l’entité destinataire pour associer un type d’application à une politique d’ordonnancement de paquets qui permettrait de satisfaire, par exemple, les exigences de qualité liées à ce type application.

Autrement dit, l’entité source et/ou l’entité destinataire peuvent associer une connexion « applicative » (qui transporte les données applicatives) à une connexion de référence sur laquelle est mise en œuvre une PSS sélectionnée pour satisfaire les exigences de qualité liées à ce type d’application.

Ces informations de classification peuvent être :

configurées par un administrateur en utilisant une interface de gestion spécifique à l’entité source et/ou destinataire,
communiquées via un mécanisme de signalisation tel que le protocole PCP (« Port Control Protocol ») : un client PCP peut alors être embarqué dans un terminal connecté au réseau local,
exposées par un serveur applicatif via une API dédiée : par exemple, l’invocation de l’API peut être conditionnée à un accord entre le fournisseur du serveur et l’entité qui gère le service de communication (par exemple l’opérateur d’un réseau SD-WAN),
indiquées via une API transport, par exemple l’API décrite dans le document RFC6897 « Multipath TCP (MPTCP) Application Interface Considerations » de mars 2013 ou « QUIC API for Peer-to-peer Connections » du W3C Community Group Draft report du 3 mars 2022,
etc.

Ainsi, l’entité source peut notamment sélectionner le mode d’application d’une PSS à mettre en œuvre pour associer le trafic reçu à une connexion de référence préétablie, ou décider d’établir une nouvelle connexion de référence, en tenant compte d’au moins un élément appartenant au groupe comprenant :

une information de classification de trafic,
un identifiant de PSS,
une heuristique locale à l’entité source,
une évolution des conditions de transmission (par exemple dégradation du temps de latence observé sur une connexion de référence ou une sous-connexion).

Le trafic est ensuite associé à une interface de sortie de l’entité source, puis acheminé sur la ou les sous-connexions associées.

On note que l’entité source et l’entité destinataire peuvent utiliser des chemins différents pour acheminer le trafic aller et le trafic retour si les objectifs de qualité de service ou de QoE ne sont satisfaits que dans une seule direction d’acheminement du trafic (CE vers concentrateur ou concentrateur vers CE), par exemple.

En particulier, si aucun chemin disponible ne permet de satisfaire les exigences de qualité d’une application, l’entité source peut envoyer une alerte vers l’entité qui en a la responsabilité de gestion, par exemple le contrôleur SDN du site où l’entité source est déployée.

On a décrit ci-dessus le cas où l’entité source est un équipement d’accès et l’entité destinataire est un concentrateur (trafic en provenance du LAN et à destination d’un réseau externe). Bien entendu, les opérations décrites ci-dessus peuvent être mises en œuvre dans le cas où l’entité source est un concentrateur et l’entité destinataire est un équipement d’accès (trafic en provenance du réseau externe et à destination du LAN). De même, les opérations décrites ci-dessus peuvent être mises en œuvre par un premier équipement tel un terminal s’il supporte une procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention, et/ou un deuxième équipement tel un autre terminal, un serveur, etc., s’il supporte une procédure de sélection d’au moins une politique d’ordonnancement de paquets selon l’invention. Ainsi, l’entité source peut être un terminal et l’entité destinataire un serveur (ou vice-versa), l’entité source peut être un équipement d’accès et l’entité destinataire un serveur (ou vice-versa), l’entité source peut être un concentrateur et l’entité destinataire un serveur (ou vice-versa), l’entité source peut être un équipement d’accès et l’entité destinataire un concentrateur (ou vice-versa).

5.2.6 Pluralité d’équipement d’accès

On décrit ci-après un mode de réalisation particulier selon lequel plusieurs équipements d’accès sont connectés à un même réseau local. Dans ce cas, il est possible de sélectionner l’un des équipements d’accès comme point de sortie (resp. point d’entrée) du LAN.

Les différents CE connectés à un même réseau local peuvent notamment utiliser un canal dédié pour partager entre eux des informations relatives aux différents réseaux externes, par exemple des informations caractéristiques du trafic transitant par les CE connectés aux réseaux externes. De telles informations peuvent notamment être utilisées pour sélectionner l’un des CE connectés au réseau local pour acheminer des données applicatives entre le terminal et le serveur.

Selon un premier exemple illustré en , le canal dédié peut être de type « point-à-multipoint ». Un équipement d’accès CE1 peut ainsi recevoir des informations relatives à au moins un des réseaux externes en provenance d’au moins un autre équipement d’accès CE2, CE3, CEk connecté au réseau local et capable d’établir une connexion de référence avec le serveur distant S ou le concentrateur 23.

Un exemple d’implémentation de ce canal point-à-multipoint repose sur un mode de transmission multicast, où l’ensemble des CE souscrivent au même groupe multicast défini par une adresse de groupe particulière. Cette adresse multicast est déclarée dans tous les CE ayant souscrit au même groupe multicast, par exemple de façon statique ou de façon dynamique en utilisant les ressources d’un protocole tel que DHCP ou CWMP ou NETCONF.

Les informations reçues par un CE (par exemple le CE2 de la ) en provenance des autres CE (par exemple CE1) peuvent ainsi alimenter une procédure de sélection de chemins mise en œuvre par le CE, pour acheminer les données reçues de terminaux connectés au réseau local vers un ou plusieurs concentrateurs. De telles informations sont par exemple caractéristiques des différents trafics transitant par les différents CE, telles que des paires {adresse source ; adresse destination}.

Aussi, ces informations peuvent être utilisées par au moins un CE pour modifier le routage dans le réseau local pour le trafic de données applicatives en adéquation avec la politique d’ordonnancement de paquets sélectionnée pour l’application associée à ces données applicatives. Notamment, ces informations peuvent être utilisées par au moins un CE pour déterminer le point de sortie (« egress point », en anglais) du trafic de données applicatives en fonction de différents critères tels que la destination du trafic émis par un terminal connecté au réseau local, la nature du trafic émis par un terminal connecté au réseau local et dont les contraintes en termes de latence ou de variation de délai inter-paquets peuvent imposer un chemin plutôt qu’un autre pour atteindre un concentrateur, etc.

Par exemple, la sélection d’un CE sera conditionnée par sa capacité à contribuer au respect du niveau de qualité d’expérience (QoE) caractéristique de la nature du service ou de l’application utilisée par un terminal connecté au réseau local pour atteindre une destination donnée. Pour ce faire, chacun des CE permettant d’atteindre ladite destination choisit un chemin privilégié en fonction des conditions locales (d’accès au service ou à un site distant, par exemple) de nature à optimiser la QoE telle que perçue par l’utilisateur, et annonce ce chemin dans le réseau local. Le CE qui contribue à fournir une QoE optimale sera sélectionné pour acheminer le trafic vers une destination donnée. A noter que la même procédure peut être utilisée pour les chemins par défaut (« wildcard » : « :: / 0 » (IPv6) ou « 0.0.0.0/0 » (IPv4)).

A titre d’exemple, on considère une connexion applicative établie entre le terminal H2 et le serveur S. Les figures 4A et 4B illustrent un premier chemin à un instant T0 et un deuxième chemin à un instant T1 entre le terminal H2 et le serveur S.

A l’instant T0, illustré en , la connexion applicative est associée (par exemple par le CE1) à une connexion de référence établie entre le CE1 et le concentrateur 23. Autrement dit, la connexion applicative transportant les données applicatives entre le CE1 et le concentrateur 23 est associée à la connexion de référence établie entre le CE et le concentrateur. Les données applicatives transitent donc par l’équipement d’accès CE1 et le réseau externe Net. #1. Les différents équipements d’accès CE1 et CEk peuvent notamment observer le réseau étendu (temps de transit, bande passante disponible, profil de trafic, etc.) et sélectionner un point de sortie (CE, pour un trafic du LAN vers un réseau externe) en fonction des paramètres de QoS observés par les CE et échangés via les canaux établis entre les CE d’un même site (Site #i).

A l’instant T1, illustré en , un autre point de sortie (CE) est sélectionné. La connexion applicative est alors associée à une connexion de référence établie entre le CEk et le concentrateur 23. Les données transitent alors par l’équipement d’accès CEk et le réseau externe Net. #j.

On note qu’en cas de redirection de trafic vers un autre point de sortie, la continuité de la connexion applicative établie entre le terminal H2 et le serveur S peut être préservée par la présence du même concentrateur 23 dans les différentes sous-connexions ou chemins empruntés par les données qui transitent par ce même concentrateur.

Dans un mode de réalisation particulier, la sélection d’un CE parmi plusieurs CE connectés au réseau local tient également compte d’un identifiant associé aux données applicatives échangées entre le terminal et le serveur.

Selon un premier exemple, un tel identifiant est un identifiant d’application, par exemple « app-id ». L’identifiant « app-id » peut notamment être utilisé par un terminal pour l’acheminement de paquets caractéristiques d’applications spécifiques, également appelé données applicatives. A titre d’exemple, les applications ayant les mêmes contraintes de QoE peuvent être identifiées par un même identifiant d’application. Par exemple, une application peut communiquer son identifiant (« app-id ») via une API réseau locale pour indiquer à un processus de routage/acheminement (« routing/forwarding », en anglais) embarqué dans un CE la route « applicative » à utiliser pour acheminer les données de cette application au sein du réseau local. Par exemple, les messages d’annonce de routes contiennent un identifiant d’application qui permet de maintenir dans le réseau local des routes spécifiques par application. Ce faisant, un réseau local peut alors maintenir des routes différenciées par application, et donc, des CE distincts peuvent être choisis pour acheminer le trafic vers une même destination pour une application donnée.

Selon d’autres exemples, d’autres identifiants peuvent être utilisés pour sélectionner une route plutôt qu’une autre : par exemple, un même codage DSCP (« DiffServ Code Point ») peut conduire à sélectionner des routes pour le trafic marqué EF (« Expedited Forwarding ») et d’autres routes pour le trafic marqué AF (« Assured Forwarding »), sans préjuger de la nature de la ou des applications qui bénéficieront de ce traitement différencié. Dans ce cas, un identifiant « dscp-val » peut être associé aux routes annoncées entre CE dans les messages échangés entre eux via un canal dédié.

A titre d’exemple, la illustre la sélection d’un point de sortie (CE1 ou CEk, pour un trafic en provenance du LAN et à destination d’un réseau externe) en fonction de l’application (« app-id ») et des paramètres de QoE observés et échangés entre les CE d’un même site (Site #i). Des routes distinctes sont utilisées pour acheminer le trafic en fonction des contraintes applicatives et des conditions observées par les différents points de sortie (CE) connectés à un même réseau local. Par exemple une première route via l’équipement d’accès CE1 est privilégiée pour les applications identifiées par l’identifiant app-id=1 et une deuxième route via l’équipement d’accès CEk est privilégiée pour les applications identifiées par l’identifiant app-id=2.

On note que dans ce mode de réalisation mettant en œuvre plusieurs CE, afin d’éviter des instructions contradictoires entre différents CE d’un même site (c’est-à-dire connectés au même réseau local), un CE doit informer les autres CE avant de modifier la route.

On a décrit ci-dessus un premier exemple selon lequel le canal dédié peut être de type « point-à-multipoint ».

La illustre un deuxième exemple selon lequel le canal dédié au partage des informations entre CE est un canal « point-à-point ».

Selon cet exemple, au moins un équipement d’accès connecté au réseau local et permettant d’établir une connexion de référence avec le serveur distant S ou le concentrateur 23 transmet à un contrôleur 61 des informations relatives à au moins un des réseaux externes auquel il est connecté. De telles informations peuvent notamment être utilisées pour sélectionner l’un des CE connectés au réseau local pour acheminer des données applicatives entre le terminal et le serveur.

Un exemple d’établissement d’un tel canal point-à-point consiste à établir une connexion (de contrôle) entre un CE et un ou plusieurs contrôleurs exploités par une entreprise par exemple.

Un tel contrôleur 61 (contrôleur SDN par exemple) peut être local à chaque site. De cette façon, il est possible de préserver l’étanchéité des communications entre les différents sites. En effet, les décisions (politiques de routage, redirection de trafic, gestion des CE du site, etc.) prises par un tel contrôleur sont locales au site. De fait, ces décisions n’interfèrent pas avec celles prises par les autres contrôleurs déployés sur les autres sites. Une telle ingénierie permet également de ne pas dépendre de la connectivité entre les sites, ce qui contribue à renforcer la robustesse et la capacité à appliquer les décisions prises par le contrôleur, sans induire de délai supplémentaire ni compromettre la bonne application des décisions, notamment lorsque celles-ci doivent être prises en réaction à de nouvelles conditions de qualité de service ou de QoE observées sur le site considéré.

Alternativement, un seul contrôleur peut être utilisé pour gérer les différents sites où plusieurs CE sont déployés. Dans ce cas, le contrôleur peut associer un CE à son site de déploiement. Cette information peut être configurée dans le contrôleur par un administrateur ou être récupérée depuis chaque CE en utilisant un protocole tel que NETCONF, par exemple.

Quelle que soit l’ingénierie retenue (un contrôleur par site ou un contrôleur pour tous les sites), le contrôleur utilise les informations reçues de la part des différents CE pour décider de la politique locale de sélection des point(s) de sortie au sein du réseau local pour acheminer le trafic vers une destination donnée, pour toutes les destinations ou pour un sous-ensemble de destinations, en tenant compte de plusieurs critères tels que les conditions de qualité de service ou de QoE, la nature du trafic, les différents profils de trafic, les politiques de priorisation de trafic, etc.

Comme décrit précédemment en relation avec la , le contrôleur peut notamment configurer les CE avec des routes spécifiques à un groupe d’applications ayant des contraintes de qualité de service ou de QoE similaires. Par exemple, l’identifiant « app-id » peut être utilisé pour démultiplexer les routes et pourvoir choisir des points de sortie (CE, pour un trafic en provenance du LAN et à destination d’un réseau externe) par application. Le contrôleur peut également être responsable de l’établissement du ou des canaux dédiés au partage des informations entre CE : l’échange des informations entre CE via un tel canal point-à-point peut également impliquer le contrôleur lui-même, car les informations recueillies peuvent servir de données d’entrée pour le calcul des routes (et l’instanciation dynamique de la politique de routage « applicatif » associée) qui transiteront par tel ou tel CE.

A titre d’exemple, on considère une connexion applicative établie entre le terminal H2 et le serveur S. Les figures 7A et 7B illustrent un premier chemin à un instant T0 et un deuxième chemin à un instant T1 entre le terminal H2 et le serveur S.

A l’instant T0, illustré en , les données transitent par l’équipement d’accès CE1 et le réseau externe Net. #1. La connexion applicative est associée à une connexion de référence établie entre le CE1 et le concentrateur 23. Le contrôleur 61 peut notamment collecter des informations en provenance des différents équipements d’accès CE1 et CEk et sélectionner un point de sortie (CE, pour un trafic du LAN vers un réseau externe) en fonction des paramètres de QoS observés par les CE d’un même site (Site #i).

A l’instant T1, illustré en , un autre point de sortie (CE) est sélectionné. Les données transitent alors par l’équipement d’accès CEk et le réseau externe Net. #j. La connexion applicative est associée à une connexion de référence établie entre le CEk et le concentrateur 23.

On note qu’en cas de redirection de trafic vers un autre point de sortie, la continuité de la connexion applicative établie entre le terminal H2 et le serveur S peut être préservée par la présence du même concentrateur 23 dans les différentes sous-connexions ou différents chemins empruntés par les données qui transitent par ce même concentrateur.

Selon un mode de réalisation particulier, le type de canal (point-à-point ou point-à-multipoint) qui permet de partager des informations entre CE peut être fourni aux différents CE d’un même réseau local ou configuré dans les différents CE. Si aucune information de ce type n’est fournie à un CE, alors la procédure de communication et le partage d’informations entre CE est désactivée par défaut.

5.3 Entité correspondante

On présente finalement, en relation avec la , la structure simplifiée d’une entité source et/ou destinataire selon un mode de réalisation de l’invention.

L’entité source et/ou destinataire, selon un mode de réalisation de l’invention, comprend une mémoire 81, une unité de traitement 82, é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 83, mettant en œuvre des étapes du procédé de gestion de trafic selon au moins un mode de réalisation de l’invention.

A l’initialisation, les instructions de code du programme d’ordinateur 83 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 82.

Le processeur de l’unité de traitement 82 met en œuvre des étapes du procédé de gestion de trafic décrit précédemment, selon les instructions du programme d’ordinateur 83, pour :

sélectionner, pour ladite entité source et ladite entité destinataire, au moins une politique d’ordonnancement de paquets de données applicatives échangés entre ladite entité source et ladite entité destinataire, et tenant compte d’au moins une caractéristique d’une application associée auxdites données applicatives,

établir au moins une connexion entre ladite entité source et ladite entité destinataire sur laquelle est mise en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.

Claims

Procédé de gestion du trafic de données entre une entité source (11) et une entité destinataire (12), mettant en œuvre :
la sélection (13), pour ladite entité source et ladite entité destinataire, d’au moins une politique d’ordonnancement de paquets de données applicatives échangés entre ladite entité source et ladite entité destinataire, tenant compte d’au moins une caractéristique d’une application associée auxdites données applicatives,
ladite au moins une politique d’ordonnancement de paquets sélectionnée étant supportée par ladite entité source et par ladite entité destinataire,
l’établissement (14) d’au moins une connexion entre ladite entité source et ladite entité destinataire, sur laquelle est mise en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.
Procédé selon la revendication 1, caractérisé en ce que l’entité source transmet à l’entité destinataire une liste d’au moins une politique d’ordonnancement de paquets supportée par ladite entité source.
Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que l’entité source reçoit, en provenance de l’entité destinataire, une liste d’au moins une politique d’ordonnancement de paquets supportée par ladite entité destinataire.
Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite entité source, resp. ladite entité destinataire, transmet un paramètre signalant à l’entité destinataire, resp. l’entité source, qu’elle est apte à mettre en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.
Procédé selon l’une quelconque des revendications 2 à 4, caractérisé en ce que ladite liste selon la revendication 2 ou la revendication 3 et/ou ledit paramètre selon la revendication 4 est transmis en utilisant un protocole de la couche transport entre ladite entité source et ladite entité destinataire.
Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite connexion comprend au moins deux sous-connexions associées chacune à un chemin distinct entre ladite entité source et ladite entité destinataire, et en ce que ladite entité source envoie lesdites données applicatives sur au moins une desdites sous-connexions en tenant compte de ladite au moins une politique d’ordonnancement de paquets sélectionnée pour ladite connexion.
Procédé selon l’une quelconque des revendications 1 à 6, caractérisé en ce qu’il comprend la réception d’au moins une information de classification de trafic permettant d’associer au moins une politique d’ordonnancement de paquets à un type d’application.
Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le mode d’application de ladite au moins une politique d’ordonnancement de paquets sélectionnée est mis à jour périodiquement et/ou en fonction d’une évolution des conditions d’acheminement des données applicatives échangées entre ladite entité source et ladite entité destinataire.
Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite entité source, resp. entité destinataire, est un premier équipement connecté à un réseau local, et en ce que ladite entité destinataire, resp. entité source, est un deuxième équipement connecté à un réseau externe.
Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite entité source, resp. entité destinataire, est un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant lesdites données applicatives en provenance, resp. vers, un premier équipement connecté audit réseau local, et en ce que ladite entité destinataire, resp. entité source, est un deuxième équipement connecté à l’un desdits au moins un réseau externe.
Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite entité source, resp. entité destinataire, est un équipement d’accès, connecté à un réseau local et à au moins un réseau externe, acheminant lesdites données applicatives en provenance, resp. vers, un premier équipement connecté audit réseau local, et en ce que ladite entité destinataire, resp. source, est un concentrateur, acheminant lesdites données applicatives vers, resp. en provenance d’un deuxième équipement connecté à l’un desdits au moins un réseau externe.
Procédé selon l'une quelconque des revendications 10 et 11, caractérisé en ce que ledit équipement d’accès établit au moins deux connexions entre ladite entité source et ladite entité destinataire, mettant chacune en œuvre une politique d’ordonnancement de paquets distincte sélectionnée en tenant compte d’au moins une caractéristique d’une application.
Procédé selon l'une quelconque des revendications 10 à 12, caractérisé en ce que ledit équipement d’accès reçoit des informations relatives à au moins un desdits réseaux externes, en provenance d’au moins un autre équipement d’accès connecté audit réseau local et ayant établi une connexion avec ledit deuxième équipement selon la revendication 10 ou ledit concentrateur selon la revendication 11.
Procédé selon l'une quelconque des revendications 10 à 12, caractérisé en ce que ledit équipement d’accès transmet à un contrôleur des informations relatives à au moins un desdits réseaux externes, ledit contrôleur recevant des informations relatives à au moins un desdits réseaux externes en provenance d’au moins un autre équipement d’accès connecté audit réseau local et ayant établi une connexion avec ledit deuxième équipement selon la revendication 10 ou ledit concentrateur selon la revendication 11.
Procédé selon la revendication 13 ou la revendication 14, caractérisé en ce qu’il sélectionne un desdits équipements d’accès pour acheminer lesdites données applicatives en provenance dudit premier équipement, resp. vers ledit premier équipement, en tenant compte desdites informations relatives à au moins un desdits réseaux externes.
Procédé selon la revendication 15, caractérisé en ce que ladite sélection d’un desdits équipements d’accès tient également compte d’un identifiant associé auxdites données applicatives.
Entité dite source (11), resp. destinataire, apte à communiquer avec une entité destinataire (12), resp. source, comprenant au moins un processeur configuré pour :
sélectionner (13), pour ladite entité source et ladite entité destinataire, au moins une politique d’ordonnancement de paquets de données applicatives échangés entre ladite entité source et ladite entité destinataire, tenant compte d’au moins une caractéristique d’une application associée auxdites données applicatives,
ladite au moins une politique d’ordonnancement de paquets sélectionnée étant supportée par ladite entité source et par ladite entité destinataire,
établir (14) au moins une connexion entre ladite entité source et ladite entité destinataire sur laquelle est mise en œuvre ladite au moins une politique d’ordonnancement de paquets sélectionnée.