BE1023707B1 - Multi-trajet tcp dans des reseaux d'acces hybrides - Google Patents

Abstract

Procédé pour échanger des données sur une connexion TCP (234) entre un nœud de client (100) et un nœud de réseautage (103). La connexion TCP comprend un sous-flux MPTCP primaire (122) entre un équipement de local d’abonné, un HCPE (101), et une passerelle d’accès hybride, une HAG (102). Par le HCPE, on convertit ( 410, 413) des premiers segments TCP (401, 406) en premiers segments MPTCP (402, 405) du sous-flux MPTCP primaire et réciproquement et des adresses de destination des premiers segments TCP sont utilisés en informations d’adresse de destination des premiers segments MPTCP, et des adresses de source du premier segment MPTCP sont utilisées en informations d’adresse de source des premiers segments TCP. Par la HAG, on convertit (411, 412) des seconds segments TCP (403, 404) en seconds segments MPTCP (402, 405) du sous-flux primaire et réciproquement

Description

MULTI-TRAJET TCP DANS DES RESEAUX D’ACCES HYBRIDES Domaine de l’invention [01] La présente invention porte de manière générale sur le domaine de la connectivité de réseau fournie à des clients par un réseau d’accès hybride. Dans un tel réseau d’accès hybride, un client peut accéder à un serveur dans un réseau externe tel que l’ I nternet par un équipement de local d’abonné hybride ou HCPE qui se connecte à une passerelle d’accès hybride ou HAG sur plus d’un réseau d’accès.

[02] Plus particulièrement, l’invention porte sur la fourniture de capacités de protocole de commande de transmission (TCP) multi-trajet entre un tel HCPE et une telle HAG à l’intérieur d’une connexion TCP mono-trajet entre le client et le serveur.

Arrière-plan de l’invention [03] Un équipement de local d’abonné connecte des clients ou des réseaux locaux à un réseau d’accès d’un fournisseur de services I nternet ou I SP. L’ I SP fournit ensuite un accès I nternet aux clients par connexion du réseau d’accès avec l’ I nternet par l’intermédiaire d’une passerelle sur le réseau central du fournisseur.

[04] Avec les bandes passantes plus élevées fournies par les dernières technologies sans fil telles que par exemple LTE, les équipements de local d’abonné hybrides ou HCPE ont été introduits fournissant un accès réseau sur à la fois les technologies câblées et sans fil. Afin d’amplifier davantage la bande passante pour l’utilisateur, des manières d’utiliser simultanément plusieurs réseaux d’accès ont été introduites. L’une d’elles est l’utilisation du protocole TCP multi-trajet (MPTCP) qui est spécifié par l’ I ETF dans la norme RFC 6824. Le protocole permet d’établir une connexion TCP entre un client et un nœud de serveur. La connexion comprend ensuite plusieurs sous-flux, des sous-flux MPTCP, sur lesquels les données sont transférées.

[05] Cependant, un inconvénient du protocole est qu’à la fois les deux points d’extrémité, c’est-à-dire le client et le serveur, doivent supporter MPTCP afin d’en faire une pleine utilisation. Par conséquent, le protocole ne supporte pas l’établissement de différents sous-flux entre des nœuds intermédiaires d’une connexion TCP, tel qu’entre le HCPE et la passerelle sur les différents réseaux d’accès.

[06] Dans EP2882148, une solution est fournie pour s’attaquer à l’inconvénient ci-dessus et, ainsi, pour fournir des capacités multi-trajet entre un HCPE et une passerelle. A la fois le HCPE et la passerelle servent de mandataire intermédiaire entre un client se connectant à un serveur. Lorsque le client se connecte au serveur, le HCPE convertira le segment de synchronisation TCP du client en un segment de synchronisation MPTCP et l’adressera à la passerelle avec l’adresse du serveur incluse dans un champ facultatif du segment. La passerelle à son tour convertit le segment MPTCP en retour vers un segment TCP et l’adresse au serveur. De cette manière, un dialogue à trois est réalisé et une connexion TCP entre le client et le serveur est établie.

[07] Un désavantage de la solution ci-dessus est que le serveur voit la passerelle en tant que source de la connexion et non le client ou le HCPE. L’utilisation de la HAG et du HCPE n’est ainsi pas transparente pour le serveur. Un autre inconvénient est que le HCPE doit fournir l’adresse du serveur en tant que champ facultatif. Ceci augmente la dimension des segments de synchronisation critiques de temps et n’est en outre pas optimal parce que les champs facultatifs sont limités en taille. Un autre inconvénient est que le trafic à l’intérieur du réseau d’accès et le réseau central de l’ I SP est adressé à la passerelle et non au serveur. Ceci est problématique pour des raisons légales en raison du fait que les I SP sont obligés de garder une trace de l’activité de réseau et ainsi des serveurs qu’un abonné et ainsi un client essaie d’atteindre.

Afin de faire ceci, I’ I SP aura à lier le trafic intercepté à des informations provenant de la passerelle. Ceci est complexe et donc coûteux.

[08] C’ est un objectif de la présente invention de surmonter les inconvénients ci-dessus et de fournir une manière de fournir une connexion TCP d’extrémité à extrémité transparente entre un client et un serveur tout en utilisant des capacités multi-trajet entre le HCPE et une passerelle. Résumé de l’invention [09] Cet objectif est atteint, selon un premier aspect, par un procédé pour échanger des données sur une connexion TCP entre un nœud de client et un nœud de réseautage. La connexion TCP comprend un sous-flux MPTCP primaire sur un premier réseau d’accès entre un équipement de local d’abonné hybride, un HCPE, servant de premier nœud mandataire et une passerelle d’accès hybride, une HAG, servant de second nœud mandataire. Le procédé comprend les étapes suivantes : - la conversion, par le HCPE, de premiers segments TCP en premiers segments MPTCP du sous-flux MPTCP primaire et réciproquement ; et - l’utilisation, par le HCPE, d’informations d’adresse de destination des premiers segments TCP en tant qu’informations d’adresse de destination des premiers segments MPTCP ; et - l’utilisation, par le HCPE, d’informations d’adresse de source des premiers segments MPTCP en tant qu’informations d’adresse de source des premiers segments TCP ; et - la conversion, par la HAG, de seconds segments TCP en seconds segments MPTCP du sous-flux primaire et réciproquement tout en préservant des informations d’adresse de source et de destination.

[10] Le client est ainsi connecté au nœud de réseautage, par exemple un serveur, par l’intermédiaire du HCPE et de la HAG. Le HCPE fournit l’accès client à plus d’un réseau d’accès, par exemple une ligne d’abonné numérique (DSL) et un réseau LTE. La HAG à son tour sert de passerelle entre les réseaux d’accès et un réseau externe tel que I’ I nternet dans lequel se trouve le nœud de réseautage. En d’autres termes, la HAG se situe entre le réseau externe et le HCPE. La connexion TCP comprend une première partie monotrajet entre le client et le HCPE, puis une partie multi-trajet entre le HCPE et la HAG puis encore une partie mono-trajet entre la HAG et le serveur. La partie multi-trajet comprend le sous-flux MPTCP primaire, c’est-à-dire, le sous-flux qui a été configuré en premier lors de l’établissement de la connexion MPTCP. La partie multi-trajet peut comprendre un ou plusieurs sous-flux supplémentaires ou auxiliaires entre la HCPE et la HAG établis sur d’autres réseaux d’accès. La connexion TCP peut être initiée à partir du nœud client ou à partir du nœud de réseautage.

