FR2892248A1 - Procede d'interaction entre un protocole de connexion de type point a point et un protocole de configuration dynamique pour permettre l'acces a un service - Google Patents

Abstract

La présente invention concerne un procédé d'accès par un client à un service au travers d'un réseau, ledit client mettant en oeuvre un protocole de connexion de type point à point pour l'établissement d'une session d'accès audit service, dite session point à point.Ledit service met en oeuvre un protocole de fourniture dynamique d'au moins un paramètre de configuration, appelé protocole de configuration dynamique, pour l'établissement d'une session d'accès par ledit client, dite session conforme audit protocole de configuration dynamique. Le procédé comprend, alors, une étape de conversion de ladite session point à point en une session conforme audit protocole de configuration dynamique, mise en oeuvre dans un équipement intermédiaire dudit réseau.

Description

L'invention se situe dans le domaine des télécommunications, et plus

particulièrement dans le domaine des réseaux d'accès fixes. De tels réseaux d'accès fixes permettent par exemple à un usager d'accéder au réseau mondial Internet, par connexion en bande étroite, ou, plus récemment, au moyen d'une connexion large bande telle que l'ADSL (de l'abréviation anglaise "Asymmetric Digital Subscriber Une", ou en français "Ligne d'Abonné Numérique Asymétrique ") Pour des raisons historiques et par similitude avec ce qui est utilisé lors de connexions en bande étroite, l'accès à Internet au moyen d'une connexion large bande se fait, pour la plupart des opérateurs en télécommunications dans le monde, en utilisant un protocole PPP (Point-to-Point Protocol ou "Protocole Point à point" en français). La base installée des usagers abonnés à I'ADSL et équipés de matériel utilisant ce protocole est donc très important. Un tel protocole PPP propose une méthode pour le transport de datagrammes multi-protocoles sur une liaison point à point entre deux éléments distants. Il comprend trois composants principaux : une méthode pour encapsuler des datagrammes issus de plusieurs protocoles différents; un protocole de contrôle du lien ou "Link Control Protocol' (LCP) destiné à établir, configurer, et tester une liaison de données; enfin, une famille de protocoles de contrôle de réseau ou "Network Contrai Protocols" (NCPs) pour l'établissement et la configuration de plusieurs protocoles de la couche réseau, telle que définie dans le modèle CS l (Open Systems Interconnection ou en français Inter corä ex : de Systèmes Ouverts").

Un tel protocole PPP est utilisé sur des liaisons transportant des paquets de données entre deux éléments distants et permettant une communication simultanée bidirectionnelle. Ce protocole propose une solution commune pour un raccordement aisé d'une grande variété d'hôtes, de ponts et de routeurs.

