FR3115644A1 - Procédé et dispositif d’aiguillage d’une donnée applicative - Google Patents
Procédé et dispositif d’aiguillage d’une donnée applicative Download PDFInfo
- Publication number
- FR3115644A1 FR3115644A1 FR2010883A FR2010883A FR3115644A1 FR 3115644 A1 FR3115644 A1 FR 3115644A1 FR 2010883 A FR2010883 A FR 2010883A FR 2010883 A FR2010883 A FR 2010883A FR 3115644 A1 FR3115644 A1 FR 3115644A1
- Authority
- FR
- France
- Prior art keywords
- application
- data
- identifier
- packet
- transport protocol
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 90
- 101100264195 Caenorhabditis elegans app-1 gene Proteins 0.000 claims abstract description 59
- 239000012634 fragment Substances 0.000 claims abstract description 54
- 238000012545 processing Methods 0.000 claims abstract description 25
- 101100137363 Arabidopsis thaliana PPI2 gene Proteins 0.000 claims abstract description 11
- 101100536527 Arabidopsis thaliana TOC159 gene Proteins 0.000 claims abstract description 11
- 101100481793 Arabidopsis thaliana TOC33 gene Proteins 0.000 claims abstract 5
- 101150031304 ppi1 gene Proteins 0.000 claims abstract 5
- 238000004590 computer program Methods 0.000 claims description 14
- 230000005540 biological transmission Effects 0.000 claims description 9
- 101150053844 APP1 gene Proteins 0.000 claims 1
- 101100055496 Arabidopsis thaliana APP2 gene Proteins 0.000 claims 1
- 101100189105 Homo sapiens PABPC4 gene Proteins 0.000 claims 1
- 102100039424 Polyadenylate-binding protein 4 Human genes 0.000 claims 1
- 101100016250 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) GYL1 gene Proteins 0.000 claims 1
- 238000004891 communication Methods 0.000 description 24
- 230000008569 process Effects 0.000 description 18
- 238000007689 inspection Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 7
- 230000008901 benefit Effects 0.000 description 4
- 235000014510 cooky Nutrition 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Procédé et dispositif d’aiguillage d’une donnée applicative Les identifiants de ports de destination utilisés dans les techniques relevant de l’art antérieur et permettant de distinguer de façon sûre des données applicatives sont de plus en plus difficile à obtenir de la part d’organismes internationaux. Il est donc de plus en plus difficile de différencier de façon non ambiguë des données relatives à plusieurs applications transportées simultanément sur le même protocole de transport. Pour répondre à ce problème, l’invention décrit un procédé d’aiguillage d’une donnée relative à une application transportée dans un fragment de données d’un paquet d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, mis en œuvre par un dispositif (110) de multiplexage apte à transférer des données relatives à une pluralité d’applications (App1, App2) à des entités de traitement, en utilisant un premier identifiant (P0) de port de destination commun à la pluralité d’applications (App1, App2), et dans un fragment de données un deuxième identifiant (PPI1, PPI2) spécifique à l’application (App1, App2). Figure pour l'abrégé : Fig. 2
Description
1. Domaine technique
L'invention se situe dans les réseaux de communications, et plus précisément dans les réseaux dans lesquels les flux de données sont acheminés en utilisant un protocole de transport de flux, tel que le protocole SCTP (en anglais Stream Control Transport Protocol), ces flux de données étant relatifs à de multiples applications. L’invention vise plus particulièrement à pouvoir différencier de façon non ambiguë des données relatives à plusieurs applications transportées simultanément sur le même protocole de transport.
2. Etat de la technique
Les architectures de réseau aujourd’hui spécifiées et déployées sont basées sur un système de communication en couches où chaque couche est responsable d’un service d’acheminement. Ainsi, les architectures Internet couramment utilisées pour une diversité de besoins et de services sont basées sur les protocoles TCP/IP (en anglais Transmission control Protocol/Internet Protocol) comprenant un ensemble de protocoles. Parmi ces couches, on distingue la couche IP permettant notamment de joindre un correspondant en utilisant une adresse IP et la couche transport assurant notamment le bon acheminement des données entre deux correspondants ainsi que l’intégrité de ces données. Parmi les protocoles de transport, on identifie notamment les protocoles UDP (en anglais User Data Protocol), TCP ainsi que le protocole SCTP spécifié dans le document IETF RFC 4960 (Septembre 2007). Ce protocole SCTP présente notamment des caractéristiques de fiabilité, de redondance, de sécurité et de fiabilité particulièrement pertinentes pour les services à contrainte, tels que les services de téléphonie sur IP. Il est en outre à noter que les protocoles de transport utilisés dans les réseaux acheminent des flux de données d’applications diverses. Ainsi, les données applicatives acheminées via les protocoles de transport, parmi lesquels le protocole SCTP, sont multiplexées en utilisant une adresse IP commune et en utilisant un numéro de port relatif au protocole de transport associé à une application spécifique. Ainsi, comme indiqué sur la , un nœud 400 transmettant des données applicatives des applications App1, App2 à un nœud 410, émet des paquets IP comprenant l’adresse IP (source) du nœud 400, l’adresse IP (destination) du nœud 410, le port PS (source) du protocole de transport, le port (destination) du protocole SCTP de transport. Dans les architectures actuelles, le port destination utilisé identifie de façon non ambiguë les données applicatives transportées au-dessus du protocole de transport. Ainsi, les données de l’application App1 seront identifiées par un port destination P1, les données de l’application App2 par un port destination P2. Ainsi, la couche transport achemine des flux de données d’applications multiples App1, App2 en différenciant ces flux avec des numéros de ports P1 et P2 spécifiques.
Le nœud 410 est ainsi capable de transmettre les données reçues du nœud 400 et relatives aux applications App1, App2 aux entités en charge des applications App1, App2 en analysant le port destination utilisé au niveau du protocole SCTP de transport. Pour chaque application déployée dans les réseaux, selon les techniques actuelles, notamment quand l’application est utilisée sur l’Internet public, il est nécessaire d’allouer un port du protocole de transport. Il est ainsi nécessaire de solliciter l’IANA (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) qui alloue ces ports. Cependant, les procédures d'allocation sont de plus en plus strictes, car IANA a peur de voir tous les numéros de port attribués et se trouver en manque de numéros de ports. Il devient ainsi très difficile d'obtenir ces numéros de port. En outre, dans le cas de déploiement de réseau dit privé, c’est-à-dire géré par une entité et n’ayant pas besoin de communiquer avec des réseaux dits public sur l’Internet, l’IANA a fortement restreint la possibilité de recourir à l’allocation de numéros de ports publics, ce qui pose des problèmes de conflit de numéros et de gestion de ces numéros de ports, notamment dans le cas d’interconnexion avec d’autres réseaux dits privés. Cette indisponibilité des numéros de ports de la couche transport, et notamment pour le protocole SCTP, pose donc des problèmes de déploiement de services et d’applications. Il est à noter que le protocole TCPMux défini dans le document IETF RFC 1078 décrit un procédé de multiplexage de flux applicatifs mais ce procédé est spécifique au protocole TCP (Novembre 1998) et sa mise en œuvre pose notamment des problèmes de sécurité, ce qui le rend inopérant pour les besoins ci-dessus décrits.
La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.
3. Exposé de l'invention
L'invention vient améliorer la situation à l'aide d'un procédé d’aiguillage d’une donnée relative à une application transportée dans un fragment de données d’un paquet d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, mis en œuvre par un dispositif de multiplexage apte à transférer des données relatives à une pluralité d’applications à des entités de traitement, et comprenant la réception, en provenance d’un dispositif terminal, du paquet du protocole de transport de flux comprenant un en-tête contenant un premier identifiant de port de destination commun à la pluralité d’applications, et le fragment de données comprenant un deuxième identifiant spécifique à l’application, la détermination de l’application en fonction du premier et du deuxième identifiant reçus et dans le cas où l’application est déterminée, l’émission de la donnée à destination d’une entité en charge du traitement de la donnée de l’application.
Un dispositif de multiplexage recevant plusieurs paquets du protocole de transport, tel que SCTP, peut ainsi transférer les données applicatives aux différentes entités en charge de la réception, du traitement, et possiblement de la construction d’une réponse en fonction des deux identifiants présents dans l’en-tête et chacun des fragments transportant les données applicatives. Par exemple, si deux applications de voix sur IP et de visio sur IP sont activées, le dispositif d’aiguillage présent par exemple dans un client de voix sur IP, recevra les flux de voix sur IP et de visio sur IP et transmettra les données de voix sur IP au processus gérant les sessions de voix sur IP et les données de visio sur IP au processus gérant l’application de visio sur IP, possiblement déployé sur un autre terminal que le client de voix sur IP. Ce procédé permet ainsi d’économiser les ports de destination utilisés pour multiplexer les flux applicatifs dans une connexion au niveau transport tout en assurant le procédé de multiplexage nécessaire pour transmettre des flux applicatifs distincts sur une même connexion entre deux équipements. Le dispositif de multiplexage comprend des moyens pour pouvoir analyser les identifiants reçus et d’autre part déterminer si les deux identifiants correspondent à une application dont le dispositif de multiplexage est apte à gérer les données.
Un dispositif de multiplexage recevant plusieurs paquets du protocole de transport, tel que SCTP, peut ainsi transférer les données applicatives aux différentes entités en charge de la réception, du traitement, et possiblement de la construction d’une réponse en fonction des deux identifiants présents dans l’en-tête et chacun des fragments transportant les données applicatives. Par exemple, si deux applications de voix sur IP et de visio sur IP sont activées, le dispositif d’aiguillage présent par exemple dans un client de voix sur IP, recevra les flux de voix sur IP et de visio sur IP et transmettra les données de voix sur IP au processus gérant les sessions de voix sur IP et les données de visio sur IP au processus gérant l’application de visio sur IP, possiblement déployé sur un autre terminal que le client de voix sur IP. Ce procédé permet ainsi d’économiser les ports de destination utilisés pour multiplexer les flux applicatifs dans une connexion au niveau transport tout en assurant le procédé de multiplexage nécessaire pour transmettre des flux applicatifs distincts sur une même connexion entre deux équipements. Le dispositif de multiplexage comprend des moyens pour pouvoir analyser les identifiants reçus et d’autre part déterminer si les deux identifiants correspondent à une application dont le dispositif de multiplexage est apte à gérer les données.
Le procédé d’aiguillage permet ainsi de différencier de façon non ambiguë des données relatives à plusieurs applications transportées simultanément sur le même protocole de transport.
Selon un aspect de l'invention, le procédé d’aiguillage comprend en outre l’émission d’un message d’erreur au dispositif terminal dans le cas où une application n’est pas déterminée.
Le dispositif terminal peut avantageusement être informé d’un problème de sélection d’identifiants, de paramétrage d’identifiants, et/ou d’un problème de compatibilité du dispositif d’aiguillage pour pouvoir le cas échéant changer de dispositif d’aiguillage, initialiser une nouvelle connexion SCTP et/ou vérifier l’un ou l’autre des identifiants transmis.
Selon un autre aspect de l’invention, dans le procédé d’aiguillage, le message d’erreur est un paquet du protocole de transport de flux comprenant un fragment contenant un code d’erreur de type Abort.
L’utilisation d’un message Abort, c’est-à-dire l’envoi d’un fragment comprenant une information Abort, permet de pouvoir mettre fin à l’association SCTP entre le dispositif terminal et le dispositif d’aiguillage et de recourir à un message défini dans la spécification du protocole SCTP.
Selon un autre aspect de l’invention, dans le procédé d’aiguillage, le message d’erreur comprend une cause d’échec destinée à l’application mise en œuvre dans le dispositif terminal.
Comme indiqué ci-dessus des causes diverses peuvent occasionner la réception d’un message d’erreur de la part du dispositif d’aiguillage. Il est donc avantageux de prévoir des causes d’échecs correspondant aux problèmes que peut rencontrer le dispositif d’aiguillage et ainsi permettre au dispositif terminal de pouvoir recourir à une solution idoine par rapport à la cause d’échec reçue.
Selon un autre aspect de l’invention, dans le procédé d’aiguillage, le premier identifiant de port de destination est un identifiant de port dédié au procédé d’aiguillage.
L’identifiant de port de destination peut être un port dédié au procédé d’aiguillage permettant ainsi au dispositif d’aiguillage de recourir directement et sans autre examen des paquets à un processus d’aiguillage. D’autre part, un port dédié au procédé d’aiguillage évite les problèmes de conflit d’identifiants si un même identifiant est utilisé pour deux procédés ou deux applications distinctes. Un tel port dédié peut ainsi être mis en œuvre dans un réseau public (Internet) ou un réseau privé (réseau mobile basé sur les spécifications 3GPP).
Selon un autre aspect de l’invention, dans le procédé d’aiguillage, le premier identifiant de port de destination est un identifiant de port déjà alloué pour le protocole TCPMux.
Le protocole TCPMux utilise d’ores et déjà un port spécifique pour le multiplexage de flux applicatifs sur une connexion TCP selon une méthode distincte du procédé d’aiguillage. Cependant, notamment dans le cas où le protocole TCPMux et le procéé d’aiguillage sont exploités par une même entité, l’utilisation d’un même identifiant de port pour les deux méthodes présente l’avantage de simplifier la gestion des services de multiplexage basés sur l’un ou l’autre des protocoles et procédé.
Selon un autre aspect de l’invention, dans le procédé d’aiguillage, le premier identifiant de port de destination est un identifiant de port alloué pour une application basée sur le protocole SCTP.
Le premier identifiant de port de destination peut être un identifiant d’une application SCTP, donc un identifiant déjà utilisé pour un autre besoin, permettant de ne pas recourir à un identifiant spécifique et préservant ainsi les identifiants à utiliser pour les applications et procédés s’appuyant sur SCTP.
Les différents aspects du procédé d’aiguillage qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un procédé de configuration d’un paquet d’un protocole de transport de flux tel que le protocole Stream Control Transport Protocol, le paquet comprenant un en-tête et un fragment de données, le procédé étant mis en œuvre par un dispositif terminal apte à émettre une donnée relative à une application à un dispositif de multiplexage, et comprenant le paramétrage du paquet avec un premier identifiant de port de destination dans l’en-tête et avec un deuxième identifiant spécifique à l’application dans le fragment de données, ainsi que l’émission à destination du dispositif de multiplexage du paquet paramétré.
Selon un autre aspect de l’invention, le procédé de configuration comprend en outre la réception d’un message d’erreur si aucune application n’est déterminée par le dispositif de multiplexage à partir du premier identifiant et du deuxième identifiant paramétrés.
Les différents aspects du procédé de configuration qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un dispositif d’aiguillage apte à transférer des données relatives à une pluralité d’applications à des entités de traitement, une des données étant transportée dans un fragment de données d’un paquet d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, comprenant
- un récepteur, apte à recevoir en provenance d’un dispositif terminal, le paquet du protocole de transport de flux comprenant un en-tête contenant un premier identifiant de port de destination commun à la pluralité d’applications, et le fragment de données comprenant un deuxième identifiant spécifique à l’application,
- un module de détermination, apte à déterminer l’application en fonction du premier et du deuxième identifiant reçus,
- un émetteur, apte à émettre la donnée à destination d’une entité en charge du traitement de la donnée de l’application dans le cas où l’application est déterminée.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé d’aiguillage qui vient d'être décrit, est destiné à être mis en œuvre dans serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)). Le dispositif 100 peut également être mis en œuvre dans un équipement utilisateur.
- un récepteur, apte à recevoir en provenance d’un dispositif terminal, le paquet du protocole de transport de flux comprenant un en-tête contenant un premier identifiant de port de destination commun à la pluralité d’applications, et le fragment de données comprenant un deuxième identifiant spécifique à l’application,
- un module de détermination, apte à déterminer l’application en fonction du premier et du deuxième identifiant reçus,
- un émetteur, apte à émettre la donnée à destination d’une entité en charge du traitement de la donnée de l’application dans le cas où l’application est déterminée.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé d’aiguillage qui vient d'être décrit, est destiné à être mis en œuvre dans serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)). Le dispositif 100 peut également être mis en œuvre dans un équipement utilisateur.
L’invention concerne également un dispositif de configuration d’un paquet d’un protocole de transport de flux tel que le protocole Stream Control Transport Protocol, le paquet comprenant un en-tête et un fragment de données, comprenant
- un module de paramétrage, apte à paramétrer le paquet avec un premier identifiant de port de destination dans l’en-tête et avec un deuxième identifiant spécifique à une application dans le fragment de données
- un émetteur, apte à émettre à destination d’un dispositif de multiplexage le paquet paramétré.
- un module de paramétrage, apte à paramétrer le paquet avec un premier identifiant de port de destination dans l’en-tête et avec un deuxième identifiant spécifique à une application dans le fragment de données
- un émetteur, apte à émettre à destination d’un dispositif de multiplexage le paquet paramétré.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de configuration qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement utilisateur ou bien une passerelle d’un réseau personnel. Il peut également être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)).
L’invention concerne aussi un système d’aiguillage d’une donnée relative à une application transportée dans un fragment d’un paquet d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, comprenant
- un dispositif de multiplexage comprenant un dispositif d’aiguillage,
- un dispositif terminal comprenant un dispositif de configuration.
- un dispositif de multiplexage comprenant un dispositif d’aiguillage,
- un dispositif terminal comprenant un dispositif de configuration.
L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs d’aiguillage et de configuration qui viennent d'être décrits, lorsque ces programmes sont l’un et l’autre exécutés par un processeur et un support d’enregistrement lisible respectivement par un dispositif d’aiguillage et de configuration sur lesquels sont enregistrés les programmes d’ordinateurs.
L'invention vient en outre améliorer la situation à l'aide d'un procédé de médiation d’une pluralité d’applications utilisateur par l’intermédiaire d’une application relative au protocole de transport de contrôle de flux, tel que le protocole Stream Control Transport Protocol, dite application générique, le procédé étant mis en œuvre dans un dispositif mandataire, apte à établir une connexion basée sur le protocole de transport de flux avec un dispositif terminal, et comprenant la réception en provenance du dispositif terminal d’un paquet de requête du protocole de transport de contrôle de flux comprenant un fragment de données contenant un identifiant d’une application utilisateur requis par le dispositif terminal, la vérification que l’application utilisateur requise est une application de la pluralité, et dans le cas où l’application utilisateur requise est une application de la pluralité, l’émission à destination du dispositif terminal d’un message d’accord.
L’association d’une connexion SCTP entre le dispositif terminal et le dispositif mandataire est établie par un échange de messages INIT, INIT ACK, COOKIE-ECHO et COOKIE-ACK. Une fois que l’association est établie, les dispositifs peuvent échanger des données d’application utilisateur. Le procédé permet l’échange de données d’applications utilisateur diverses (voix sur IP, visio sur IP, monitoring…) en recourant à une application de médiation, ou générique, mise en œuvre dans un dispositif de médiation. Ainsi, le port de destination de l’en-tête du protocole SCTP est propre à cette application de médiation, permettant d’économiser des ports qui seraient utilisés pour distinguer les données des applications utilisateur, ce port destination dédié à l’application générique est en outre utilisé dans les messages SCTP échangés lors de l’établissement de l’association. Une fois l’association établie, le dispositif terminal transmet un message de requête SCTP nouveau et inventif, permettant d’interroger le dispositif mandataire sur sa capacité à assurer la médiation pour les applications utilisateur dont il transmet les identifiants. Seulement dans le cas où effectivement le dispositif mandataire est apte à assurer la médiation pour une application utilisateur, le dispositif terminal peut émettre des données de l’application utilisateur que le dispositif mandataire sera apte à transmettre à un serveur applicatif, à un client des données de l’application utilisateur ou à un processus gérant l’application utilisateur déployé sur le serveur mandataire. Le procédé permet donc au dispositif terminal de transmettre des données utilisateur avec garantie de leur traitement par le dispositif mandataire et au dispositif mandataire d’informer dynamiquement les dispositifs terminaux de ses capacités de traitement des données utilisateur tout en préservant en outre les ports de destination utilisés pour le transport des données des applications utilisateur.
Selon un aspect de l'invention, dans le procédé de médiation, le paquet de requête comprend en outre un en-tête contenant un identifiant de port de destination dédié à l’application générique.
L’identification du paquet de requête reçu est facilitée par l’exploitation du port de destination présent dans les paquets SCTP transmis par le dispositif terminal. En outre dans le cas où un nombre important d’applications utilisateur sont gérées par le dispositif mandataire, il peut être avantageux de déployer plusieurs applications génériques, et de répartir la médiation des applications utilisateurs sur ces différentes applications génériques. Notamment dans ce cas, l’exploitation du port de destination présent dans l’en-tête du paquet SCTP reçu est particulièrement avantageuse.
Selon un aspect de l'invention, dans le procédé de médiation, le message d’accord comprend au moins un identifiant d’application utilisateur de la pluralité accessible à partir de l’application générique.
Le dispositif mandataire s’appuie efficacement sur le message de requête reçu pour informer le dispositif terminal de ses capacités en termes d’applications utilisateurs pour lesquelles il assure la médiation. Le message de requête reçu peut être exploité pour émettre la liste des identifiants des applications utilisateur, indépendamment des identifiants reçus dans le message de requête reçu, correspondant ainsi à une méthode Push mise en œuvre par le dispositif mandataire pour informer le dispositif terminal.
Selon un aspect de l'invention, le procédé de médiation comprend en outre la réception en provenance du dispositif terminal, d’un paquet applicatif du protocole de transport de flux comprenant un fragment de données contenant l’identifiant spécifique à l’application utilisateur requise et une donnée applicative propre à l’application utilisateur requise, et l’émission à destination de l’application utilisateur requise de la donnée applicative reçue.
Le dispositif terminal, par exemple un équipement utilisateur, exploite le message d’accord reçu et les informations présentes dans ce message pour émettre les données applicatives en utilisant des protocoles applicatifs au-dessus de SCTP à destination du dispositif mandataire et plus spécifiquement de l’application générique. L’avantage du procédé est notamment pour le dispositif terminal d’obtenir des identifiants d’applications de façon préventive (en mode push) lui permettant d’émettre des données relatives à ces applications sans nécessiter l’envoi d’un nouveau message de requête SCTP.
Selon un aspect de l'invention, le procédé de médiation comprend l’émission à destination du dispositif terminal d’un message d’échec dans le cas où l’identifiant de l’application utilisateur requise ne correspond pas à une application utilisateur de la pluralité.
Le dispositif terminal peut avantageusement être informé d’un problème de sélection d’identifiants, de paramétrage d’identifiants, et/ou d’un problème de compatibilité du dispositif mandataire, de disponibilité de l’application générique pour recevoir des flux de données d’applications utilisateurs, pour pouvoir le cas échéant changer de dispositif mandataire, initialiser une nouvelle connexion SCTP et/ou vérifier l’un ou l’autre des identifiants transmis, mettre en mémoire les données des applications utilisateur à émettre.
Selon un aspect de l'invention, dans le procédé de médiation, le message d’échec est un paquet du protocole de transport de flux, comprenant un fragment de type Abort mettant fin à une association établie entre le dispositif terminal et le dispositif mandataire.
L’utilisation d’un message Abort, c’est-à-dire l’envoi d’un fragment comprenant une information Abort, permet de pouvoir mettre fin à l’association SCTP entre le dispositif terminal et le dispositif mandataire et de recourir à un message défini dans la spécification du protocole SCTP.
Selon un aspect de l'invention, dans le procédé de médiation, le message d’échec comprend en outre une cause d’échec destinée à l’entité du dispositif terminal requérant l’application.
Des problèmes divers peuvent occasionner la réception d’un message d’erreur de la part du dispositif mandataire. Il est donc avantageux de prévoir des causes d’échecs correspondant aux problèmes que peut rencontrer le dispositif mandataire et/ou l’application générique et ainsi permettre au dispositif terminal de pouvoir recourir à une solution adaptée (sollicitation d’une autre application générique, configuration d’un nouveau paquet de requête, association avec un autre dispositif mandataire) par rapport à la cause d’échec reçue.
Les différents aspects du procédé de médiation qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un procédé de paramétrage d’un paquet de requête d’un protocole de transport de contrôle de flux, tel que le protocole Stream Control Transport Protocole, émis à destination d’un dispositif mandataire, le procédé étant mis en œuvre par dispositif terminal apte à communiquer avec le dispositif mandataire, et comprenant la détermination d’un paquet de requête du protocole de transport de contrôle de flux, comprenant, un fragment de données comprenant une donnée d’identification d’une application utilisateur requise par le dispositif terminal, et l’émission à destination du dispositif mandataire du paquet de requête déterminé.
Selon un aspect de l'invention, le procédé de paramétrage comprend en outre l’émission à destination du dispositif mandataire d’un paquet applicatif du protocole de transport de flux comprenant un fragment de données contenant un identifiant spécifique à l’application requise et une donnée applicative propre à l’application requise.
Selon un aspect de l'invention, dans le procédé de paramétrage, le paquet de requête déterminé comprend en outre un en-tête contenant un identifiant de port destination dédié à une application relative au protocole de transport de contrôle de flux, dite application générique.
Les différents aspects du procédé de paramétrage qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un dispositif de médiation d’une pluralité d’applications utilisateur par l’intermédiaire d’une application relative à un protocole de transport de contrôle de flux, tel que le protocole Stream Control Transport Protocol, dite application générique, apte à établir une connexion basée sur le protocole de transport de flux avec un dispositif terminal, et comprenant
- un récepteur, apte à recevoir en provenance du dispositif terminal un paquet de requête du protocole de transport de contrôle de flux comprenant un fragment de données contenant un identifiant d’une application utilisateur requis par le dispositif terminal,
- un module de vérification apte à vérifier que l’application utilisateur requise est une application de la pluralité,
- un émetteur, apte à émettre à destination du dispositif terminal un message d’accord dans le cas où l’application utilisateur requise est une application de la pluralité.
- un récepteur, apte à recevoir en provenance du dispositif terminal un paquet de requête du protocole de transport de contrôle de flux comprenant un fragment de données contenant un identifiant d’une application utilisateur requis par le dispositif terminal,
- un module de vérification apte à vérifier que l’application utilisateur requise est une application de la pluralité,
- un émetteur, apte à émettre à destination du dispositif terminal un message d’accord dans le cas où l’application utilisateur requise est une application de la pluralité.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de médiation qui vient d'être décrit, est destiné à être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)). Le dispositif 100 peut également être mis en œuvre dans un équipement utilisateur
L’invention concerne également un dispositif de paramétrage d’un paquet de requête d’un protocole de transport de contrôle de flux, tel que le protocole Stream Control Transport Protocole, émis à destination d’un dispositif mandataire, mis en œuvre dans un dispositif terminal et comprenant
- un module de détermination, apte à déterminer un paquet de requête du protocole de transport de contrôle de flux, comprenant un fragment de données comprenant une donnée d’identification d’une application utilisateur requise par le dispositif terminal,
- un émetteur, apte à émettre à destination du dispositif mandataire le paquet de requête déterminé.
- un module de détermination, apte à déterminer un paquet de requête du protocole de transport de contrôle de flux, comprenant un fragment de données comprenant une donnée d’identification d’une application utilisateur requise par le dispositif terminal,
- un émetteur, apte à émettre à destination du dispositif mandataire le paquet de requête déterminé.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de paramétrage qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement utilisateur ou bien une passerelle d’un réseau personnel. Il peut également être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)).
L’invention concerne aussi un système de médiation d’une pluralité d’applications utilisateur par l’intermédiaire d’une application relative à un protocole de transport de contrôle de flux, tel que le protocole Stream Control Transport Protocol, dite application générique, comprenant
- un dispositif mandataire comprenant un dispositif de médiation,
- un dispositif terminal comprenant un dispositif de paramétrage.
- un dispositif mandataire comprenant un dispositif de médiation,
- un dispositif terminal comprenant un dispositif de paramétrage.
L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs de médiation et de paramétrage qui viennent d'être décrits, lorsque ces programmes sont l’un et l’autre exécutés par un processeur et un support d’enregistrement lisible respectivement par un dispositif de médiation et de paramétrage sur lesquels sont enregistrés les programmes d’ordinateurs.
Les programmes mentionnés ci-dessus peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
Les supports d'informations mentionnés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique.
Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc.
D'autre part, un support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question.
4. Brève description des dessins
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La présente une vue simplifiée d’une communication entre deux nœuds selon l’art antérieur,
La présente une vue simplifiée d’une communication entre deux nœuds selon un aspect de l’invention,
La présente une vue simplifiée d’une communication entre deux nœuds selon un autre aspect de l’invention,
La présente un aperçu du procédé d’aiguillage d’une donnée relative à une application et du procédé de configuration selon un mode de réalisation de l’invention,
La présente un aperçu du procédé de médiation d’une pluralité d’applications par l’intermédiaire d’une application générique et du procédé de paramétrage selon un mode de réalisation de l’invention
La présente un dispositif d’aiguillage d’une donnée relative à une application selon un mode de réalisation de l'invention,
La présente un dispositif de configuration d’un paquet d’un protocole de transport de flux selon un mode de réalisation de l'invention,
La présente un dispositif de médiation d’une pluralité d’applications par l’intermédiaire d’une application générique selon un mode de réalisation de l'invention,
La présente un dispositif de paramétrage d’un paquet protocole de transport de contrôle de flux selon un mode de réalisation de l'invention.
5. Description des modes de réalisation
Dans la suite de la description, on présente des modes de réalisation de l'invention dans une infrastructure de communication. Cette infrastructure peut être mise en œuvre pour acheminer des données de communications à destination de terminaux fixes ou mobiles et l’invention peut être destinée à installer des fonctions virtualisées utilisées pour l’acheminement et/ou le traitement de données de clientèle résidentielle ou d’entreprises.
On se réfère tout d’abord à la qui présente une vue simplifiée d’une communication entre deux nœuds selon un aspect de l’invention. Comme sur la pour les nœuds 400 et 410, un nœud 100, correspondant à un dispositif terminal, transmet des données applicatives des applications App1, App2 à un nœud 110, et émet des paquets IP comprenant l’adresse IP (source) du nœud 100, l’adresse IP (destination) du nœud 110, le port PS (source) du protocole SCTP de transport, le port (destination) du protocole SCTP de transport et des données applicatives relatives aux applications App1 et App2. Les nœuds 100 et 110 peuvent être indifféremment des terminaux, des serveurs, des équipements de communication de téléphonie et/ou visiophonie, des entités de routage et/ou de gestion d’un réseau de communication. Les applications App1 et App2 peuvent être des applications permettant à des utilisateurs des nœuds 100 et 110 d’accéder à des services à valeur ajoutée, des applications de gestion d’un réseau de communication, ou de façon indifférente toute application dont les données sont transportées sur un réseau Internet. Seules deux applications App1 et App2 sont représentées sur les et mais il n’existe pas à priori de limites quant au nombre d’applications pouvant bénéficier du procédé d’aiguillage. Le protocole SCTP utilisé pour le transport des données des applications App1 et App2 comprend un en-tête comprenant le port source PS et le port destination P0. A la différence de la où les ports destination (pour rappel P1 et P2) distinguaient les applications (respectivement App1 et App2), le port destination P0 est commun aux deux applications App1 et App2 et ne permet donc pas de différencier les données des applications App1 et App2. A la réception des paquets SCTP, le nœud 110 correspondant à un dispositif de multiplexage comprenant un dispositif d’aiguillage, ne peut différencier les données des applications App1 et App2 par la seule lecture et interprétation du port destination de l’en-tête du protocole SCTP. Pour assurer l’aiguillage des données des applications App1 et App2 vers les entités ou les applications logicielles gérant ces deux applications, une autre information présente dans un fragment de données (en anglais DATA Chunk) du paquet SCTP est utilisée en complément du port destination P0. Cette information est un identifiant PPI1 (en anglais Payload Protocol Identifier 1) présent dans chaque fragment de données du protocole SCTP. Ainsi, avec le premier identifiant P0 de l’en-tête du protocole SCTP et le deuxième identifiant PPI1 d’un fragment du protocole SCTP, le dispositif de multiplexage est capable d’aiguiller les données de l’application App1, correspondant aux identifiant P0 – PPI1, vers l’entité en charge de l’application App1. A la réception d’un paquet comprenant les deux identifiants P0 et PPI1, le nœud 110, apte à analyser les paquets SCTP, vérifie que ces identifiants correspondent à des applications pour lesquelles il peut aiguiller les données et si c’est le cas, il transmet les données à l’application App1. L’application App1 correspond ici à une entité physique ou logicielle apte à gérer les données de l’application App1. Dans le cas où les données de l’application App1 sont relatives à un service de voix sur IP, les données de l’application pourront être transférées à une entité logicielle présente sur le nœud 110 ou bien à une autre entité physique possiblement en utilisant un protocole de communication entre le nœud 110 et cette autre entité physique différent du protocole SCTP. De la même façon, lorsque le nœud 110 reçoit un paquet SCTP comprenant un en-tête contenant un port destination P0 et un fragment comprenant un identifiant PPI2, si l’application App2 correspondant aux identifiants P0 et PPI2 fait partie des applications multiplexées par le nœud 110, alors il transmet les données de l’application App2 à l’entité en charge de l’application App2. La mise en œuvre de l’invention présentée dans la est symétrique et les nœuds 100 et 110 peuvent être commutés, le nœud 100 pouvant correspondre au dispositif de multiplexage et le nœud 110 à un dispositif terminal. Les deux nœuds 100 et 110 peuvent ainsi comprendre des dispositifs de multiplexage, chaque nœud 100 et 110 pouvant comprendre un dispositif de configuration et de un dispositif de multiplexage. Lors d’une communication bidirectionnelle, l’un des deux nœuds joue le rôle du dispositif de multiplexage et l’autre nœud joue le rôle du dispositif de configuration. Il est à noter que dans le cadre d’une communication bidirectionnelle, les données applicatives transmises par le nœud 110 ou via le nœud 110 à destination du nœud 100, sont transmises dans des paquets SCTP conformément aux spécifications du protocole, notamment en utilisant les informations d’adresse IP source, adresse IP de destination, port source et port de destination.
Selon un exemple, dans le cas où les identifiants reçus par le nœud 110 correspondent à une application pour laquelle le nœud 110 n’effectue pas l’aiguillage des données, ou bien qu’il n’est pas possible d’identifier une application à partir de ces identifiants, alors un message d’erreur est transmis au nœud 100.
Selon un autre exemple, si un message d’erreur est transmis, ce message peut avantageusement être un paquet SCTP comprenant un code d’erreur Abort. Selon une alternative, le message d’erreur peut en outre comprendre un code d’échec permettant au nœud 100 d’identifier la cause, selon que c’est une mauvaise formation du paquet SCTP transmis au nœud 110 ou bien que le nœud 110 n’a pas été correctement sélectionné ou bien encore que les identifiants n’ont pas été correctement positionnés.
Selon un exemple, le premier identifiant de port de destination positionné dans l’en-tête du protocole SCTP est un port dédié au procédé de multiplexage facilitant le traitement à effectuer sur le paquet reçu pour le nœud 110. Selon une alternative, le port dédié utilisé comme premier identifiant peut être le port numéro 1 utilisé notamment par le protocole TCPMux, spécifié dans le document IETF RFC 1078, permettant d’identifier ainsi un port commun de multiplexage pour une diversité de protocoles de transport. Selon une alternative, le premier identifiant de port de destination correspond à un port d’ores et déjà utilisé pour une application s’appuyant sur SCTP, par exemple attribué par l’IANA, évitant ainsi de recourir à un nouveau numéro de port de destination.
On se réfère maintenant à la qui présente une vue simplifiée d’une communication entre deux nœuds selon un autre aspect de l’invention.
Comme sur la et la pour les nœuds respectifs 400, 410, 100 110, un nœud 300, correspondant à un dispositif terminal, transmet des données applicatives des applications App1, App2 à un nœud 310, correspondant à un dispositif mandataire, et émet des paquets IP comprenant l’adresse IP (source) du nœud 300, l’adresse IP (destination) du nœud 310, le port PS (source) du protocole SCTP de transport, le port (destination) du protocole SCTP de transport et des données applicatives relatives aux applications App1 et App2.
Selon cet aspect de l’invention, une application AppM relative au protocole SCTP, dite application générique, est également déployée sur le nœud 310. Les applications App1 et App2 peuvent, selon un exemple, être mises en œuvre dans des équipements distincts du nœud 310.
Le protocole SCTP utilisé pour le transport des données des applications App1 et App2 comprend un en-tête comprenant le port source PS et le port destination PM. A la différence de la où les ports destination (pour rappel P1 et P2) distinguaient les applications (respectivement App1 et App2), et de la où le port destination P0 bien que commun aux deux applications App1 et App2, n’identifiait pas de façon spécifique une application, le port destination PM du protocole SCTP identifie de façon non ambigüe l’application générique AppM. Ainsi, tous les paquets d’association SCTP comprenant le port destination PM sont acheminés vers l’application AppM. Le port PM est certes spécifique à l’application générique, mais comme un seul port est requis répondant à la problématique de disponibilité de ports. Indépendamment de l’application App1 et App2 destinataires des paquets émis vers le nœud 310, ceux-ci sont acheminés vers l’application AppM et ne permet donc pas de différencier les données des applications App1 et App2. Le nœud 310, par l’intermédiaire de l’application AppM, comprend un dispositif de médiation pour les flux de données destinés aux applications utilisateur App1 et App2. En effet, le nœud 310, à la réception des paquets de requête SCTP exploite une donnée d’identification, respectivement RPPI1 (en anglais Required Payload Protocol Identifier 1) et RPPI2 correspondant à des identifiant d’applications App1 et App2 requises par le nœud 100. Ces identifiants transmis dans un seul message de requête ou dans deux messages de requête distincts sont présents dans les fragments du protocole SCTP pour vérifier que les applications App1 et App2 font bien partie des applications pour lesquelles le nœud mandataire 310 assure la médiation. Si c’est le cas, le nœud 310 transmet un message d’accord, par exemple en utilisant le protocole SCTP, au nœud 300 l’information qu’une connexion SCTP pour l’application App1 peut être opérée entre le nœud 300 et le nœud 310, cette connexion étant opérée via l’application générique AppM. Cet aspect de l’invention permet donc, comme le premier aspect de l’invention, de pouvoir multiplexer des flux applicatifs relatifs à une pluralité d’applications, tout en préservant les ports destination utilisés pour l’acheminement des paquets SCTP.
Selon une alternative, le nœud 310 peut utiliser en outre l’identifiant de port de destination PM en plus des identifiants d’applications utilisateur requises (ici RPPI1 et RPPI2) pour vérifier que les applications utilisateurs App1 et App2 déterminées à partir de ces identifiants font partie des applications pour lesquelles le nœud mandataire 310 assure la médiation.
Selon un exemple, le message d’accord comprend un identifiant PPI1 (respectivement PPI2) correspondant à l’application pour laquelle le message de succès est transmis au nœud 100 et qui pourra être utilisé pour marquer le fragment comprenant les données de l’application App1 (respectivement App2) transmises au nœud 310 lors de l’envoi de ces données au nœud 310.
Selon un exemple, le nœud 300 transmet ensuite au nœud 310, un paquet SCTP comprenant l’en-tête contenant le port destination PM et un identifiant PPI1 (respectivement PPI2) correspondant à l’application App1 (respectivement PPI2) obtenu dans le message de réponse reçu ou bien mémorisé dans le nœud 300. A la réception, conformément au message de succès transmis, le nœud 310 transmet les données applicatives relatives à l’application App1 (respectivement App2) à l’application App1 (respectivement App2) ou à l’entité en charge de la réception et du traitement de ces données applicatives présents dans les fragments SCTP.
Selon un exemple, dans le cas où l’application App1 ne fait pas partie des applications pour lesquelles le nœud 310 assure la médiation, un message d’échec est transmis au nœud 300 lui indiquant ainsi que le nœud 310 n’est pas apte à recevoir et le cas échéant à transférer vers une entité distincte, les données relatives à l’application App1 pour lesquelles le nœud 310 a été sollicité via le paquet d’association reçu.
Selon un autre exemple, le message de succès comprend l’ensemble des identifiants, par exemple PPI1 et PPI2, des applications pour lesquelles le nœud 310 assure la médiation indépendamment des identifiants des applications utilisateur requises par le nœud 300.
Comme pour les nœuds de la , les nœuds 300 et 310 peuvent comprendre les deux dispositifs, à savoir le dispositif terminal et le dispositif de médiation, et les utiliser en fonction du nœud qui initie la connexion SCTP.
En relation avec la , on présente un aperçu du procédé d’aiguillage d’une donnée relative à une application et du procédé de configuration selon un premier mode de réalisation de l’invention. Dans cette , deux nœuds 100 et 110 communiquent par exemple via un réseau de communication, tel que le réseau Internet, une infrastructure mobile, un réseau d’entreprise ou tout type d’infrastructure permettant au nœud 100 et au nœud 110 de s’échanger des paquets SCTP.
Lors d’une étape 200, le nœud 100, comprenant un dispositif de configuration, transmet un message SCTP INIT au nœud 110. Ce message SCTP comprend plus spécifiquement un fragment de contrôle INIT pour établir une association avec le nœud 110.
En réponse au message SCTP INIT reçu du nœud 100, le nœud 110 émet lors de l’étape 210 à destination du nœud 100 un message SCTP INIT ACK au nœud 100 lors de l’étape 210. Ce message comprend notamment un fragment de contrôle INIT ACK ainsi qu’une information Cookie d’état (en anglais Cookie State).
En réponse au message SCTP INIT ACK reçu, le nœud 100 émet à destination du nœud 110 un message SCTP de réponse COOKIE-ECHO lors de l’étape 220. Ce message permet de finaliser l’association SCTP entre les nœuds 100 et 110, initialisée par le nœud 100. Le message comprend un fragment contenant la valeur du Cookie d’état reçue dans le message SCTP INIT ACK.
En réponse au message COOKIE-ECHO reçu, le nœud 110 émet lors de l’étape 230 un message SCTP COOKIE-ACK après avoir vérifié l’authenticité de la valeur du cookie state reçu. Ce message COOKIE-ACK acquitte le message COOKIE-ECHO et la session SCTP est effectivement établie entre le nœud 100 et le nœud 110 une fois que ce message a été reçu par le nœud 100.
Une fois la session SCTP établie, le nœud 100 émet des données applicatives relatives à une application App1 à destination du nœud 110 lors d’une étape 240. Plus précisément, le message SCTP émis par le nœud 100 comprend un en-tête dont le port de destination est un port non spécifique à une application mais un port commun à un ensemble d’applications. Le message SCTP comprend en outre au moins un fragment comprenant un identifiant de l’application App1, tel qu’une suite de caractères identifiant l’application App1, ainsi que des données applicatives destinées à un processus ou une entité en charge de recevoir, traiter, et émettre des données de l’application App1. Le nœud 100, à partir d’un dispositif de configuration, lors d’une étape 235, paramètre le paquet SCTP comprenant l’en-tête et l’au moins un fragment, et émet, lors de l’étape 240, le paquet paramétré à destination du nœud 110, ce nœud 110 comprenant un dispositif d’aiguillage.
A la réception du message SCTP, le nœud 110 comprenant le dispositif d’aiguillage, vérifie lors d’une étape 245 que l’identifiant de port de destination et l’identifiant de l’application reçus dans le paquet SCTP, correspondent à une application pour laquelle le dispositif d’aiguillage route les données applicatives, et si c’est le cas, le dispositif d’aiguillage émet les données applicatives de l’application App1 vers les entités en charge de l’application App1. Dans le cas défavorable, où les identifiants de l’en-tête et du fragment ne permettent pas d’identifier une application ou si l’application identifiée ne fait pas partie des applications dont les données sont aiguillées par le nœud 110, le nœud 110 émet un message d’erreur, par exemple un message SCTP comprenant un fragment ABORT au nœud 100 lors d’une étape 250.
On se réfère maintenant à la qui présente un aperçu du procédé de médiation d’une pluralité d’applications par l’intermédiaire d’une application générique et du procédé de paramétrage selon un mode de réalisation de l’invention.
Les quatre premières étapes 500, 510, 520, 530 sont équivalentes aux étapes respectives 200, 210, 220, 230 à la différence que le port de destination de l’en-tête des messages 300 et 320 est un port source correspondant à une application générique de médiation SCTP. A l’issue de la réception du message COOKIE-ACK lors de l’étape 330, les nœuds 300 et 310 ont établi une session SCTP s’appuyant sur une application générique de médiation.
Lors d’une étape 535, le nœud 300 paramètre un paquet SCTP avec un en-tête comprenant le port de destination correspondant à une application générique de médiation et avec un fragment de données comprenant des identifiants d’application requis par le dispositif 300. Les identifiants requis correspond à des identifiants dont le nœud 300 souhaite savoir si l’application générique assure la médiation pour les données applicatives des applications correspondant à ces identifiants. Lors d’une étape 540, le nœud 300 émet à destination du nœud 310 un message de requête SCTP dont l’en-tête contient le port de destination paramétré avec un identifiant de l’application générique, et au moins un fragment comprenant un ou plusieurs identifiants d’applications utilisateur requises par le nœud 300. Le nœud 300, par ce message, indique au nœud 310 qu’il souhaite savoir si le nœud 310 accepte de recevoir des données et de les transmettre à des entités logicielles présentes sur le nœud 310 ou à des nœuds distincts du nœud 310 pour une ou plusieurs applications utilisateur dont l’identifiant ou les identifiants se trouvent dans le fragment du paquet de requête SCTP. Le nœud 300 peut choisir de transmettre un message de requête par application utilisateur ou bien de transmettre un message de requête pour un ensemble d’applications utilisateur.
A la réception du message de requête, le nœud 310 examine lors d’une étape 545 s’il assure la médiation pour l’identifiant ou les identifiants reçus et transmet au nœud 300 lors d’une étape 550, en réponse au message de requête, un message d’accord indiquant au nœud 300 qu’il est apte à recevoir des messages SCTP pour l’application utilisateur ou les applications utilisateur dont l’identifiant ou les identifiants ont été reçus. Dans ce cas favorable, le nœud 300 peut émettre lors d’une étape 560 des paquets SCTP comprenant une donnée utilisateur propre à l’application ou à une des applications pour lesquelles le nœud 300 a émis un message de succès.
Dans le cas où seulement une partie des applications utilisateur correspondant aux identifiants reçus sont effectivement gérés par le nœud 310, le nœud 310 peut transmettre lors de l’étape 550 la liste des identifiants correspondant aux applications pour lesquelles il assure la médiation via l’application générique. Selon un autre exemple, le nœud 310 peut également informer le nœud 300 des applications pour lesquelles il assure la médiation en transmettant leurs identifiants, indépendamment de l’identifiant ou des identifiants reçus en provenance du nœud 300. Selon encore un autre exemple, le nœud 310 peut émettre un message d’échec, par exemple comprenant un fragment ABORT, si aucun des identifiants reçus ne correspond à une application pour laquelle il assure la médiation, mettant possiblement fin ainsi à la session SCTP entre le nœud 300 et le nœud 310.
Il est à noter que les modes de réalisation sont décrits en utilisant le protocole SCTP mais ces modes de réalisations pourraient également être proposés avec un protocole de transport de flux ayant des caractéristiques de la couche transport équivalentes au protocole SCTP.
En relation avec la , on présente un dispositif de configuration d’un paquet d’un protocole de transport de flux selon un mode de réalisation de l'invention.
Un tel dispositif 100, aussi appelé dispositif terminal, peut être mis en œuvre dans un équipement utilisateur ou bien une passerelle d’un réseau personnel. Il peut également être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)).
Par exemple, le dispositif 100 comprend une unité de traitement 1030, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 1010, stocké dans une mémoire 1020 et mettant en œuvre le procédé de détermination selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 1010 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 1030.
Un tel dispositif 100 comprend :
- un module 1001 de paramétrage, apte à paramétrer le paquet avec un premier identifiant de port de destination dans l’en-tête et avec un deuxième identifiant spécifique à une application dans le fragment de données
- un émetteur 1002, apte à émettre à destination d’un dispositif de multiplexage le paquet paramétré.
- un émetteur 1002, apte à émettre à destination d’un dispositif de multiplexage le paquet paramétré.
En relation avec la , on présente un dispositif d’aiguillage d’une donnée relative à une application selon un mode de réalisation de l'invention.
Un tel dispositif 110, aussi appelé dispositif de multiplexage, peut être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)). Le dispositif 100 peut également être mis en œuvre dans un équipement utilisateur.
Par exemple, le dispositif 110 comprend une unité de traitement 1130, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 1110, stocké dans une mémoire 1120 et mettant en œuvre le procédé de détermination selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 1110 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 1130.
Un tel dispositif 110 comprend :
- un récepteur 1101, apte à recevoir en provenance d’un dispositif terminal, le paquet Paq du protocole de transport de flux comprenant un en-tête contenant un premier identifiant de port de destination commun à la pluralité d’applications, et le fragment de données comprenant un deuxième identifiant spécifique à l’application,
- un module 1103 de détermination, apte à déterminer l’application en fonction du premier et du deuxième identifiant reçus,
- un émetteur 1102, apte à émettre la donnée Don à destination d’une entité en charge du traitement de la donnée de l’application dans le cas où l’application est déterminée..
- un module 1103 de détermination, apte à déterminer l’application en fonction du premier et du deuxième identifiant reçus,
- un émetteur 1102, apte à émettre la donnée Don à destination d’une entité en charge du traitement de la donnée de l’application dans le cas où l’application est déterminée..
En relation avec la , on présente un dispositif de paramétrage d’un paquet protocole de transport de contrôle de flux selon un mode de réalisation de l'invention.
Un tel dispositif 300, aussi appelé dispositif terminal, peut être mis en œuvre dans un équipement utilisateur ou bien une passerelle d’un réseau personnel. Il peut également être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)).
Par exemple, le dispositif 300 comprend une unité de traitement 3030, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 3010, stocké dans une mémoire 3020 et mettant en œuvre le procédé de détermination selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 3010 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 030.
Un tel dispositif 300 comprend :
- un module 3001 de détermination, apte à déterminer un paquet de requête Req du protocole de transport de contrôle de flux, comprenant un fragment de données comprenant une donnée d’identification d’une application utilisateur requise par le dispositif terminal,
- un émetteur 3002, apte à émettre à destination du dispositif mandataire le paquet de requête déterminé..
- un émetteur 3002, apte à émettre à destination du dispositif mandataire le paquet de requête déterminé..
En relation avec la , on présente un dispositif de médiation d’une pluralité d’applications par l’intermédiaire d’une application générique selon un mode de réalisation de l'invention,
Un tel dispositif 310, aussi appelé dispositif mandataire, peut être mis en œuvre dans un serveur applicatif, dans un routeur d’un réseau de communication ou d’un équipement intermédiaire (DPI (en anglais Deep Packet Inspection) ou pare-feu) ou bien encore dans un équipement d’un réseau mobile (passerelle d’accès, serveur d’une architecture MEC (en anglais Mobile Edge computing)). Le dispositif 100 peut également être mis en œuvre dans un équipement utilisateur.
Par exemple, le dispositif 310 comprend une unité de traitement 3130, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 3110, stocké dans une mémoire 3120 et mettant en œuvre le procédé de détermination selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 3110 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 3130.
Un tel dispositif 310 comprend :
- un récepteur 3101, apte à recevoir en provenance du dispositif terminal un paquet de requête Req du protocole de transport de contrôle de flux comprenant un fragment de données contenant un identifiant d’une application utilisateur requis par le dispositif terminal,
- un module 3102 de vérification apte à vérifier que l’application utilisateur requise est une application de la pluralité,
- un émetteur 3103, apte à émettre à destination du dispositif terminal un message d’accord Acc dans le cas où l’application utilisateur requise est une application de la pluralité.
- un module 3102 de vérification apte à vérifier que l’application utilisateur requise est une application de la pluralité,
- un émetteur 3103, apte à émettre à destination du dispositif terminal un message d’accord Acc dans le cas où l’application utilisateur requise est une application de la pluralité.
Claims (14)
- Procédé d’aiguillage d’une donnée relative à une application (App1, App2) transportée dans un fragment de données d’un paquet (Paq) d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, mis en œuvre par un dispositif (110) de multiplexage apte à transférer des données relatives à une pluralité d’applications (App1, App2) à des entités de traitement, et comprenant
- la réception (240), en provenance d’un dispositif (100) terminal, du paquet (Paq) du protocole de transport de flux comprenant un en-tête contenant un premier identifiant (P0) de port de destination commun à la pluralité d’applications (App1, App2), et le fragment de données comprenant un deuxième identifiant (PPI1, PPI2) spécifique à l’application (App1, App2),
- la détermination (245) de l’application en fonction du premier et du deuxième identifiant reçus,
- dans le cas où l’application est déterminée, l’émission de la donnée (Don) à destination d’une entité en charge du traitement de la donnée de l’application. - Procédé d’aiguillage, selon la revendication 1, comprenant l’émission (250) d’un message d’erreur au dispositif terminal dans le cas où une application n’est pas déterminée.
- Procédé d’aiguillage, selon la revendication 2, où le message d’erreur est un paquet du protocole de transport de flux comprenant un fragment contenant un code d’erreur de type Abort.
- Procédé d’aiguillage, selon la revendication 2 ou la revendication 3, où le message d’erreur comprend une cause d’échec destinée à l’application mise en œuvre dans le dispositif terminal.
- Procédé d’aiguillage, selon l’une des revendications précédentes 1 à 4, où le premier identifiant de port de destination est un identifiant de port dédié au procédé d’aiguillage.
- Procédé d’aiguillage, selon l’une des revendications 1 à 4, où le premier identifiant de port de destination est un identifiant de port déjà alloué pour le protocole TCPMux.
- Procédé d’aiguillage, selon l’une des revendications 1 à 4, où le premier identifiant de port de destination est un identifiant de port alloué pour une application basée sur le protocole SCTP.
- Procédé de configuration d’un paquet (Paq) d’un protocole de transport de flux tel que le protocole Stream Control Transport Protocol, le paquet (Paq) comprenant un en-tête et un fragment de données, le procédé étant mis en œuvre par un dispositif (100) terminal apte à émettre une donnée (Don) relative à une application à un dispositif (110) de multiplexage, et comprenant
- le paramétrage (235) du paquet (Paq) avec un premier identifiant de port de destination dans l’en-tête et avec un deuxième identifiant spécifique à l’application dans le fragment de données,
- l’émission (240) à destination du dispositif de multiplexage du paquet (Paq) paramétré. - Procédé de configuration, selon la revendication 8, comprenant en outre la réception (250) d’un message d’erreur si aucune application n’est déterminée par le dispositif de multiplexage à partir du premier identifiant et du deuxième identifiant paramétrés.
- Dispositif (110) d’aiguillage apte à transférer des données relatives à une pluralité d’applications (App1, App2) à des entités de traitement, une (Don) des données étant transportée dans un fragment de données d’un paquet (Paq) d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, comprenant
- un récepteur (1101), apte à recevoir en provenance d’un dispositif (100) terminal, le paquet (Paq) du protocole de transport de flux comprenant un en-tête contenant un premier identifiant (P0) de port de destination commun à la pluralité d’applications (App1, App2), et le fragment de données comprenant un deuxième identifiant (PPI1, PPI2) spécifique à l’application (App1, App2),
- un module (1103) de détermination, apte à déterminer l’application (App1, App2) en fonction du premier (P0) et du deuxième identifiant (PPI1, PPI2) reçus,
- un émetteur (1102), apte à émettre la donnée (Don) à destination d’une entité en charge du traitement de la donnée de l’application (App1, App2) dans le cas où l’application (App1, App2) est déterminée. - Dispositif (100) de configuration d’un paquet (Paq) d’un protocole de transport de flux tel que le protocole Stream Control Transport Protocol, le paquet (Paq) comprenant un en-tête et un fragment de données, comprenant
- un module (1001) de paramétrage, apte à paramétrer le paquet (Paq) avec un premier identifiant (P0) de port de destination dans l’en-tête et avec un deuxième identifiant (PPI1, PPI2) spécifique à une application (APP1, APP2) dans le fragment de données
- un émetteur (1002), apte à émettre à destination d’un dispositif (110) de multiplexage le paquet (Paq) paramétré. - Système d’aiguillage d’une donnée relative à une application transportée dans un fragment d’un paquet d’un protocole de transport de flux, tel que le protocole Stream Control Transport Protocol, comprenant
- un dispositif de multiplexage comprenant un dispositif (110) d’aiguillage selon la revendication 10,
- un dispositif terminal comprenant un dispositif (100) de configuration selon la revendication 11. - Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d’aiguillage selon l'une quelconque des revendications 1à 7, lorsque le programme est exécuté par un processeur.
- Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de configuration selon l'une quelconque des revendications 8 à 9, lorsque le programme est exécuté par un processeur.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2010883A FR3115644A1 (fr) | 2020-10-23 | 2020-10-23 | Procédé et dispositif d’aiguillage d’une donnée applicative |
| US18/250,094 US20240007549A1 (en) | 2020-10-23 | 2021-10-14 | Method and device for switching an item of application data |
| CN202180072482.XA CN116391351A (zh) | 2020-10-23 | 2021-10-14 | 用于交换应用数据项的方法和装置 |
| PCT/FR2021/051789 WO2022084605A1 (fr) | 2020-10-23 | 2021-10-14 | Procede et dispositif d'aiguillage d'une donnee applicative |
| EP21806010.1A EP4233302A1 (fr) | 2020-10-23 | 2021-10-14 | Procede et dispositif d'aiguillage d'une donnee applicative |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2010883 | 2020-10-23 | ||
| FR2010883A FR3115644A1 (fr) | 2020-10-23 | 2020-10-23 | Procédé et dispositif d’aiguillage d’une donnée applicative |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3115644A1 true FR3115644A1 (fr) | 2022-04-29 |
Family
ID=74125438
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2010883A Withdrawn FR3115644A1 (fr) | 2020-10-23 | 2020-10-23 | Procédé et dispositif d’aiguillage d’une donnée applicative |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20240007549A1 (fr) |
| EP (1) | EP4233302A1 (fr) |
| CN (1) | CN116391351A (fr) |
| FR (1) | FR3115644A1 (fr) |
| WO (1) | WO2022084605A1 (fr) |
-
2020
- 2020-10-23 FR FR2010883A patent/FR3115644A1/fr not_active Withdrawn
-
2021
- 2021-10-14 WO PCT/FR2021/051789 patent/WO2022084605A1/fr active Application Filing
- 2021-10-14 CN CN202180072482.XA patent/CN116391351A/zh active Pending
- 2021-10-14 EP EP21806010.1A patent/EP4233302A1/fr active Pending
- 2021-10-14 US US18/250,094 patent/US20240007549A1/en active Pending
Non-Patent Citations (3)
| Title |
|---|
| IAN RYTINA ERICSSON LTD UK: "Comments on Draft Recommendation Q.2150.3 Signalling Transport Converter on SCTP", ITU-T DRAFT ; STUDY PERIOD 2001-2004, INTERNATIONAL TELECOMMUNICATION UNION, GENEVA ; CH, vol. 13/11, 2 November 2002 (2002-11-02), pages 1 - 3, XP017496196 * |
| JESUP MOZILLA S LORETO ERICSSON M TUEXEN MUENSTER UNIV OF APPL SCIENCES R: "WebRTC Data Channel Establishment Protocol; draft-ietf-rtcweb-data-protocol-09.txt", WEBRTC DATA CHANNEL ESTABLISHMENT PROTOCOL; DRAFT-IETF-RTCWEB-DATA-PROTOCOL-09.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 4 January 2015 (2015-01-04), pages 1 - 13, XP015103811 * |
| LOTTOR SRI-NIC M: "TCP Port Service Multiplexer (TCPMUX); rfc1078.txt", TCP PORT SERVICE MULTIPLEXER (TCPMUX)?; RFC1078.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 1 November 1988 (1988-11-01), XP015006020 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116391351A (zh) | 2023-07-04 |
| WO2022084605A1 (fr) | 2022-04-28 |
| US20240007549A1 (en) | 2024-01-04 |
| EP4233302A1 (fr) | 2023-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2019002754A1 (fr) | Procédé de communication quic via des chemins multiples | |
| WO2017220892A1 (fr) | Procédé de communication udp via des chemins multiples entre deux terminaux | |
| FR2857187A1 (fr) | Procede de configuration automatique d'un routier d'acces, compatible avec le protocole dhcp, pour effectuer un traitement automatique specifique des flux ip d'un terminal client | |
| EP3643044B1 (fr) | Procédé d'activation de traitements appliqués à une session de données | |
| EP3732829B1 (fr) | Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur | |
| EP3603024B1 (fr) | Procédé de recommandation d'une pile de communication | |
| EP1994724A2 (fr) | Procede et systeme de caracterisation de noeuds de communication heterogenes | |
| EP2294798B1 (fr) | Procede de routage d'un paquet de donnees dans un reseau et dispositif associe | |
| FR3035291A1 (fr) | Procede d' emulation dune connexion a chemins multiples | |
| FR3096533A1 (fr) | Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en œuvre du procédé | |
| EP3560168B1 (fr) | Classification et aiguillage de messages de contrôle d'une infrastructure de communications | |
| WO2022084605A1 (fr) | Procede et dispositif d'aiguillage d'une donnee applicative | |
| EP4233298A1 (fr) | Procédé et dispositif de médiation d'un ensemble d'applications | |
| EP3430777B1 (fr) | Procédé et système de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs | |
| EP4162658A1 (fr) | Procede de discrimination d'un message entre un terminal et un serveur de donnees | |
| FR3094590A1 (fr) | Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé de gestion du trafic. | |
| EP1845693B1 (fr) | Dispositif de contrôle de l'établissement de sessions | |
| FR3111252A1 (fr) | Procédé de capture d’un paquet d’une session chiffrée | |
| WO2011029913A1 (fr) | Procede et systeme pour le controle de l'acheminement d'un flux de donnees d'une classe de service a travers un reseau maille et chiffre |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20220429 |
|
| ST | Notification of lapse |
Effective date: 20230606 |