[11] Des segments TCP envoyés du client au nœud de réseautage sont interceptés par le HCPE qui les convertit en segments MPTCP. Si le HCPE décide d’envoyer un segment sur le sous-flux primaire, il ne modifie pas l’adresse de destination dans le segment. En fonction du point de savoir si le HCPE applique une traduction d’adresse de réseau (NAT) ou pas, il peut modifier les informations d’adresse de source dans le segment. Par la suite, la HAG va intercepter le segment étant donné que tout le trafic vers le HCPE passera par la HAG. La HAG convertit ensuite le segment MPTCP en retour en un segment TCP sans modifier les informations d’adresse de source ou de destination. De cette manière, la HAG et la partie MPTCP sont transparentes pour le nœud de réseautage et le nœud de réseautage croit qu’il reçoit des segments TCP mono-trajet en provenance du client ou du HCPE. Dans l’autre sens, des segments envoyés par le nœud de réseautage au client sont interceptés par la HAG et convertis en segments MPTCP. A nouveau, si la HAG décide d’envoyer les segments sur le sous-flux MPTCP primaire, elle ne modifie pas l’adresse de source ou de destination des segments. Au niveau du HCPE, le segment est converti en un segment TCP tout en préservant l’adresse de source et transmis au client. En fonction de la fonction NAT au niveau du HCPE, l’adresse de destination peut être traduite en celle du client.

[12] En d’ autres termes, à la fois le client et le nœud de réseautage ressentent une connexion TCP mono-trajet tandis qu’un multi-trajet est supporté pour la connexion entre le HCPE et la HAG. C’est ainsi un avantage que l’utilisation du multi-trajet soit transparente à la fois pour le client et le nœud de réseautage. Ceci implique également que la journalisation de réseau à des fins légales puisse être réalisée à n’importe quel endroit avant ou après la HAG. Une transparence est également avantageuse pour une ingénierie de trafic pour des sources et des destinations I P, pour un marquage de classe de service (CoS), pour un rapport de trafic par, par exemple, le protocole d’export d’informations de flux de protocole I nternet ( I PF IX) ou le protocole de flux échantillonné (sflow) et pour des applications de sécurité telles que, par exemple, des étiquettes de système de détection d’intrusion ( I DS) et de sécurité de fournisseur I nternet ( I PS). En outre, c’est un avantage que l’adresse du serveur puisse être fournie dans le champ de destination des segments MPTCP et n’ait pas besoin d’être fournie dans un champ facultatif, améliorant ainsi une compatibilité de protocoles et réduisant la taille des segments.

[13] Etant donné que le HCPE et la HAG conservent un état de connexion MPTCP, la connexion TCP peut en outre comprendre un sous-flux MPTCP auxiliaire sur un second réseau d’accès entre le HCPE et la HAG. Le procédé comprend alors en outre : - au niveau du HCPE, la conversion de troisièmes segments TCP en troisièmes segments MPTCP du sous-flux MPTCP auxiliaire et réciproquement ; et - au niveau de la HAG, la conversion de quatrièmes segments TCP en quatrièmes segments MPTCP du sous-flux auxiliaire et réciproquement.

[14] Comme prévu par le protocole MPTCP, le HCPE ou la HAG peut ensuite décider sur quel sous-flux envoyer le segment MPTCP sur la base d’une performance de réseau courante ou de politiques de réseau. De manière similaire au sous-flux primaire, à la fois le HCPE et la HAG réalisent une conversion entre les états TCP et MPTCP et réciproquement.

[15] Selon un mode de réalisation, la conversion comprend alors en outre : - par le HCPE, l’utilisation d’informations d’adresse de destination de la HAG pour les troisièmes segments MPTCP ; et - par la HAG, l’utilisation d’informations d’adresse de destination du nœud de réseautage pour les quatrièmes segments envoyés au nœud de réseautage.

[16] Afin de router les segments différemment pour le sous-flux auxiliaire, le HCPE envoie maintenant un segment MPTCP avec les données du segment TCP à l’adresse de réseau de la HAG dans le second réseau d’accès. De cette manière, les segments sont routés sur le sous-flux auxiliaire vers la HAG. Au niveau de la HAG, l’adresse de destination est à nouveau remplacée par celle du nœud de réseautage.

[17] En raison du fait que tous les segments du sous-flux auxiliaire ont besoin d’être adressés à la HAG directement, l’opérateur de réseau peut utiliser des politiques qui empêchent le client ou le HCPE d’utiliser le second réseau d’accès pour accéder au dispositif de réseautage directement. De cette manière, l’utilisation du second réseau d’accès peut être contrôlée d’une manière facile et simple.

[18] Selon un mode de réalisation, le procédé comprend en outre, afin d’établir le sous-flux MPTCP auxiliaire : - l’envoi, par la HAG pour établir le sous-flux MPTCP auxiliaire, d’un segment comprenant une adresse de la HAG dans le second réseau d’accès sur le sous-flux MPTCP primaire.

[19] La HAG annonce ainsi son adresse pour établir le sous-flux MPTCP auxiliaire vers le HCPE. Ceci a l’avantage que la HAG peut, à tout moment, déterminer lorsque le HCPE, et ainsi le client, peut utiliser le sous-flux MPTCP auxiliaire.

[20] Le HCPE peut initier le sous-flux auxiliaire par envoi d’un segment comprenant une requête pour établir le second sous-flux MPTCP vers la HAG. En variante, la HAG peut initier le sous-flux auxiliaire par envoi d’un segment comprenant la requête pour établir le second sous-flux MPTCP vers le HCPE. Dans ce cas, il n’est pas nécessaire d’envoyer l’adresse de la HAG dans le second réseau d’accès sur le sous-flux MPTCP primaire si la HAG connaît l’adresse alternative du HCPE.

[21] En variante, à la fois les sous-flux MPTCP primaire et auxiliaire peuvent être établis par : - par la HAG, la réception d’un segment de synchronisation provenant du HCPE indicatif d’une requête pour établir les sous-flux MPTCP primaire et auxiliaire ; et - par la suite, par le HCPE, la réception d’un segment de synchronisation et d’acquittement en provenance de la HAG ; et - l’établissement, par le HCPE, des sous-flux MPTCP primaire et auxiliaire ; et - la réception, par la HAG, d’un segment d’acquittement en provenance du HCPE ; et - par la suite, par la HAG, l’établissement des sous-flux MPTCP primaire et auxiliaire.