L'ensemble de protocoles contenus dans le protocole PPP permet entre autres, le contrôle d'accès, dont l'authentification des utilisateurs est une composante, et l'attribution d'adresses 1P aux terminaux clients, et inclut la notion d'établissement et de terminaison de sessions entre un client et un serveur. Un tel protocole PPP est défini dans le document référencé RFC 1661 (RFC signifiant "requête pour commentaires, ou en anglais Request For Comments) établi par I'IETF (groupe pour la participation à la standardisation de l'Internet, abréviation des termes anglais Internet Engineering Task Force). En référence à la figure 1, lors de l'établissement d'une session conforme au protocole PPP, dite session PPP, une liaison point-à-point est établie entre un client PPP 1 et un serveur PPP appelé BAS 2 situé dans le réseau (BAS signifiant Broadband Remote Access Server, ou en français, "serveur d'accès large bande à distance"). Un tel serveur BAS 2, également appelé de manière plus générale serveur RAS (RAS signifiant Remote Access Server ou en français, "serveur d'accès à distance") remplit une fonction d'identification du client PPP 1 au moyen de mécanismes d'authentification. Afin de simplifier l'exposé, nous utiliserons indifféremment dans la suite de ce document les termes de serveurs \ ~äj OU BAS. RAS ou BrtAS. I,.ii BAS 2 V ~] une 1 S 441 Le serveur BnS 2 exerce aussi une fonction d'allocation d'adresses IP et de paramètres DNS (Domain Name System ou en français, "système de nom de domaine"), ainsi qu'une fonction d'établissement et de terminaison de sessions PPP. Toujours en référence à la figure 1, le serveur BAS 2 peut inclure également un client RADIUS qui établit un dialogue avec un serveur RADIUS 3 (Remote Authentification Dia/4n User Service ou en français "service a [ entification à distance d'un _ a_eur entrant") qui fournit des paramètres de configuration de chaque client PPP 1 sur la base des paramètres d'authentification ou d'identification qui leurs sont associés. Ainsi, lors de l'établissement d'une session PPP, le serveur BAS 2 interroge le serveur RADIUS 3 afin d'authentifier le client PPP 1 et, le cas échéant, d'ouvrir une session PPP. La clôture d'une session PPP se traduit par la rupture de la liaison établie entre le client PPP 1 et le serveur BAS 2. La notion de session étant clairement définie dans le protocole PPP, il est possible pour un opérateur en télécommunications de connaître avec exactitude la durée d'une session en cours ou qui s'est achevée. Ceci lui permet de contrôler et de facturer de manière standard et précise la consommation de ses usagers. Le manque de souplesse du protocole PPP, notamment pour les applications diffusées en multicast et/ou demandant des qualités de services 15 distinctes constitue l'un des principaux inconvénients du protocole PPP. Un autre inconvénient de l'utilisation du protocole PPP est que l'utilisation de serveurs RAS centralisés ne permet pas la diffusion en multicast de nouveaux contenus ou de nouveaux services car la bande passante disponible sur le réseau de collecte IP n'est pas suffisante. En outre les serveurs RAS 20 sont des équipements souvent dédiés, onéreux et difficiles à gérer. Dans ce contexte, la question de la pertinence de garder une architecture basée sur l'utilisation du protocole PPP, notamment pour l'accès Internet dans un réseau se pose. Les acteurs de !'industrie des télécommunications ont donc étudié les 25 possibilités qui s'offrent à eux, comme alternatives au protocole PPP. Parmi celles-ci, le protocole DHCP (abréviation de Dynamic Host Configuration Protocol, ou en français, "protocole de configuration dynamique d'un hôte"), est largement utilisé et déployé dans les réseaux locaux et privés. I! est notamment utilisé par certains opérateurs en télécommunications pour le déploiement de services tels que la télévision par ADSL, ou la visiophonie. Le protocole DHCP permet à un équipement qui se connecte sur un réseau d'obtenir dynamiquement, c'est-à-dire sans intervention particulière, des paramètres de configuration tels qu'une adresse IP. Un tel protocole DHCP est défini dans le document référencé RFC 2131. En référence à la figure 2, lorsqu'un équipement 4 se connecte à un réseau une liaison est établie entre un client DHCP 5, embarqué dans l'équipement 4, et un serveur DHCP 6 présent dans le réseau.

Contrairement au cas du protocole PPP, la notion de session n'existe pas en tant que telle dans le protocole DHCP. Lors de la mise en oeuvre du protocole DHCP, les paramètres de configuration d'un client DHCP 5, tels que son adresse IP, sont attribués pour une durée déterminée appelée "bail", à l'issue de laquelle ils sont libérés et redeviennent accessibles aux autres usagers, ce qui permet d'optimiser les ressources du réseau. Cependant, un client DHCP 5 qui voit son bail arriver à terme peut demander au serveur DHCP 6 une prolongation du bail. Si le serveur DHCP 6 ne reçoit pas de requête de prolongement du bail de la part du client DHCP 5, avant l'expiration du bail, ou si le bail n'est pas prolongeable, il rend disponible lors de la fin du bail l'adresse IP qu'il avait attribuée à ce client DHCP 5 pour la durée de son bail. Afin d'initialiser un bail DHCP entre un client DHCP 5 et un serveur DHCP 6, ce dernier doit procéder à l'affectation de paramètres de configuration au client DHCP 5. Après affectation, le serveur DHCP 6 mémorise les paramètres de configuration de chaque client DHCP 5, ainsi qu'éventuellement leurs données d'authentification, pour toute la durée du bail voire au delà. L'utilisation du protocole DHCP pour tous les services présenterait plusieurs a ., tttges pour un opérateur en télécommunication. En effet, elle permettrait ; ot:amment de supprimer les serveurs RAS dans le réseau de collecte, d'optimiser l'utilisation de la bande passante du réseau et de rendre possible une communication par le plus court chemin entre les usagers titulaires d'une ligne ADSL connectés à un même noeud d'accès ou à une même boucle de collecte.

L'utilisation du protocole DHCP pour l'accès aux services du type Internet, permettrait également l'homogénéisation de tous les services proposés par un opérateur en télécommunications par l'utilisation du même protocole d'attribution d'adresses IP puisque, comme indiqué plus haut, certains de ces services tels que la télévision par ADSL par exemple, sont déjà conformes à ce protocole. L'utilisation du protocole DHCP constituerait, également, une étape vers la convergence des réseaux fixes et mobiles et une meilleure intégration mutuelle des services offerts par l'opérateur. Cependant, les inventeurs ont constaté que la majorité des équipements permettant aux usagers d'accéder aux services de type Internet sont configurés pour utiliser le protocole PPP. De multiples serveurs RAS sont donc déployés dans les réseaux d'accès et la plupart des usagers titulaires d'une ligne ADSL mettent en oeuvre un client PPP, dans un modem ou directement dans un ordinateur. La problématique de la migration d'une offre de service conforme au protocole PPP vers une offre de service conforme au protocole DHCP doit donc être étudiée avec soin. Afin de réaliser cette migration, deux solutions principales s'offrent logiquement à un opérateur en télécommunications. La première solution consisterait à modifier ou faire modifier la configuration de tous les modems et ordinateurs de l'ensemble des usagers pour que l'accès aux services repose désormais sur l'utilisation du protocole DHCP à la place du protocole PPP. Etant donné le nombre et les différents types et marques d'équipements d'ores et déjà déployés, cette solution s'avère très difficile à mettre en oeuvre, très longue et très coûteuse. En outre, elle pourrait être perçue comme intrusive par les usagers.

Une deuxième solution consisterait à faire coexister, dans un même réseau, les deux types d'architecture, l'une fonctionnant avec le protocole PPP et l'autre fonctionnant avec le protocole DHCP. En d'autres termes, l'opérateur en télécommunications déploierait simultanément dans le réseau des serveurs RAS et des serveurs RADIUS pour les accès utilisant le protocole PPP, et des serveurs DHCP pour les nouveaux clients utilisant le protocole DHCP, de façon à pouvoir offrir un accès aux services simultanément aux clients historiques utilisant le protocole PPP et à de nouveaux clients utilisant le protocole DHCP. Cette double architecture devrait être maintenue par l'opérateur dans le réseau jusqu'à ce que le renouvellement naturel de leurs équipements par les usagers ait conduit à la disparition complète de l'utilisation du protocole PPP au profit de l'utilisation du protocole DHCP. Le gain en termes d'investissement, pour l'opérateur en télécommunications, serait donc nul car cette solution ne permettrait pas la suppression des serveurs RAS qui sont particulièrement coûteux. En outre, l'opérateur en télécommunications devrait supporter des coûts d'exploitation supplémentaires liés à la nécessité de gérer et maintenir les deux architectures simultanément. L'invention propose une solution qui ne présente pas ces inconvénients. En effet, elle repose sur un procédé d'accès par un client à un service au 20 travers d'un réseau, le client mettant en oeuvre un protocole de connexion de type point à point pour l'établissement d'une session d'accès audit service, dite session point à point. Selon !'inv:e-ntion, ledit service mot en oeuvre un prOtOCOle de fourniture dynamique Sao. rnoins ur, parametre de configuration, appelé protocole de configuration dynamique, pour rétablissement d'une session d'accès par ledit client, dite session conforme audit protocole de configuration dynamique, et ledit procédé comprend une étape de conversion de ladite session point à point en une session conforme audit protocole de. configuration dynamique, . lise en oeuvre dans un équipement iritermédi.aire dudit réseau.

Ainsi, l'invention permet à un client utilisant un protocole de type pointà-point d'accéder à un service fourni selon un protocole de configuration dynamique, en réalisant une conversion, par adaptation protocolaire, d'une session point-à-point en session conforme au protocole de configuration dynamique. On notera que ce terme de session n'est pas habituellement employé dans le domaine des protocoles de configuration dynamique, pour lesquels on parle plus généralement de bail. L'homme du métier comprendra cependant aisément ce terme, par analogie avec le principe de fonctionnement des protocoles point-à-point.

Un tel procédé, de mise en oeuvre simple, permet de supprimer progressivement le protocole point-à-point, comme par exemple le protocole PPP, pour le remplacer par un protocole de configuration dynamique, comme par exemple le protocole DHCP. On notera, bien sûr, que l'invention ne se limite pas aux simples protocoles PPP et DHCP mais peut être utilisée pour toutes situations oû un client utilisant un protocole de type point-à-point souhaite accéder à un service implémentant un protocole de configuration dynamique. Ce procédé ne nécessite pas d'intervention dans les équipements déjà déployés chez les usagers, pour lesquels il est donc transparent. Il ne nécessite pas, non plus, la mise en place d'une infrastructure de réseau complexe. Une telle conversion peut être exécutée dans tout équipement intermédiaire du réseau situé entre le client et le serveur. On notera cependant qu'il est avantageux de réaliser cette conversion le plus en amont possible, c'est-à-dire près du client, comme par exemple dans le noeud d'accès du client au réseau. Dans l'exemple particulier de la migration d'un protocole PPP vers un protocole DHCP, la solution de l'invention permet également de mutualiser le serveur DHCP qui peut être utilisé simultanément par des usagers dont les modems ou les ordinateurs sont configurés pour utiliser le protocole DHCP et des usagers ~-~ le protocole PPP.

Cette mutualisation facilite la configuration et l'exploitation du réseau ce qui entraîne une réduction des coûts pour l'opérateur en télécommunications et lui permet, également, de mettre en oeuvre un plan d'adressage unique pour tous ses usagers.

Selon une caractéristique de l'invention, ladite étape de conversion comprend, sur réception d'un premier message d'établissement de ladite session point à point par ledit équipement intermédiaire, une étape d'émission d'au moins un deuxième message d'établissement de ladite session conforme audit protocole de configuration dynamique, ledit deuxième message d'établissement étant un message de fourniture et/ou de requête d'au moins un paramètre de ladite session conforme audit protocole de configuration dynamique. En d'autres termes, et en reprenant l'exemple particulier des protocoles PPP et DHCP, lorsque l'équipement intermédiaire (par exemple un équipement de type DSLAM) reçoit un message de type LCPConfigRequest, il active l'initialisation d'une session DHCP, en émettant un message DHCPDiscover, pour découvrir un ou plusieurs serveurs accessibles, suivi, sur réponse d'un serveur, d'un message de type DHCPRequest servant à fournir ou à demander les paramètres de session DHCP.

Ainsi, une initialisation de session PPP par le client déclenche automatiquement l'initialisation d'une session DHCP par l'équipement intermédiaire, de façon tout à fait transparente pour le client PPP comme pour le serveur DHCP. Tout se passe, pour le client PPP, comme si le service lui était accessible de bout en bout via le protocole PPP. Quant au serveur DHCP, tout se passe pour lui comme s'il devait établir un bail pour un usager utilisant le protocole DHCP. Les paramètres de session sont, par exemple, un identifiant de session, une durée de session ou encore un couple nom d'utilisateur/mot de passe. Enfin, il faut comprendre ici que dans les expressions "premier message d'établissement de ladite session point à point" et "deuxième message d'établissement de ladite session conforme audit protocole de configuration dynamique", les termes "premier" et "deuxième" ne revêtent pas nécessairement un caractère chronologique. Ils n'ont pour but que de permettre la distinction entre ces deux messages afin de faciliter la compréhension du lecteur. Avantageusement, ladite étape de conversion comprend, sur réception desdits paramètres de ladite session conforme audit protocole de configuration dynamique en provenance dudit réseau, et/ou sur réception d'au moins un paramètre de ladite session point â point en provenance dudit client, une étape de mémorisation desdits paramètres dans ledit équipement intermédiaire. Les paramètres de session obtenus sont par exemple, une adresse IP ou encore une adresse d'un serveur DNS. Tout ou partie de ces paramètres de session sont ensuite transmis d'un protocole à l'autre. Autrement dit les paramètres classiquement transmis et obtenus au moyen d'un serveur RADIUS sont maintenant transmis et obtenus au moyen d'un serveur DHCP. Il est alors possible, pour un client apte à transmettre et/ou recevoir des informations selon un protocole de transport point à point, d'accéder à des services fournis par un opérateur en télécommunications même si celui-ci n'est pas compatible avec le protocole de transport point à point permettant d'accéder aux services de fournisseurs de services. Il est à noter que des paramètres de session tels qu'une adresse IP ou encore une adresse de serveur DNS sont des paramètres de configuration, qui 25 constituent un sous-ensemble de l'ensemble des paramètres de session. Selon une caractéristique de l'invention, ladite étape de conversion met en oeuvre: sur réception par ledit équipement intermédiaire d'un message selon ledit )tocole point point, une étape d'extraction d'au moins un 30 pa e la F point à point, encapsulé dans ledit message, et une étape de transfert dudit paramètre de la session point à point vers ledit réseau, conformément audit protocole de configuration dynamique; sur réception par ledit équipement intermédiaire d'un message selon ledit protocole de configuration dynamique, une étape d'extraction d'au moins un paramètre de la session conforme au protocole de configuration dynamique, encapsulé dans ledit message, et une étape de transfert dudit paramètre de la session conforme au protocole de configuration dynamique vers ledit client, conformément audit protocole point à point.

Ainsi, l'équipement intermédiaire garantit une transmission correcte des paramètres de session échangés entre le client et le serveur et réciproquement, en adaptant leur format aux protocoles de transmission du réseau sur lequel ils circulent et aux protocoles implémentés dans le serveur et l'équipement client. Par exemple, l'équipement intermédiaire peut extraire des paramètres de session encapsulés dans une trame conforme au protocole point-à-point, leur appliquer éventuellement un traitement spécifique, puis les insérer dans les options conformes au protocole de configuration dynamique, avant de les envoyer sur le réseau. Inversement, l'équipement intermédiaire peut extraire des paramètres de session encapsulés dans une trame conforme au protocole de configuration dynamique implémenté dans le serveur, puis les insérer de nouveau dans une trame conforme au protocole point-à-point. Dans un mode de réalisation de l'invention, l'étape d'extraction des paramètres de session est suivie d'une étape de mémorisation des paramètres extraits. Ainsi en cas d'échec de la transmission, les paramètres de session ne sont pas perdus et une nouvelle tentative de transmission peut être effectuée. De manière avantageuse, ladite étape de conversion comprend, sur réception d'un message d'absence de fourniture desdits paramètres de ladite session conforme audit protocole de configuration dynamique en provenance dudit réseau, une étape de transmission par ledit équipement intermédiaire audit d'un message d'absence d' .. , â de configuration selon ledit protocole de transport point à point. Ainsi, le client sait qu'il doit envoyer un nouveau message protocolaire demandant l'attribution de paramètres de session. Notamment, en reprenant l'exemple particulier des protocoles PPP et DHCP, le client PPP est ainsi informé de la nécessité de relancer un message LCPConfigRequest en cas d'échec de l'attribution de paramètres de session par le serveur DHCP. II est à noter que les messages d'absence de fourniture de paramètres de session peuvent ne pas être émis. Ainsi un silence suivant l'émission d'un message de demande de fourniture de paramètres de session est alors interprété comme une absence de fourniture de ces paramètres. De manière avantageuse, lesdits paramètres transférés appartiennent au groupe comprenant: au moins une donnée d'authentification dudit client; au moins une donnée d'identification d'une ligne de connexion dudit client audit réseau; au moins un paramètre de configuration. De telles données sont par exemple le couple login/mot de passe du client qui permet l'authentification du client par le serveur afin d'éviter toute usurpation de la liaison par un tiers, ou encore d'une adresse IP.

Selon un autre aspect de l'invention, ladite étape de conversion comprend, en cas de détection d'une fin de session point à point, respectivement d'une fin de session selon ledit protocole de configuration dynamique, une étape de transmission d'un message de libération desdits paramètres de configuration selon ledit protocole de configuration dynamique vers ledit réseau, respectivement d'un message de fin de session point à point vers ledit client. La transmission de ces messages de fin de session vers le client et vers le serveur permet de s'assurer tant du côté du client que du côté de l'opérateur en télécc s de la clôture d'une session. CE _ erme également a l'opérateur de connaître avec précision la durée effective d'une session. Cette information lui permet, notamment, de facturer ses clients en fonction de la durée des sessions que ceux-ci ont initiés. A réception du message de libération des paramètres de session, le serveur libère les paramètres de session attribués au client pour la durée de sa session. Cela signifie par exemple, que l'adresse IP qui était attribuée au client pour la durée de sa session peut être attribuée à un nouveau client pour lequel une nouvelle session vient d'être initiée. L'invention concerne également un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé tel que décrit précédemment lorsque ledit programme est exécuté par un processeur. L'invention concerne encore un système d'accès à un service par un client au travers d'un réseau, ledit client mettant en oeuvre un protocole de connexion de type point à point pour l'établissement d'une session d'accès audit service, dite session point à point, caractérisé en ce que ledit service est accessible par l'intermédiaire d'un serveur mettant en oeuvre un protocole réseau de fourniture dynamique d'au moins un paramètre de configuration, appelé protocole de configuration dynamique, et en ce que ledit système comprend, dans un équipement intermédiaire dudit réseau, des moyens de conversion de ladite session point à point en une session d'accès audit service conforme audit protocole de configuration dynamique. L'invention a également pour objet un équipement intermédiaire d'un réseau permettant l'accès par un client à un service, ledit client mettant en oeuvre un protocole de connexion de type point à point pour l'établissement d'une session d'accès audit service, dite session point à point, caractérisé en ce que, ledit service étant accessible par l'intermédiaire d'un serveur mettant en oeuvre un protocole réseau de fourniture dynamique d'au moins un paramètre de con .ara appelé protocole de tetion dy. ledit équipement tntermedâaiie comprend des moyens ion F de ladite session point â point en une session d'accès audit service conforme audit protocole de configuration dynamique. Selon une variante de réalisation, ledit équipement est un noeud d'accès dudit client audit réseau.

Ainsi, la conversion de session est réalisée très en amont dans le réseau, ce qui permet de gagner en efficacité. En outre, différents clients connectés à un même noeud d'accès du réseau peuvent échanger des données entre eux sans que ces données ne transitent par des équipements distants comme cela peut être le cas lorsque les clients mettent en oeuvre un protocole point-à-point comme le protocole PPP avec un serveur RAS centralisé. Selon une autre variante de réalisation, lesdits moyens de conversion comprennent: un serveur mettant en oeuvre ledit protocole point à point; - un client mettant en oeuvre ledit protocole de configuration dynamique; - des moyens d'interaction desdits serveur et client. D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation préférés décrits en référence aux dessins dans lesquels : - la figure 1, déjà commentée en relation avec l'art antérieur, présente une architecture comportant divers équipements réseaux impliqués dans l'établissement d'une session entre un client PPP et un serveur BAS; - la figure 2, également commentée en relation avec l'art antérieur, présente une architecture comportant divers équipements réseaux impliqués dans la délivrance par un serveur DHCP d'un bail DHCP à un client DHCP; - la figure 3 présente une architecture dans laquelle le procédé selon l'invention est mis en oeuvre, - la figure 4 illustre schématiquement un équipement réseau dans lequel l'invention est 1,entée, - la figure 5 décrit un algorithme de fonctionnement du procédé selon l'invention mis en oeuvre dans un équipement intermédiaire du réseau lorsque celui-ci traite des paquets de données dans le sens remontant, - la figure 6 présente un algorithme de fonctionnement équivalent de celui de la figure 5 pour le cas de traitement de paquets de données dans le sens descendant, - la figure 7 propose un diagramme temporel d'échanges de requêtes entre un client PPP d'une part et un équipement intermédiaire du réseau implémentant le procédé selon l'invention d'autre part et, entre cet équipement intermédiaire d'une part et un serveur DHCP d'autre part, dans le cadre d'un premier mode de réalisation de la présente invention, - la figure 8 illustre une variante de la figure 7 dans un deuxième mode de réalisation de la présente invention, - la figure 9 illustre une variante de la figure 7 dans un troisième mode de réalisation de la présente invention, - les figures 10 et 11 proposent un diagramme temporel d'échanges de requêtes entre un client PPP d'un part et un équipement intermédiaire du réseau implémentant le procédé selon l'invention d'autre part et, entre cet équipement intermédiaire d'une part et un serveur DHCP d'autre part, respectivement lorsque le client PPP décide de clôturer une session PPP, ou que l'un des équipements en présence ne répond pas. Le principe général de l'invention repose sur la conversion, dans un équipement intermédiaire d'un réseau de communication, d'une session d'accès implémentant un protocole de type point à point, initiée par un usager, en une session conforme à un protocole de configuration dynamique utilisé par un serveur apte à fournir des services. Dans toute la suite de la description, on se limitera à un exemple particulier d'application aux protocoles PPP (et ses variantes telles que PPPoE et PPPoA) et DHCP. L'invention est bien sûr également susceptible de s'appliquer à d'autres protocoles proches ou similaires. On présente désormais, en relation avec la figure 3, une architecture de réseau dans laquelle l'invention est implémentée. Sur cette figure, un premier terminal usager A est connecté à un équipement réseau intermédiaire 7, constituant un noeud du réseau, au moyen d'un équipement 11 embarquant un client PPP 1 implémentant leprotocole PPP. L'équipement 11 est, par exemple, un modem. Un deuxième terminal usager B est également connecté à l'équipement réseau intermédiaire 7, mais cette fois au moyen d'un équipement 4 embarquant un client DHCP 5 implémentant le protocole DHCP. L'équipement intermédiaire 7 est, de préférence, situé dans le premier noeud auquel sont connectés les usagers, autrement dit, le noeud d'accès. Un tel équipement intermédiaire 7 est par exemple un DSLAM (Digital Line Subscriber Line Access Multiplexer, ou en français "multiplexeur d'accès de ligne d'abonné numérique"). L'équipement intermédiaire 7 est ensuite connecté à un réseau de collecte R. Un serveur DHCP 6 appartenant à un opérateur en télécommunications est présent dans le réseau. Le procédé selon l'invention consiste à permette à un usager connecté au réseau au moyen d'un équipement 11 embarquant un client PPP 1 de pouvoir accéder à un service accessible par un protocole de configuration dynamique tel que le protocole DHCP. Dans l'exemple particulier de réalisation décrit ici, un tel procédé est implémenté dans l'équipement intermédiaire 7. Ainsi, sur la figure 4, l'équipement intermédiaire 7 comporte un serveur RAS 10, un client DHCP 60 et des moyens de conversion 8 d'une session PPP en une session DHCP. Ces moyens de conversion 8 ont pour fonction d'assurer la corrélation des activités du serveur RAS 10 et du client DHCP 60.

En référence aux figures 3 et 4, une session PPP est initiée entre le client PPP 1 et le serveur RAS 10 embarqué dans l'équipement intermédiaire 7 en vue d'accéder à un service. Pour établir la session PPP, le client PPP 1 transmet des messages protocolaires au serveur RAS 10. Ces messages, qui sont par exemple un message LCPconfigRequest de demande de paramètres de configuration, sont ensuite traités par les moyens de conversion 8 et transmis au client DHCP 60. Une fois en possession de ces messages protocolaires, le client DHCP dialogue avec le serveur DHCP 6 afin d'obtenir les paramètres de configuration demandés et ensuite de pouvoir initialiser un bail DHCP. Pour cela, le client DHCP 60 émet une requête DHCPREQUEST à destination du serveur DHCP 6 en vue d'obtenir des paramètres de configuration. Lorsque l'usager souhaitant accéder à un service auprès d'un opérateur en télécommunications dispose d'un terminal B connecté au réseau R au moyen d'un équipement 4 embarquant un client DHCP 5, le noeud d'accès DSLAM 7 traite les paquets émis par le client DHCP 5 de manière classique en les envoyant directement sur le réseau R. L'équipement intermédiaire 7 comporte donc des moyens de détermination du protocole mis en oeuvre par un client. Une fois identifiée la nature du protocole utilisé par le client, à savoir PPP ou DHCP, l'équipement intermédiaire 7 sait s'il doit ou non mettre en oeuvre le procédé selon l'invention. Ainsi, il est possible, pour un client apte à transmettre et/ou recevoir des informations selon le protocole PPP, d'accéder à des services fournis par un opérateur en télécommunications même si ceux-ci ne sont pas compatibles avec le protocole de transport PPP. La figure 5 représente le principe de fonctionnement de l'équipement intermédiaire 7 lorsqu'un paquet de données est émis dans le sens remontant, c'est-à-dire provenant du client PPP 1 ou DHCP 5.

Dans une première étape El, le DSLAM 7 détermine la nature des paquets de données reçus afin de savoir si ce sont des paquets émis au moyen du protocole PPP, du protocole DHCP ou bien d'autres protocoles tels que le protocole IP (Internet Protocol ou "protocole Internet") ou le protocole Ethernet. Si le paquet reçu par le DSLAM 7 est un paquet IPoE (Internet Protocol over Ethernet) émis au moyen du protocole IP et encapsulé dans une trame conforme au protocole Ethernet, celui-ci est directement transmis, au cours d'une étape E2, sur le réseau.

Si le paquet reçu est un paquet émis au moyen du protocole DHCP, le DSLAM insère alors, au cours de l'étape E5, les informations dans les options du paquet DHCP comme par exemple l'option 82 qui contient l'identifiant de ligne du client. Le DSLAM 7 transmet alors le paquet sur le réseau. Si le paquet reçu est un paquet émis au moyen du protocole PPP, le DSLAM 7 en détermine la nature pour savoir si un tel paquet PPP est conforme au protocole PPPoA ou PPPoE. Si le paquet est émis conformément au protocole PPPoA, le DSLAM 7 exécute alors l'étape E3, au cours de laquelle le paquet PPP reçu est mis en conformité avec le protocole PPPoE. Au cours d'une étape E40, le DSLAM 7 étudie le contenu de ce paquet PPP. Si ce contenu correspond à un message d'initialisation ou de clôture de session PPP, ou encore à un message de configuration de session PPP, le DSLAM 7 exécute l'étape E43. Si tel n'est pas le cas, et que le contenu du paquet est constitué de données, telles des données de voix sur IP par exemple, alors le DSLAM 7 exécute l'étape E41, Au cours de l'étape E43, le DSLAM 7 insère dans le paquet PPP une information PPPoE IA qui correspond à l'identifiant de ligne du client. E .; , e, au cours de l'étape E44, les moyens de conversion 8 extraient les messages protocolaires contenus dans le paquet PPP afin de les transmettre au client DHCP 60 qui les insère dans des champs d'un paquet DHCP. A titre d'exemple, l'identifiant de ligne du client est une information que les moyens de conversions 8 extraient du paquet PPP. Au cours de l'étape E45, le DSLAM 7, tout comme lors de l'étape E5, insère les informations dans différentes options du paquet DHCP obtenues lors de l'étape précédente. Le DSLAM 7 procède ensuite à la transmission du paquet DHCP vers le serveur DHCP 6. Au cours de l'étape E41, le DSLAM 7 désencapsule les trames de données contenues dans le paquet PPP reçu et les réencapsule dans un paquet IPoE conforme au protocole Ethernet. Le paquet IPoE ainsi obtenu est ensuite transmis sur le réseau. La figure 6 représente le principe de fonctionnement de l'équipement intermédiaire 7 lorsqu'un paquet de données est émis dans le sens descendant, c'est-à-dire du réseau vers le client PPP 1 ou DHCP 5.

Dans une première étape F1, le DSLAM 7 détermine la nature des paquets de données reçus afin de savoir si ce sont des paquets émis au moyen du protocole DHCP ou bien des paquets IPoE. Si le paquet reçu est un paquet IPoE émis au moyen du protocole lP, le DSLAM prend connaissance, au cours d'une étape F30, de l'adresse 1P du terminal destinataire du paquet. Si l'adresse IP destinataire est une adresse obtenue par le client DHCP 60, alors, le DSLAM exécute l'étape F31. Sinon, ce paquet subit le traitement par défaut qui est appliqué par le DSLAM à tout paquet IP, par exemple une transmission directe vers le client DHCP 5 Au cours de cette étape F31, le paquet est encapsulé dans un paquet PPPoE. Au cours de l'étape F32, le DSLAM 7 détermine si le paquet PPP obtenu à l'issue de l'étape précédente est relatif à une session PPPoA ou PPPoE. Si le paquet PPP est relatif à une session PPPoA, le DSLAM exécute alors l'étape F33, au cours de laquelle le paquet PPP reçu est mis en conformité avec le protocole PPPoA. Si le paquet reçu est un paquet DHCP, le DSLAM 7 lit, au cours d'une étape F20, les informations contenues dans les différentes options du paquet DHCP et les mémorise au cours d'une étape F21. Au cours d'une étape F22, le DSLAM 7 détermine la nature du client DHCP destinataire du paquet DHCP reçu, par exemple sur la base d'un identifiant de connexion de la session DHCP. Cet identifiant de connexion correspond à un paramètre appelé paramètre XID. Ce paramètre consiste en un nombre aléatoire choisi par le client DHCP 60 qu'il utilise avec le serveur DHCP 6 pour associer les requêtes et les réponses. Si le client destinataire est le client DHCP 5, le paquet DHCP lui est transmis directement, si le client destinataire est le client DHCP 60, le DSLAM exécute alors l'étape F23.

Au cours de cette étape F23, les moyens de conversion 8 extraient les paramètres protocolaires contenus dans le paquet DHCP afin de les transmettre au serveur RAS 10 qui les adapte et les insère dans des champs d'un paquet PPP. Au cours de l'étape F24, le DSLAM 7 détermine si le paquet PPP obtenu à l'issue de l'étape précédente est relatif à une session PPPoA ou PPPoE. Si le paquet PPP est relatif à une session PPPoA, le DSLAM exécute alors l'étape F25, au cours de laquelle le paquet PPP reçu est mis en conformité avec le protocole PPPoA. Le paquet PPP ainsi obtenu est ensuite transmis au client PPP 1.

La figure 7 représente un diagramme des échanges protocolaires effectués lors de l'établissement d'une session conforme à une variante du protocole PPP dite PPPoA (Point-to-Point Protocol over ATM). Lorsque le client PPP 1 souhaite se connecter à un service, l'établissement d'une session PPP débute par l'envoi par le PPP 1 ~:`,, quête LCPConfigRequest.

A la réception de ce message le serveur RAS 10 peut répondre positivement au client PPP 1 par l'envoi d'un message LCPConfigAck et simultanément une requête DHCPDISCOVER est émise par le client DHCP 60 vers le serveur DHCP 6. Cette requête DHCPDISCOVER permet de localiser un serveur DHCP 6 disponible. Celui-ci répond à la requête par l'émission d'un message DHCPOFFER dans lequel il soumet une adresse IP au client DHCP 60. Le client DHCP 60 émet alors une requête DHCPREQUEST dans laquelle il demande des paramètres de configuration. Le serveur DHCP 6 répond positivement par un message DHCPACK ou négativement par un message DHCPNACK. Si le serveur DHCP 6 répond positivement à la requête DHCPREQUEST, sa réponse inclut les différents paramètres réseau nécessaires à la configuration du client tels l'adresse IP, les adresses des serveurs DNS, etc. Ces paramètres sont mémorisés par le client DHCP 60. En parallèle, une fois que le client PPP 1 a reçu une réponse positive LCPConfigAck, il émet une requête NCPConfigRequest vers le serveur RAS 10 de manière à obtenir ses paramètres de configuration. Si le message reçu par le client DHCP 60 est un message DHCPACK, le serveur RAS 10 répond au dernier message NCPConfigRequest qu'il a reçu du client PPP 1 par un message NCPConfigAck incluant les paramètres réseaux qu'il a reçus et mémorisés au préalable. Si le message reçu par le client DHCP 60 est un message DHCPNACK, le serveur RAS 10 répond négativement au client PPP 1 par l'envoi d'un message NCP ConfigNack. Une fois que le client PPP 1 a obtenu ses paramètres de configuration, 25 une session est établie entre le client PPP 1 et le serveur DHCP 6. Le DSLAM 7 procède alors à l'extraction des paquets lP encapsulés dans les trames PPP et les transmet vers le réseau en y ajoutant par exemple un en-tête Ethernet et inversement dans le sens descendant en extrayant les entêtes Ethernet et en encapsulant les paquets IP dans des messages PPP à destination du client PPP 1.

La figure 8 représente un diagramme des échanges protocolaires effectués lors de l'établissement d'une session conforme à une autre variante du protocole PPP, dite PPPoE (Point-to-Point Protocol over Ethernet). Quand un client PPP 1 veut initier une session conforme au protocole PPPoE, il doit tout d'abord exécuter une phase dite de découverte afin d'identifier l'adresse Ethernet ou adresse MAC, qui est une adresse physique, de son vis à vis et définir un identificateur de session PPPoE. Alors que le protocole PPP définit une liaison point-à-point, la phase de découverte fonctionne sur un modèle client-serveur. La phase de découverte se déroule en quatre temps. Dans un premier temps, le client PPP 1 émet à destination du serveur RAS 10 un message PPPoEPADI. Ce message contient une information d'initialisation. Dans un deuxième temps le serveur RAS 10 répond au client PPP 1 par l'envoi d'un message PPPoEPADO contenant son adresse MAC. Dans un troisième temps, le client PPP 1 émet un message PPPoEPADR par lequel il adresse une demande d'ouverture de session conforme au protocole PPPoE dite session PPPoE au serveur RAS 10. Enfin, dans un quatrième temps, le serveur RAS 10 répond par un message PPPoEPADS dans lequel il confirme l'ouverture de la session PPPoE en fournissant au client PPP 1 un identificateur de session PPPoE. Les échanges LCP suivants sont identiques à ceux décrits en référencé à là figure 7 et permettent l'initïalisatipn d'une session PPP. Lors de la clôture de la session PPP par le serveur RAS 1Q un message PA~ l- (message de terminaison d'une session PPPoE) peut être émis par le s0rveur ~AS 1G vers le clieot PPP 1 au lieu d'un message LCPTerminateReqnest tel qu'utilisé dans ia variante de realisation décrite plus haut pour le protocole PPPoA. La figure 9 représente un diagramme des échanges protocolaires :M.Î.iJeni;nt d'une conforme sicue ~ ~~_ avec authentification du client PPP 1 cherchant à établir une session pour obtenir un service. Ce mode de réalisation est compatible avec les deux modes de réalisation précédemment décrits et qui concernent l'établissement de sessions conformément aux protocoles PPPoA et PPPoE.

Contrairement aux variantes de réalisation, décrites plus haut, on réalise ici une authentification du client PPP 1 avant de procéder à l'ouverture d'une session entre ledit client PPP 1 et le serveur DHCP 6. En effet, un protocole point à point tel que le protocole PPP supporte des opérations d'authentification préalablement à l'établissement d'une session.

Avant d'échanger des messages contenant des informations d'authentification, le client PPP 1 et le serveur RAS 10 échangent d'abord des messages au moyen de requêtes LCPConfigRequest afin de déterminer s'ils sont tous les deux aptes à mettre en oeuvre un même protocole d'authentification. Si tel n'est pas le cas, ils tentent alors d'établir une session PPP dans laquelle le client PPP 1 n'est pas authentifié. Deux protocoles d'authentifications sont principalement utilisés en vue d'établir une session PPP. Un premier protocole est le protocole PAP (Password Authentication Protocol pour protocole d'authentification par mot de passe) qui implémente l'utilisation d'un couple nom d'utilisateur/mot de passe qui est transmis sans cryptage. Sur demande du serveur RAS 10, qui remplit ici la fonction d'un authentificateur, le client PPP 1 répond en émettant un paquet contenant son couple nom d'utilisateur/mot de passe, le serveur RAS 10 valide l'information reçue et envoie un accusé de réception positif ou négatif dans le cas où l'information reçue ne serait pas validée. Un deuxième protocole est le protocole CHAP (Challenge Handshake Authentification Protocol, ou "protocole d'authentification par défi-réponse") qui implémente l'utilisation d'un couple nom d't;'e,a'',eur!mot de passe err utilisant un cryptage du mot de passe, afin de former un couple nom d'utilisateur/chaîne de caractères aléatoire, dite chaîne CHAP. Le serveur RAS 10, qui remplit ici aussi la fonction d'un authentificateur envoie un paquet contenant son couple nom d'utilisateur/chaîne CHAP au client PPP 1. A réception de ce paquet, le client PPP 1 transforme la chaîne CHAP reçue au moyen d'un algorithme de calcul en une clé CHAP secrète. ll envoie ensuite le résultat accompagné de son nom d'utilisateur à destination du serveur RAS 10 qui compare la clé CHAP secrète reçue avec sa propre copie de la clé CHAP secrète. Enfin, il envoie un accusé de réception indiquant le résultat positif ou négatif de la comparaison des deux clés CHAP secrètes.

Dans les réseaux actuels, les opérateurs en télécommunications utilisant le protocole PPP pour permettre l'accès aux services qu'ils proposent, mettent en oeuvre dans la plupart des cas un mécanisme d'authentification du client PPP 1. Dans l'exemple de réalisation décrit en référence à la figure 9, le protocole d'authentification utilisé est le protocole CHAP (Challenge Handshake Authentication Protocol). Comme décrit en référence à la figure 7, le client PPP 1 émet un message LCPConfigRequest à destination du serveur RAS 10, lequel répond par l'émission d'un message LCPConfigACK. Cet échange de message permet, en plus de fonctions classiques précédemment décrites, de s'assurer que le client PPP 1 et le serveur RAS 10 supportent le même protocole d'authentification. Si tel est le cas, le serveur RAS 10 envoie son nom et une chaîne aléatoire de caractères au moyen d'un message CHAPCHALLENGE vers le client PPP 1. A réception de ce message, le client PPP 1 transforme cette chaîne en une clé CHAP secrète. Le client PPP 1 envoie ensuite le résultat accompagné de son nom au moyen d'un message CHAPRESPONSE. Les moyens de conversion 8 extraient alors le couple nom --pur/ sot dei i: a r? s par le client PPP 1 au serveur RAS 10 et l'insèrent dans une option de DHCP retenue pour l'authentification, qui peut être l'option DHCP 61 qui contient des informations d'authentification du client. Dans ce mode de réalisation, le message DHCPDISCOVER n'est transmis par le client DHCP 60 qu'à l'arrivée du message CHAPRESPONSE émit par le client PPP 1. Le serveur DHCP 6, à la réception du message DHCPDISCOVER incluant l'option d'authentification et émis par le client DHCP 60, extrait le couple nom d'utilisateur/mot de passe du client PPP 1 et interroge une base de données, non représentée sur les figures, via un protocole d'échanges. Si le couple nom d'utilisateur/mot de passe est correct le serveur DHCP 6 répond positivement en émettant un message DHCPACK. Si le couple nom d'utilisateur/mot de passe est incorrect le serveur DHCP 6 répond négativement en émettant un message DHCPNACK. S'il émet un message DHCPACK, le serveur DHCP 6 inclut différents paramètres réseau nécessaires à la configuration du client PPP 1, comme une adresse IP ou des adresses de serveurs DNS, dans son message. Dans ce cas de figure, le serveur RAS 10 répond au dernier message CHAPRESPONSE qu'il a reçu du client PPP 1 par un message CHAPSUCCESS. Si le message reçu par le client DHCP 60 est un message DHCPNACK, 20 le serveur RAS 10 répond négativement au dernier CHAPRESPONSE qu'il a reçu du client PPP 1 par l'envoi d'un message CHAPFAILURE. Le serveur RAS 10 traite ensuite le message NCPConfigRequest comme décrit précédemment. La figure 10 présente le principe d'une fin de session PPP initiée par le 25 client PPP 1, quel que soit le protocole point-à-point utilisé, PPP, PPPoA ou PPPoE. Lorsque le client PPP 1 souhaite mettre un terme à une session PPP, un message LCPTerminateRequest est envoyé vers le serveur RAS 10. A la réception de ce message, le serveur RAS 10 envoie un message LCPTer minateAck vers le client PPP 1. Par~:;ll r ?sit, le client DHCP 60 émet un message DHCPRELEASE vers le serveur DHCP 6 afin de libérer l'adresse IP allouée au client PPP 1 pour la durée de sa session. Comme représenté sur la figure 11, le serveur RAS 10 conformément au document référencé RFC 1661 sait traiter des messages d'écho en direction du client PPP 1 ou répondre aux messages d'écho en provenance du client PPP 1. Ces messages permettent à un point de terminaison d'une session PPP, c'est-â-dire un client PPP ou serveur PPP, de savoir si son vis-a-vis est toujours connecté. En l'absence de réponse par le client PPP 1 à une ou plusieurs requête(s) d'écho initiée(s) par le serveur RAS 10, ce qui est le cas par exemple si le lien physique est déconnecté ou l'équipement embarquant le client PPP 1 est éteint, ce dernier doit clore la session PPP en émettant un message LCPTerminateRequest é destination du client PPP 1. Cette information est également relayée vers le client DHCP 60 pour qu'il émette une requête DHCPRELEASE vers le serveur DHCP 6 afin de libérer l'adresse IP allouée au client PPP 1 pour la durée de sa session.

Claims (12)

REVENDICATIONS

1. Procédé d'accès par un client à un service au travers d'un réseau, ledit client mettant en oeuvre un protocole de connexion de type point à point pour l'établissement d'une session d'accès audit service, dite session point à point, caractérisé en ce que ledit service met en oeuvre un protocole de fourniture dynamique d'au moins un paramètre de configuration, appelé protocole de configuration dynamique, pour l'établissement d'une session d'accès par ledit client, dite session conforme audit protocole de configuration dynamique, et en ce que ledit procédé comprend une étape de conversion de ladite session point à point en une session conforme audit protocole de configuration dynamique, mise en oeuvre dans un équipement intermédiaire dudit réseau.

2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de conversion comprend, sur réception d'un premier message d'établissement de ladite session point â point par ledit équipement intermédiaire, une étape d'émission d'au moins un deuxième message d'établissement de ladite session conforme audit protocole de configuration dynamique, ledit deuxième message d'établissement étant un message de fourniture etlou de requête d'au moins un paramètre de ladite session conforme audit protocole de configuration dynamique.

3. Procédé selon la revendication 2, caractérisé en ce que ladite étape de conversion comprend, sur réception desdits paramètres de ladite session conforme audit protocole de configuration dynamique en provenance dudit réseau, et/ou sur réception d'au moins un paramètre de ladite session point à point en provenance dudit client, une étape de mémorisation desdits paramètres dans ledit équipement intermédiaire.

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en a dite étape de conversion met en oeuvre: sur récept par ledit équipement intermédiaire d'un message selonledit protocole point à point, une étape d'extraction d'au moins un paramètre de la session point à point, encapsulé dans ledit message, et une étape de transfert dudit paramètre de la session point à point vers ledit réseau, conformément audit protocole de configuration dynamique; - sur réception par ledit équipement intermédiaire d'un message selon ledit protocole de configuration dynamique, une étape d'extraction d'au moins un paramètre de la session conforme au protocole de configuration dynamique, encapsulé dans ledit message, et une étape de transfert dudit paramètre de la session conforme au protocole de configuration dynamique vers ledit client, conformément audit protocole point à point.

5. Procédé selon la revendication 4, caractérisé en ce que lesdits paramètres transférés appartiennent au groupe comprenant: au moins une donnée d'authentification dudit client; au moins une donnée d'identification d'une ligne de connexion dudit client audit réseau; - au moins un paramètre de configuration.

6. Procédé selon la revendication 2, caractérisé en ce que ladite étape de conversion comprend, sur réception d'un message d'absence de fourniture desdits paramètres de ladite session conforme audit protocole de configuration dynamique en provenance dudit réseau, une étape de transmission par ledit équipement intermédiaire audit client d'un message d'absence d'acquittement de configuration selon ledit protocole de transport point à point.

7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite étape de conversion comprend, en cas de détection d'une fin de session point à point, respectivement d'une fin de session selon ledit protocole de configuration dynamique, une étape de transmission d'un message de libération desdits paramètres de configuration selon ledit protocole de configuration dynamique vers ledit réseau, respectivement d'un message de fin de session point à point vers ledit client.

8. Programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par un processeur.

9. Système d'accès à un service par un client au travers d'un réseau, ledit client mettant en oeuvre un protocole de connexion de type point à point pour rétablissement d'une session d'accès audit service, dite session point à point, caractérisé en ce que ledit service met en oeuvre un protocole de fourniture dynamique d'au moins un paramètre de configuration, appelé protocole de configuration dynamique, pour l'établissement d'une session d'accès par ledit client, dite session conforme audit protocole de configuration dynamique, et en ce que ledit système comprend, dans un équipement intermédiaire dudit réseau, des moyens de conversion de ladite session point à point en une session d'accès audit service conforme audit protocole de configuration dynamique.

10. Equipement intermédiaire d'un réseau permettant l'accès par un client à un service, ledit client mettant en oeuvre un protocole de connexion de type point à point pour l'établissement d'une session d'accès audit service, dite session point à point, caractérisé en ce que, ledit service mettant en oeuvre un protocole de fourniture dynamique d'au moins un paramètre de configuration, appelé protocole de configuration dynamique, pour rétablissement d'une session d'accès par ledit client, dite session conforme audit protocole de configuration dynamique, ledit équipement intermédiaire comprend des moyens de conversion de ladite session point à point en une session d'accès audit service conforme audit protocole de configuration dynamique.

11. Equipement intermédiaire selon la revendication 10, caractérisé en ce que ledit équipement est un noeud d'accès dudit client audit réseau.

12. Equipement intermédiaire selon l'une quelconque des revendications 10 et 11, caractérisé en ce que lesdits moyens de conversion comprennent: un serveur mettant en oeuvre ledit protocole point à point; un client mettant en oeuvre ledit protocole de configuration dynamique; des moyens d'interaction entre lesdits serveur et client.