[22] Les sous-flux MPTCP primaire et auxiliaire sont ainsi établis du côté HCPE après l’échange de deux messages, c’est-à-dire, le segment de synchronisation initial puis la réception de l’acquittement correspondant en provenance de la HAG. En d’autres termes, le HCPE établit les sous-flux TCP primaire et auxiliaire sur la base du segment de synchronisation et de l’acquittement reçu. I l n’y a ainsi pas d’autres besoins de messages de dialogue additionnels.

[23] Du côté HAG, les sous-flux sont établis après l’échange des trois messages, c’est-à-dire, le segment de synchronisation initial, l’acquittement avec le segment de synchronisation provenant de la HAG puis l’acquittement provenant du HCPE.

[24] C’ est ainsi un avantage que les deux sous-flux puissent être établis par un dialogue à trois unique. Le nombre de segments échangés et la durée d’établissement sont ainsi indépendants du nombre de sous-flux auxiliaires. En outre, la même quantité de segments TCP et de segments MPTCP sont échangés. A la fois le HCPE et la HAG réalisent ainsi une conversion un à un des segments durant l’établissement de la connexion TCP.

[25] En outre, les messages échangés peuvent être rendus rétro compatibles avec des segments utilisés dans le protocole MPTCP actuel, c’est-à-dire, respectivement le segment SYN avec l’option MP_CAPABLE, le segment SYN+ACK avec l’option MP_CAPABLE et le segment ACK contenant l’option MP_CAPABLE. Si le message peut être le même, l’interprétation qui lui est donnée par le client et le serveur est différente et, par conséquent, les sous-flux sont établis uniquement par un dialogue à trois unique.

[26] Selon un autre mode de réalisation, la HAG comprend une pluralité de serveurs de passerelle chacun agissant en tant que passerelle entre le premier réseau d’accès et le nœud de réseautage ; et le procédé comprend en outre : - par la HAG, l’équilibrage de charge du sous-flux MPTCP primaire sur l’un des serveurs de passerelle.

[27] Etant donné que la HAG est un étranglement vers le réseau externe, les sous-flux MPTCP primaires sont équilibrés en charge sur les différents serveurs, c’est-à-dire, tous les segments d’une certaine connexion TCP sont affectés au même serveur de passerelle. Etant donné que le sous-flux auxiliaire est affecté à une adresse séparée, l’équilibrage de charge du sous-flux auxiliaire peut ensuite être réalisé par fourniture du HCPE avec l’adresse réseau du serveur de passerelle auquel le sous-flux primaire est affecté.

[28] Selon un second aspect, l’invention porte sur un procédé pour échanger des données sur une connexion TCP entre un nœud de client et un nœud de réseautage ; la connexion TCP comprenant un sous-flux MPTCP primaire sur un premier réseau d’accès entre un équipement de local d’abonné, un HCPE, servant de premier nœud mandataire et une passerelle d’accès hybride, une HAG, servant de second nœud mandataire ; le procédé comprenant : - par le HCPE : o la conversion de premiers segments TCP en premiers segments MPTCP du sous-flux MPTCP primaire et réciproquement ; et o l’utilisation d’informations d’adresse de destination des premiers segments TCP en tant qu’informations d’adresse de destination des premiers segments MPTCP ; et o l’utilisation d’informations d’adresse de source du premier segment MPTCP en tant qu’informations d’adresse de source des premiers segments TCP.

[29] Selon un troisième aspect, l’invention porte sur un procédé pour échanger des données sur une connexion TCP entre un nœud de client et un nœud de réseautage ; la connexion TCP comprenant un sous-flux MPTCP primaire sur un premier réseau d’accès entre un équipement de local d’abonné, un HCPE, servant de premier nœud mandataire et une passerelle d’accès hybride, une HAG, servant de second nœud mandataire ; le procédé comprenant : - par la HAG : o la conversion de seconds segments TCP en seconds segments MPTCP du sous-flux primaire et réciproquement tout en préservant les informations d’adresse de source et de destination.

[30] Selon un quatrième aspect, l’invention porte sur un équipement de local d’abonné hybride, HCPE, configuré pour réaliser les étapes réalisées par le HCPE selon les premier et second aspects.

[31] Selon un cinquième aspect, l’invention porte sur une passerelle d’accès hybride configurée pour réaliser les étapes réalisées par la HAG selon le troisième aspect.

[32] Selon un sixième aspect, l’invention porte sur un système comprenant le HCPE selon le second aspect et la HAG selon le troisième aspect.

Brève description des dessins [33] La Figure 1 illustre un équipement de local d’abonné hybride, une passerelle d’accès hybride et un serveur utilisés pour établir une connexion TCP selon un mode de réalisation de l’invention ; et [34] La Figure 2 illustre des segments échangés afin d’établir une connexion TCP multi-trajet selon un mode de réalisation de l’invention ; et [35] La Figure 3 illustre des segments échangés pour établir un sous-flux auxiliaire selon un mode de réalisation de l’invention ; et [36] La Figure 4 illustre des segments échangés sur à la fois le sous-flux primaire et le sous-flux auxiliaire d’une connexion TCP multi-trajet selon un mode de réalisation de l’invention ; et [37] La Figure 5 illustre une passerelle d’accès hybride selon un mode de réalisation de l’invention.

[38] La Figure 6 illustre un système informatique approprié en tant que mode de réalisation supplémentaire d’un équipement de local d’abonné hybride et/ou d’une passerelle d’accès hybride selon un mode de réalisation de l’invention.

Description détaillée des modes de réalisation [39] La Figure 1 illustre un système pour échanger des données sur une connexion TCP entre un client 100 et un nœud de réseautage 103 selon un mode de réalisation de l’invention. La connexion TCP peut être initiée par le client 100 auquel cas le nœud 103 agit en tant que serveur ou réciproquement. Pour le reste de cette description, le nœud de réseautage 103 sera désigné en tant que le serveur. Le système comprend en outre un équipement de local d’abonné hybride 101, désigné en outre en tant que HCPE. Le HCPE 101 sert de passerelle pour le client 100 et tout autre dispositif de réseautage à l’intérieur du réseau local 113. Le HCPE 101 fournit au client un accès aux réseaux d’accès 110, 111 d’un fournisseur de services I nternet ( I SP). Le système comprend en outre une passerelle d’accès hybride 102 permettant une communication entre les réseaux d’accès 110, 111 et un réseau externe 112 tel que par exemple l’ I nternet. Le serveur 103 réside dans ce réseau externe 112. A la fois le HCPE 101 et la HAG 102 sont dénotés en tant que « hybride » en raison du fait qu’ils sont capables de communiquer entre eux sur plus d’un réseau d’accès. Un réseau d’accès peut être un réseau d’accès câblé tel que par exemple un réseau d’accès ADSL, ADSL2, VDSL, VDSL2, à fibre ou câblé. Dans un tel cas, le HCPE aura une interface de communication câblée. Un réseau d’accès peut également être un réseau d’accès sans fil tel que par exemple un réseau d’accès LTE, Wi-Fi, satellite ou tout autre réseau d’accès sans fil. Dans un tel cas, le HCPR comprendra également une interface sans fil.

[40] Comme cela sera décrit dans les modes de réalisation ci-après, le client 100 peut établir une connexion TCP avec le serveur 103, c’est-à-dire, une connexion dans laquelle à la fois le client 100 et le serveur 103 conservent des informations d’état TCP afin de maintenir une connexion fiable. Lors de l’envoi de données sur la connexion TCP au serveur, le client envoie les segments TCP au HCPE 101. Le HCPE conserve à la fois un état TCP et un état de connexion TCP multi-trajet, MPTCP. Le protocole MPTCP est une extension du protocole TCP. Une version du protocole est publiée par l’ I ETF dans la norme RFC 6824. Le HCPE convertit ensuite les segments TCP en segments MPTCP et les envoie sur l’un des réseaux d’accès 110, 111 vers la HAG 102. Afin de faire ceci, le HCPE conserve un sous-flux MPTCP primaire 122 sur le premier réseau d’accès 110 avec la HAG 102 et un sous-flux MPTCP auxiliaire 124 sur le second réseau d’accès 111 avec la HAG 102. De cette manière, la connexion TCP peut bénéficier de la bande passante agrégée des réseaux d’accès 110 et 111. Egalement, la HAG 102 conserve à la fois un état de connexion TCP et un état de connexion MPTCP. Lorsque la HAG reçoit les segments MPTCP en provenance du HCPE, elle les convertit en retour en segments TCP et les transfère au serveur 103. Les segments TCP provenant du serveur sont envoyés de manière similaire au client 100.

[41] Pour l’adressage, le schéma de numérotation de ports TCP peut être combiné avec le schéma d’adressage de protocole I nternet, I P, qui est communément désigné en tant que TCP/ I P. Le protocole I P peut par exemple être I Pv4 ou le plus récent I Pv6.

[42] La Figure 2 illustre l’établissement de la connexion TCP 234 entre le client 100 et le serveur 103 selon un mode de réalisation de l’invention. Dans l’exemple, le client initie la connexion, mais l’établissement peut également être réalisé par le nœud 103 auquel cas le client 100 agit en tant que nœud serveur. L’établissement est réalisé par l’échange de segments TCP 201 à 209. Dans chaque segment des Figures 2 à 4, le type de segment est souligné suivi par l’adresse de source dénotée par « SA » et l’adresse de destination dénotée par « DA ». Pour les adresses dans les segments, « CL » indique l’adresse du client 100, « SRV » indique l’adresse du serveur 103, « HCPE » indique une adresse du HCPE 101 et « HAG » indique une adresse de la HAG 102.

[43] Dans une première étape, le client transmet un segment de synchronisation TCP 201 ou en plus court un segment SYN sur son interface de réseautage 220 au serveur 103 par ajout de l’adresse réseau affectée à l’interface de réseautage 227 du serveur dans le champ d’adresse de destination du segment de synchronisation 201. Comme le HCPE sert de passerelle pour le client 100, le segment sera reçu au niveau de l’interface de réseautage 221 du HCPE 101.

[44] Le HCPE comprend deux interfaces de réseau externe 222 et 223 connectant le HCPE respectivement aux premier et second réseaux d’accès 110 et 111. Ensuite, dans l’étape 210, le HCPE 101 convertit le segment SYN reçu 201 en un segment SYN 202 qui indique des capacités multi-trajet, c’est-à-dire, un segment SYN contenant l’option MP_CAPABLE. En fonction du point de savoir si le HCPE met en œuvre une traduction d’adresse de réseau, NAT, le HCPE peut remplacer l’adresse de source du segment 201 par l’adresse du HCPE, c’est-à-dire, par l’adresse affectée à l’interface 222. Une NAT peut par exemple être réalisée lors de l’utilisation de l’ IPv4 tandis qu’elle n’est normalement pas utile lors de l’utilisation de l’ I Pv6. Dans les deux cas, le HCPE 101 ne modifie pas l’adresse de destination durant l’étape de conversion 210.

[45] Dans une nouvelle étape, le HCPE 101 transmet ensuite le segment 202 sur sa première interface de réseautage 222 puis sur le sous-flux primaire 122 au serveur. Comme la HAG agit en tant que passerelle pour le premier réseau d’accès vers le réseau dans lequel se trouve le serveur, le segment 202 sera routé vers l’interface de réseau 224 de la HAG et ainsi reçu par la HAG 102. Ensuite, dans l’étape 211, la HAG convertit le segment MPTCP 202 en retour en un segment TCP 203 par retrait de l’option MP_CAPABLE. Durant la conversion, la HAG ne modifie pas l’adresse de source ou de destination du segment. La HAG transfère ensuite le segment converti.

[46] Lorsque le serveur 103 reçoit le segment SYN, tout se passe comme si le client 100 ou le HCPE 101 tentait d’établir une connexion TCP mono-trajet avec le serveur. S’il n’y a pas de NAT appliquée, à la fois le HCPE 101 et la HAG 102 restent complètement transparents pour le serveur. En retour, le serveur 103 répond au client 100 ou au HCPE 101 par un segment de synchronisation et d’acquittement 204, un SYN+ACK.

[47] Ce segment 204 est à nouveau intercepté par la HAG 102 servant de passerelle vers le HCPE 101 et le client 100. Dans l’étape 212, la HAG réalise une conversion similaire du segment 204 comme dans l’étape 211, mais ajoute maintenant l’option de capacité multi-trajet, communément désignée sous MP_CAPABLE. A nouveau, à la fois les adresses de source et de destination restent inchangées.

[48] Comme le HCPE sert de passerelle vers le client pour des segments provenant de la HAG, le segment converti 205 sera reçu au niveau du HCPE 101. Dans l’étape 213, le HCPE retire l’option MP_CAPABLE et convertit ainsi le segment MPTCP 205 en un segment TCP 206. En fonction du point de savoir si une NAT est réalisée, l’adresse de source peut être changée en celle du client 100.

[49] Comme pour les segments SYN 201-203, le client acquitte maintenant la connexion TCP par le segment 207. Ce segment est à nouveau converti 214 par le HCPE en un segment ACK+MP_CAPABLE 208 et converti 215 en retour en un segment ACK régulier 209 par la HAG 102. Lorsque le segment ACK 209 est reçu par le serveur 103, la connexion TCP 234 est considérée établie au niveau à la fois du client 100 et du serveur 103 par le dialogue à trois. Entre le HCPE et la HAG, la connexion sera traitée comme le sous-flux primaire 122 d’une connexion MPTCP.

[50] Conjointement à l’établissement de la connexion TCP 234 ou à tout instant par la suite, un second sous-flux peut être établi entre le HCPE 101 et la HAG 102.

[51] La Figure 3 illustre les étapes réalisées par le HCPE et la HAG pour établir le second sous-flux 124 selon un mode de réalisation de l’invention. Les étapes réalisées sont conformes au protocole MPTCP pour établir un sous-flux auxiliaire. Après l’établissement du premier sous-flux 122, la HA envoie un segment MPTCP 301 contenant une option ADD_ADDRESS au CPE dans lequel l’adresse de réseau d’interface 225 de la HAG sur le second réseau d’accès 111 est annoncée. Par la suite, le HCPE et la HAG échangent d’autres segments tels que le segment SYN+MP_JO I N 302 et le segment SYN+ACK+MP_JO I N 303 afin d’établir le second sous-flux MPTCP 124. Pour l’échange de segments MPTCP, le HCPE utilisera la seconde interface réseau 223 et ainsi le second réseau d’accès.

[52] Afin d’échanger les données sur les deux sous-flux 122, 124, à la fois le HCPE 101 et la HAG 102 gardent une trace de l’état MPTCP, c’est-à-dire, gèrent les numéros de séquence de données, DSN, MPTCP, comme défini par le protocole MPTCP.

[53] Selon un autre mode de réalisation, le second sous-flux 124 peut également être établi implicitement durant l’établissement du premier sous-flux. De cette manière, un trafic de réseau supplémentaire et un retard provoqué par l’échange de segments 301-303 peuvent être évités. Cet établissement implicite est possible en raison du fait que le HCPE 101 est connu de la HAG 102 étant donné qu’ils font tous les deux partie du même réseau d’abonnés, c’est-à-dire le même ISP. Cet autre mode de réalisation sera maintenant décrit en référence à la Figure 2.

[54] Lorsque la HAG a reçu le premier segment SYN+MP_CAPABLE 202, la HAG obtiendra aussi les informations d’adressage de la seconde interface de réseautage du HCPE 223. La façon dont ces informations d’adresse peuvent être obtenues est expliquée davantage ci-après.

[55] La réception du segment 202 est interprétée par la HAG 102 comme une requête pour configurer à la fois le premier sous-flux MPTCP 122 et le sous-flux MPTCP auxiliaire 124. Ce n’est ainsi pas uniquement une indication que le HCPE 101 supporte un TCP multi-trajet. Cette requête peut être directement incluse dans le premier segment 202. En variante, la requête peut également être faite indirectement, par exemple, par une configuration prédéfinie dans le serveur selon laquelle des segments 202 devraient toujours être considérés comme une telle requête. De cette manière, aucune autre information supplémentaire ne doit être présente dans le segment 202. Le HCPE 101 peut également modifier ou configurer une telle configuration par l’intermédiaire d’une connexion ou d’un canal hors bande entre le HCPE 101 et la HAG 102.

[56] Lorsque la requête est incluse dans un segment 202, ceci peut être fait de plusieurs manières. Une manière est de définir une nouvelle option TCP qui comprend une telle requête. Une autre possibilité est de placer la requête à l’intérieur de la charge utile du segment SYN 202. Encore une autre possibilité est de placer la requête à l’intérieur d’une option dans le paquet de réseau, c’est-à-dire, en tant qu’option I P. Ceci est particulièrement avantageux dans l’ IPv6 où il n’y a aucune limite stricte sur la longueur d’une telle option et ainsi sur la longueur de la requête.

[57] Lorsque le HCPE reçoit le segment SYN+ACK+MP_CAPABLE 205, il l’interprète comme une confirmation que la HAG 102 est prête pour une communication sur les deux sous-flux 122 et 124.

[58] Par la suite, le HCPE 101 confirme l’établissement des premier et second sous-flux avec le segment ACK+MP_CAPABLE 208 vers la HAG. A réception, la HAG 102 a la confirmation que le HCPE 101 a établi les deux sous-flux 122, 124 et établit également le premier sous-flux 122 et le sous-flux auxiliaire 124.

[59] L’ obtention des informations d’adresse du HCPE 101 pour le second sous-flux par la HAG 102 peut être réalisée de plusieurs manières comme décrit ci-après.

[60] Dans une première manière de réaliser les informations d’adressage, celles-ci sont comprises dans le segment SYN+MP_CAPABLE 202 et la HAG 102 extrait ensuite ces informations du segment 202. Selon un premier exemple, une nouvelle option TCP est définie qui comprend ces informations d’adressage. Selon un second exemple, les informations d’adressage sont incorporées en tant que données de charge utile dans le segment SYN 202. Selon un troisième exemple, les informations d’adressage sont incorporées en tant qu’option dans le paquet de réseau, c’est-à-dire, en tant qu’une option I P. Ceci est particulièrement avantageux dans l’ I Pv6 où il n’y a aucune limite stricte sur la longueur d’une telle option et ainsi sur la longueur des informations d’adressage. L’incorporation des informations d’adressage peut en outre être combinée avec l’incorporation de la requête comme indiqué ci-dessus. De préférence, les informations d’adressage sont fournies de telle sorte qu’une rétro compatibilité avec le protocole MPTCP est garantie.

[61] Une seconde manière d’obtenir les informations d’adressage est par l’utilisation d’un mécanisme ou d’un canal de communication hors bande, c’est-à-dire, par une communication entre le HCPE 101 et la HAG 102 à l’extérieur des sous-flux MPTCP. Par exemple, une connexion séparée peut exister entre le HCPE 101 et la HAG 102 pour échanger de nouvelles informations concernant les sous-flux. Une telle connexion peut être utilisée par des applications de gestion s’exécutant à la fois sur le HCPE 101 et la HAG 102 qui gèrent l’établissement de sous-flux multi-trajet.

[62] Selon une troisième manière, les informations d’adressage sont déduites indépendamment par la HAG 102 par une relation logique prédéfinie, c’est-à-dire, selon une règle prédéfinie indiquant la façon dont les informations d’adressage peuvent être déduites. Certains exemples de telles règles sont : - il y a une relation mathématique entre l’adresse de réseau et/ou un port du HCPE 101 pour les deux sous-flux. Par exemple, l’adresse de réseau et/ou le port pour le sous-flux auxiliaire peuvent être obtenus par incrémentation de l’adresse de réseau et/ou un port utilisé pour le premier sous-flux. - Les informations d’adressage sont identiques à celles utilisées pour des sous-flux précédents établis par le HCPE. - La HAG a accès à une base de données qui liste toutes les adresses de tous les HCPE.

[63] La HAG 102 et le HCPE 101 peuvent également supporter un établissement de connexion provenant du réseau extérieur, c’est-à-dire, lorsque le serveur 103 initie l’établissement d’une connexion TCP 234 avec le client 100.

[64] Lorsque la connexion TCP 234 est établie selon l’un des modes de réalisation ci-dessus, des segments de données peuvent être échangés entre le client 100 et le serveur 103. La Figure 4 illustre la façon dont des segments 401 à 408 sont convertis par le HCPE 101 et la HAG 102 afin d’utiliser les deux sous-flux 122, 124 tout en préservant une transparence à la fois pour le client 100 et le serveur 103.

[65] Lorsqu’un segment TCP 401 est envoyé du client 100 au serveur 103 le long du sous-flux primaire 122, le segment 401 sera intercepté au niveau du HCPE, et transmis en tant que segment MPTCP 402 sur le premier sous-flux ou sous-flux primaire au serveur 103. Durant cette étape de conversion 410, les informations d’adresse de destination sont préservées. Les informations d’adresse de source peuvent être changées en celles de l’interface 222 lorsqu’une NAT est appliquée par le HCPE. Le segment MPTCP 402 sera à son tour intercepté par la HAG et converti en retour en segment de données TCP 403. Durant l’étape de conversion 411, les informations d’adresse de source et de destination sont préservées par la HAG. Enfin, le segment 403 arrivera au niveau du serveur 103 en tant que segment TCP mono-trajet provenant du client 100 ou du HCPE 101.

[66] La conversion dans la direction opposée du serveur 103 au client 100 sur le premier sous-flux MPTCP 122 est réalisée de manière similaire. Un segment TCP 404 provenant du serveur 103 sera intercepté par la HAG 102 et converti en un segment MPTCP 405. Durant l’étape de conversion 412, les informations d’adresse de source et de destination sont préservées. Le segment 405 sera à son tour reçu ou intercepté par le HCPE. Au niveau du HCPE, le segment 405 est converti en segment TCP 406. Durant cette étape de conversion 413, les informations d’adresse de source sont préservées. Les informations d’adresse de destination peuvent être changées en fonction du point de savoir si une NAT est appliquée par le HCPE. Le client 100 reçoit ensuite le segment TCP mono-trajet 406 de manière transparente, c’est-à-dire, comme s’il provenait du serveur 103.

[67] Lorsque le segment TCP 401 est envoyé du client 100 au serveur 103 le long du sous-flux auxiliaire 124, le segment 401 sera à nouveau intercepté au niveau du HCPE 101 et transmis en tant que segment MPTCP 407 sur le second sous-flux ou sous-flux auxiliaire vers le serveur 103. Durant cette étape de conversion 410, les informations d’adresse de destination sont remplacées par les informations d’adresse de la HAG 102, c’est-à-dire, l’adresse affectée à l’interface de réseau 225 de la HAG. Durant cette même étape 410, les informations d’adresse de source sont changées en celles de l’interface 223. Le segment 407 est ensuite transféré sur le second réseau d’accès 111 à la HAG. Comme le segment MPTCP 407 est adressé à la HAG, le segment 407 sera routé vers l’interface de réseau de HAG 225. Comme le sous-flux auxiliaire 124 est lié au sous-flux primaire 122, la HAG identifiera le segment 407 comme appartenant à la connexion TCP 234. Par conséquent, la HAG convertit le segment, durant l’étape de conversion 411, en un segment TCP 403 et remplace l’adresse de destination par celle du serveur. Si une NAT n’est pas appliquée au niveau du HCPE, l’adresse de source est remplacée par celle du client 100, autrement par l’adresse affectée à l’interface 222 du HCPE, c’est-à-dire, l’interface utilisée pour le sous-flux primaire 122.

[68] La conversion dans la direction opposée du serveur 103 au client 100 sur le sous-flux MPTCP auxiliaire 124 est réalisée de manière similaire. Un segment TCP 404 provenant du serveur 103 sera intercepté par la HAG 102 et converti en un segment MPTCP 408, c’est-à-dire, un segment MPTCP pour le sous-flux MPTCP auxiliaire 124. Durant l’étape de conversion 412, l’adresse de source du serveur est remplacée par l’adresse de source de la HAG, c’est-à-dire, l’adresse affectée à l’interface de réseau 224 de la HAG. L’adresse de destination est remplacée par celle du HCPE 101, c’est-à-dire, l’adresse de réseau de l’interface de réseau de HCPE 223 sur le second réseau d’accès 111.

[69] Le segment sera ensuite routé le long du second réseau d’accès 111 vers le HCPE 101. Au niveau du HCPE 101, le segment 408 au niveau de l’interface 223. Comme le HCPE garde un état MPTCP, il déduit que le segment 408 appartient à la connexion TCP 234. Par conséquent, par la suite, durant l’étape de conversion 413, le segment 408 est converti en segment 406. Dans l’étape 413, l’adresse de source de la HAG est remplacée par l’adresse du serveur et l’adresse de destination est remplacée par l’adresse du client. Enfin, le segment 406 arrive au niveau du client 100.

[70] La Figure 5 illustre la disposition de la HAG selon un mode de réalisation de l’invention. La HAG 102 comprend un serveur 501 comprenant une logique de serveur mandataire 505 pour réaliser les étapes de conversion telles qu’expliquées par rapport aux modes de réalisation précédents. Les segments reçus sur le sous-flux MPTCP primaire 122 et le sous-flux MPTCP auxiliaire 124 sont convertis par la logique de serveur mandataire 505 en segments TCP et réciproquement.

[71] Egalement d’autres paquets de données 510 peuvent être reçus au niveau de l’interface de réseautage 224 tels que par exemple des paquets selon les autres protocoles de réseautage comprenant UDP ou I CMP. Ces paquets ne seront pas convertis par la logique de serveur mandataire, mais sont directement transférés au réseau extérieur sur l’interface de réseautage 226. De cette manière, la fonctionnalité MPTCP dans le HCPE et la HAG 102 reste également complètement transparente pour d’autres protocoles.

[72] La HAG 102 peut comprendre en outre une pluralité de serveurs HAG 501 à 503 afin d’équilibrer la charge du trafic de données. A cet égard, la HAG 102 comprend également des dispositifs d’équilibrage de charge 520 et 521. Le dispositif d’équilibrage de charge 520 équilibre les paquets provenant de différents HCPE sur l’un des serveurs HAG 501-503. Le dispositif d’équilibrage de charge 521 équilibre les paquets provenant du réseau extérieur sur l’un des serveurs HAG 501-503. Plusieurs politiques peuvent être mises en œuvre dans le dispositif d’équilibrage de charge telles que par exemple : - équilibrage de charge par flux MPTCP, c’est-à-dire, par connexion TCP nouvellement établie entre un client et un serveur. - Equilibrage de charge par HCPE, c’est-à-dire, chaque HCPE se voit affecter un unique serveur HAG pour toutes ses connexions. Ceci peut être réalisé par vérification de l’adresse I P de source des paquets reçus sur l’interface primaire 224. - Equilibrage de charge par préfixe source. De cette manière, une grappe de HCPE se voit affecter un unique serveur HAG.

Les mécanismes d’équilibrage de charge ci-dessus assurent que les dispositifs d’équilibrage de charge à la fois côté HCPE et côté réseau externe 520 et 521 routent de manière cohérente des paquets d’un flux donné vers le même mandataire. Ceci permet également d’assurer que la décision d’équilibrage de charge n’est pas changée pour un flux en cours, c’est-à-dire, pour une connexion TCP en cours entre un client et un serveur.

[73] Durant le fonctionnement, c’est-à-dire, lorsque le TCP multi-trajet fonctionne sur à la fois les sous-flux primaire et auxiliaire, une situation peut survenir selon laquelle l’adresse de réseautage affectée à l’interface de réseau 222 pour le sous-flux MPTCP primaire 122 devient indisponible, par exemple par une réinitialisation d’interface, tandis que le sous-flux auxiliaire existant 124 est toujours en place. Dans un tel cas, le HCPE 101 peut faire présenter une option REMOVE_ADDR dans un segment vers la HAG 102 sur le sous-flux esclave toujours actif 124, c’est-à-dire, il présente le fait que l’adresse de réseautage utilisée n’est plus valide. Ceci déclenche ensuite un nettoyage de l’état MPTCP au niveau de la HAG 102 pour tout sous-flux rattaché à cette adresse. Cette fermeture de connexions qui perdent leur sous-flux primaire est nécessaire en raison du fait que l’adresse pourrait devenir affectée à un autre HCPE durant la durée de vie de la session MPTCP. L’adresse commune pourrait être utilisée simultanément par deux utilisateurs différents, ce qui pourrait conduire à des erreurs sur le réseau.

[74] Par conséquent, la HAG 102 peut terminer la connexion TCP 234 si l’adresse réseau utilisée pour le sous-flux primaire est perdue et, par la suite, libérer toutes les ressources associées. Ceci peut être fait par les étapes suivantes : - la HAG reçoit un segment provenant du HCPE 101 avec l’option REMOVE_ADDR indicative du fait que l’adresse de réseautage utilisée pour le sous-flux primaire est perdue. - Sur ce, la HAG 102 réinitialise la connexion TCP 234 vers le serveur. - La HAG 102 envoie un segment avec l’option TCP MP_FASTCLOSE au HCPE 101. - A réception, le HCPE 101 réinitialise la connexion TCP 234 vers le client 100.

[75] La Figure 6 représente un système informatique approprié 600 qu’en tant que mode de réalisation supplémentaire du HCPE 101 ou de la HAG 102. Le système informatique 600 peut de manière générale être formé en tant qu’ordinateur universel approprié et comprend un bus 610, un processeur 602, une mémoire locale 604, une ou plusieurs interfaces de sortie facultatives 616, une interface de communication 612, une interface d’élément de stockage 606 et un ou plusieurs éléments de stockage 608. Le bus 610 peut comprendre un ou plusieurs conducteurs qui permettent une communication entre les composants du système informatique 600. Le processeur 602 peut comprendre tout type de processeur ou microprocesseur classique qui interprète et exécute des instructions de programmation. Une mémoire locale 604 peut comprendre une mémoire vive (RAM) ou un autre type de dispositif de stockage dynamique qui stocke des informations et des instructions pour une exécution par le processeur 602 et/ou une mémoire morte (ROM) ou un autre type de dispositif de stockage statique qui stocke des informations et des instructions statiques pour une utilisation par le processeur 602. L’interface d’élément de stockage 606 peut comprendre une interface de stockage telle que par exemple une interface SATA ou une interface SCS I pour connecter le bus 610 à un ou plusieurs éléments de stockage 608, tels qu’un ou plusieurs disques locaux, par exemple des lecteurs de disque SATA, et commander la lecture et l’écriture de données sur et/ou depuis ces éléments de stockage 608. Bien que les éléments de stockage 608 ci-dessus soient décrits en tant que disque local, de manière générale tout autre support lisible par ordinateur approprié tel qu’un lecteur à semi-conducteurs ou des cartes de mémoire flash pourrait être utilisé. Le système 600 décrit ci-dessus peut également s’exécuter en tant que machine virtuelle au-dessus du matériel physique. Les étapes réalisées sur les dispositifs de HCPE et HAG selon les modes de réalisation ci-dessus peuvent être partiellement ou complètement mises en œuvre en tant qu’instructions de programmation à exécuter sur le processeur 602. L’interface de communication 612 peut en outre correspondre aux interfaces de réseautage du HCPE ou de la HAG 221,222, 223, 224, 225, 266.

[76] Bien que la présente invention ait été illustrée en référence à des modes de réalisation spécifiques, il apparaîtra à l’homme du métier que l’invention n’est pas limitée aux détails des modes de réalisation illustratifs précédents, et que la présente invention peut être mise en œuvre avec divers changements et modifications sans s’écarter de la portée de celle-ci. Les présents modes de réalisation doivent par conséquent être considérés à tous égards comme illustratifs et non restrictifs, la portée de l’invention étant indiquée par les revendications annexées plutôt que par la description précédente, et tous les changements qui sont dans la signification et la portée d’équivalence des revendications sont par conséquent entendus être englobés ici. En d’autres termes, il est envisagé de couvrir n’importe laquelle et toutes modifications, variations ou n’importe lequel et tous équivalents qui tombent dans la portée des principes sous-jacents de base et dont les attributs essentiels sont revendiqués dans cette demande de brevet. I l sera en outre compris par le lecteur de cette demande de brevet que les mots « comprenant » ou « comprendre » n’excluent pas d’autres éléments ou étapes, que le mot « un » ou « une » n’exclut pas une pluralité, et qu’un élément unique, tel qu’un système informatique, un processeur ou une autre unité intégrée peut remplir les fonctions de plusieurs moyens revendiqués dans les revendications. Tout chiffre de référence dans les revendications ne devra pas être interprété comme limitant les revendications respectives concernées. Les termes « premier », « second », « troisième », « a », « b », « c », et similaires, lorsqu’ils sont utilisés dans la description ou dans les revendications sont introduits pour distinguer des éléments ou des étapes similaires et ne sont pas nécessairement descriptifs d’un ordre séquentiel ou chronologique. De manière similaire, les termes « dessus », « dessous », « sur », « sous », et similaires sont introduits à des fins de description et pas nécessairement pour dénoter des positions relatives. I l est entendu que les termes ainsi utilisés sont interchangeables dans des circonstances appropriées et que les modes de réalisation de l’invention sont capables de fonctionner selon la présente invention dans d’autres séquences, ou dans des orientations différentes de celle(s) décrite(s) ou illustrée(s) ci-dessus.

Figure 1: 100 Client (CL)

101 HCPE

102 H AG 100 Serveur (SRV)

Figure 2: 220 Client (CL)

101 HCPE

102 HAG 103 Serveur (SRV) 122 Sous-flux MPTCP primaire

Figure 3: 220 Client (CL)

101 HCPE

102 HAG 103 Serveur (SRV) 124 Sous-flux MPTCP auxiliaire 122 Sous-flux MPTCP primaire

Figure 4: 220 Client (CL)

101 HCPE

102 HAG 103 Serveur (SRV) 124 Sous-flux MPTCP auxiliaire 122 Sous-flux MPTCP primaire

Figure 5: 520 Dispositif d’équilibrage de charge 521 Dispositif d'équilibrage de charge 501 Serveur HAG 1 502 Serveur HAG 2 503 Serveur HAG N 505 Mandataire

Claims (12)

1. REVENDICATIONS

   1 - Procédé pour échanger des données sur une connexion TCP (234) entre un nœud de client (100) et un nœud de réseautage (103) ; dans lequel la connexion TCP comprend un sous-flux MPTCP primaire (122) sur un premier réseau d’accès (110) entre un équipement de local d’abonné, un HCPE (101), servant de premier nœud mandataire et une passerelle d’accès hybride, une HAG (102), servant de second nœud mandataire ; le procédé comprenant : - par le HCPE : o la conversion (210, 213, 214) de premiers segments TCP (201,206, 207) en premiers segments MPTCP (202, 205, 208) du sous-flux MPTCP primaire et réciproquement ; et o l’utilisation d’informations d’adresse de destination des premiers segments TCP (201, 207) en tant qu’informations d’adresse de destination des premiers segments MPTCP (202, 208) ; et o l’utilisation d’informations d’adresse de source du premier segment MPTCP en tant qu’informations d’adresse de source des premiers segments TCP ; et - par la HAG : o la conversion (211, 212, 215, 217) de seconds segments TCP en seconds segments MPTCP du sous-flux primaire et réciproquement tout en préservant les informations d’adresse de source et de destination, - la connexion TCP (234) comprenant un sous-flux MPTCP auxiliaire sur un second réseau d’accès entre le HCPE (101) et la HAG (102) ; le procédé comprenant en outre : o au niveau du HCPE, la conversion de troisièmes segments TCP en troisièmes segments MPTCP du sous-flux MPTCP auxiliaire et réciproquement ; et o au niveau de la HAG, la conversion de quatrièmes segments TCP en quatrièmes segments MPTCP du sous-flux auxiliaire et réciproquement.
2. 2 - Procédé selon la revendication 1, comprenant en outre : - par le HCPE, l’utilisation d’informations d’adresse de destination de la HAG pour les troisièmes segments MPTCP ; et - pour la HAG, l’utilisation d’informations d’adresse de destination du nœud de réseautage pour les quatrièmes segments envoyés au nœud de réseautage.
3. 3 - Procédé selon les revendications 1 ou 2, comprenant en outre, pour établir le sous-flux MPTCP auxiliaire : - l’envoi, par la HAG pour établir le sous-flux MPTCP auxiliaire, d’un segment comprenant une adresse de la HAG dans le second réseau d’accès sur le sous-flux MPTCP primaire.
4. 4 - Procédé selon l’une quelconque des revendications 1 à 3, comprenant en outre : - l’envoi, par le HCPE, d’un segment comprenant une requête pour établir le second sous-flux MPTCP vers la HAG.
5. 5 - Procédé selon l’une quelconque des revendications 1 à 3, comprenant en outre : - l’envoi, par la HAG, d’un segment comprenant une requête pour établir le second sous-flux MPTCP vers le HCPE.
6. 6 - Procédé selon la revendication 1 ou 2 comprenant, pour l’établissement du sous-flux MPTCP primaire et du sous-flux MPTCP auxiliaire : - par la HAG, la réception d’un segment de synchronisation provenant du HCPE indicatif d’une requête pour établir les sous-flux MPTCP primaire et auxiliaire ; et - par la suite, par le HCPE, la réception d’un segment de synchronisation et d’acquittement provenant de la HAG ; et - l’établissement, par le HCPE, des sous-flux MPTCP primaire et auxiliaire ; et - la réception, par la HAG, d’un segment d’acquittement provenant du HCPE ; et - par la suite, par la HAG, l’établissement des sous-flux MPTCP primaire et auxiliaire.
7. 7 - Procédé selon l’une des revendications 1 à 6, dans lequel la HAG comprend une pluralité de serveurs de passerelle, chacun agissant en tant que passerelle entre le premier réseau d’accès et le nœud de réseautage ; et dans lequel le procédé comprend en outre : - par la HAG, l’équilibrage de charge du sous-flux MPTCP primaire sur l’un des serveurs de passerelle.
8. 8 - Procédé pour échanger des données sur une connexion TCP (234) entre un nœud de client (100) et un nœud de réseautage (103) ; dans lequel la connexion TCP comprend un sous-flux MPTCP primaire (122) sur un premier réseau d’accès (110) entre un équipement de local d’abonné, un HCPE (101), servant de premier nœud mandataire et une passerelle d’accès hybride, une HAG (102), servant de second nœud mandataire ; le procédé comprenant : - par le HCPE: o la conversion (210, 213, 214) de premiers segments TCP (201,206, 207) en premiers segments MPTCP (202, 205, 208) du sous-flux MPTCP primaire et réciproquement ; et o l’utilisation d’informations d’adresse de destination des premiers segments TCP (201, 207) en tant qu’informations d’adresse de destination des premiers segments MPTCP (202, 208) ; et o l’utilisation d’informations d’adresse de source du premier segment MPTCP en tant qu’informations d’adresse de source des premiers segments TCP, - la connexion TCP (234) comprenant un sous-flux MPTCP auxiliaire sur un second réseau d’accès entre le HCPE (101) et la HAG (102) ; le procédé comprenant en outre : o au niveau du HCPE, la conversion de troisièmes segments TCP en troisièmes segments MPTCP du sous-flux MPTCP auxiliaire et réciproquement ; et o au niveau de la HAG, la conversion de quatrièmes segments TCP en quatrièmes segments MPTCP du sous-flux auxiliaire et réciproquement.
9. 9 - Procédé pour échanger des données sur une connexion TCP (234) entre un nœud de client (100) et un nœud de réseautage (103) ; dans lequel la connexion TCP comprend un sous-flux MPTCP primaire (122) sur un premier réseau d’accès (110) entre un équipement de local d’abonné, un HCPE (101), servant de premier nœud mandataire et une passerelle d’accès hybride, une HAG (102), servant de second nœud mandataire ; le procédé comprenant : - par la HAG : o la conversion (211, 212, 215, 217) de seconds segments TCP en seconds segments MPTCP du sous-flux primaire et réciproquement tout en préservant les informations d’adresse de source et de destination, - la connexion TCP (234) comprenant un sous-flux MPTCP auxiliaire sur un second réseau d’accès entre le HCPE (101) et la HAG (102) ; le procédé comprenant en outre : o au niveau du HCPE, la conversion de troisièmes segments TCP en troisièmes segments MPTCP du sous-flux MPTCP auxiliaire et réciproquement ; et o au niveau de la HAG, la conversion de quatrièmes segments TCP en quatrièmes segments MPTCP du sous-flux auxiliaire et réciproquement.
10. 10 - Equipement de local d’abonné hybride, HCPE (101), configuré pour réaliser les étapes réalisées par le HCPE selon l’une quelconque des revendications 1 à 8.
11. 11 - Passerelle d’accès hybride (102) configurée pour réaliser les étapes réalisées par la HAG (102) selon l’une quelconque des revendications 7 et 9.
12. 12 - Système comprenant le HCPE (101) selon la revendication 10 et la HAG (102) selon la revendication 11.