Architecture de référence PPPoA

Introduction

Ce document décrit une architecture de ligne d'abonné numérique à débit asymétrique (ADSL) de bout en bout qui utilise le protocole Point à point en mode de transfert asynchrone (PPPoA). Bien que la plupart des déploiements soient basés sur l'architecture de pontage, le protocole PPPoA gagne en popularité et formera une plus grande partie des futurs déploiements ADSL.

Hypothèse

L'architecture de base suppose la nécessité de fournir un accès Internet haut débit et un accès d'entreprise à l'abonné final à l'aide de PPPoA en tant que réseau fédérateur principal. Nous aborderons cette architecture basée sur des canaux virtuels privés (PVC), la méthode la plus souvent utilisée dans les déploiements actuels. L'architecture utilisant des circuits virtuels commutés (SVC) sera traitée dans un document distinct.

Ce document est basé sur les déploiements existants ainsi que sur les tests internes de l'architecture.

Ce document a été rédigé en supposant que le lecteur connaît bien les considérations de conception d'un fournisseur d'accès réseau (NAP) telles que décrites dans le livre blanc RFC1483 Bridging Baseline Architecture.

Présentation technologique

Le protocole PPP (Point-to-Point Protocol) (RFC 1331) fournit une méthode standard d’encapsulation des protocoles de couche supérieure sur des connexions point à point. Il étend la structure de paquets HDLC (High-Level Data Link Control) à un identificateur de protocole de 16 bits qui contient des informations sur le contenu du paquet.

Le paquet contient trois types d'informations :

• Protocole LCP (Link Control Protocol) : négocie les paramètres de liaison, la taille de paquet ou le type d'authentification

• Network Control Protocol (NCP) : contient des informations sur les protocoles de couche supérieure, notamment IP et IPX, et leurs protocoles de contrôle (IPCP pour IP).

• Trames de données contenant des données

Le protocole d’adaptation PPP sur ATM de couche 5 (AAL5) (RFC 2364) utilise AAL5 comme protocole tramé, qui prend en charge les circuits virtuels permanents et les circuits virtuels commutés. PPPoA a été principalement mis en oeuvre dans le cadre de l'ADSL. Il s'appuie sur le RFC1483, fonctionnant en mode LLC-SNAP (Logical Link Control-Subnetwork Access Protocol) ou VC-Mux. Un équipement client (CPE) encapsule la session PPP basée sur cette RFC pour le transport sur la boucle ADSL et le multiplexeur d'accès DSLAM (Digital Subscriber Line Access Multier).

Avantages et inconvénients de l'architecture PPPoA

L'architecture PPPoA hérite de la plupart des avantages du protocole PPP utilisé dans le modèle de numérotation. Certains des points clés sont énumérés ci-dessous.

Avantages

• Authentification par session basée sur le protocole PAP (Password Authentication Protocol) ou le protocole CHAP (Challenge Handshake Authentication Protocol). Il s’agit du plus grand avantage de PPPoA, car l’authentification surmonte le trou de sécurité dans une architecture de pontage.

• La comptabilité par session est possible, ce qui permet au fournisseur de services de facturer l'abonné en fonction du temps de session pour les différents services offerts. La comptabilité par session permet à un fournisseur de services d'offrir un niveau d'accès minimal pour des frais minimes, puis de facturer les abonnés pour les services supplémentaires utilisés.

• Conservation des adresses IP au niveau du CPE. Cela permet au fournisseur de services d'attribuer une seule adresse IP à un CPE, le CPE étant configuré pour la traduction d'adresses réseau (NAT). Tous les utilisateurs derrière un CPE peuvent utiliser une seule adresse IP pour atteindre différentes destinations. La surcharge de gestion IP pour le fournisseur d'accès réseau/fournisseur de services réseau (NAP/NSP) pour chaque utilisateur individuel est réduite tout en conservant les adresses IP. En outre, le fournisseur de services peut fournir un petit sous-réseau d’adresses IP pour surmonter les limites de la traduction d’adresses de port (PAT) et de la NAT.

• Les NAP/NSP fournissent un accès sécurisé aux passerelles d'entreprise sans gérer les circuits virtuels permanents de bout en bout et en utilisant le routage de couche 3 ou les tunnels L2F/L2TP (Layer 2 Forwarding/Layer 2 Tunneling Protocol). Ils peuvent donc adapter leurs modèles commerciaux à la vente de services de gros.

• Dépannage des abonnés individuels. Le NSP peut facilement identifier les abonnés actifs ou non en fonction des sessions PPP actives, plutôt que de dépanner des groupes entiers comme c'est le cas avec l'architecture de pontage.

• Le NSP peut se surinscrire en déployant des délais d'inactivité et de session à l'aide d'un serveur RADIUS (Remote Authentication Dial-In User Service) standard pour chaque abonné.

• Très évolutif car nous pouvons terminer un nombre très élevé de sessions PPP sur un routeur d’agrégation. L'authentification, l'autorisation et la comptabilité peuvent être gérées pour chaque utilisateur à l'aide de serveurs RADIUS externes.

• Utilisation optimale des fonctionnalités de la passerelle de sélection de service (SSG).

Inconvénients

• Une seule session par CPE sur un canal virtuel (VC). Puisque le nom d’utilisateur et le mot de passe sont configurés sur l’équipement d’abonné, tous les utilisateurs derrière l’équipement d’abonné pour ce circuit virtuel particulier ne peuvent accéder qu’à un seul ensemble de services . Les utilisateurs ne peuvent pas sélectionner différents ensembles de services, bien qu'il soit possible d'utiliser plusieurs circuits virtuels et d'établir différentes sessions PPP sur différents circuits virtuels.

• Complexité accrue de la configuration du CPE. Le personnel du centre d'assistance du fournisseur de services doit être mieux informé. Puisque le nom d'utilisateur et le mot de passe sont configurés sur l'équipement d'abonné, l'abonné ou le fournisseur de l'équipement d'abonné devra apporter des modifications à la configuration. L'utilisation de plusieurs circuits virtuels augmente la complexité de la configuration. Cependant, il est possible d'y remédier par une fonctionnalité de configuration automatique qui n'est pas encore disponible.

• Le fournisseur de services doit tenir à jour une base de données de noms d'utilisateur et de mots de passe pour tous les abonnés. Si des tunnels ou des services proxy sont utilisés, l'authentification peut être effectuée sur la base du nom de domaine et l'authentification de l'utilisateur est effectuée sur la passerelle d'entreprise. Cela réduit la taille de la base de données que le fournisseur de services doit gérer.

• Si une adresse IP unique est fournie au CPE et que la NAT/PAT est implémentée, certaines applications telles que IPTV, qui incorporent des informations IP dans la charge utile, ne fonctionneront pas. En outre, si une fonction de sous-réseau IP est utilisée, une adresse IP doit également être réservée pour l’équipement d’abonné.

Considérations relatives à la mise en oeuvre de l'architecture PPPoA

Les points clés à prendre en compte avant de mettre en oeuvre l'architecture PPPoA sont les suivants :

• Nombre d'abonnés qui seront traités actuellement et ultérieurement, car cela affecte le nombre de sessions PPP requises.

• Indique si les sessions PPP sont terminées au niveau du routeur d'agrégation du fournisseur de services ou transmises à d'autres passerelles d'entreprise ou fournisseurs de services Internet (FAI).

• Si le fournisseur de services ou la destination finale du service fournit l'adresse IP à l'équipement d'abonné.

• Si les adresses IP fournies sont publiques ou privées. Le CPE va-t-il effectuer la NAT/PAT ou la NAT sera-t-elle exécutée à la destination de terminaison ?

• Profils des abonnés finaux, des utilisateurs résidentiels, des clients des petits bureaux à domicile (SOHO) et des télétravailleurs.

• Dans le cas de plusieurs utilisateurs, que tous les utilisateurs aient besoin d'atteindre la même destination ou le même service final, ou qu'ils aient tous des destinations de service différentes.

• Le fournisseur de services fournit-il des services à valeur ajoutée tels que la voix ou la vidéo ? Le fournisseur de services exige-t-il que tous les abonnés accèdent d'abord à un réseau particulier avant d'atteindre une destination finale ? Lorsque les abonnés utilisent SSG, vont-ils utiliser des services passthrough, PTA (PPP Terminated Aggregation), un périphérique de médiation ou un proxy ?

• Facturation des abonnés par le fournisseur de services, en fonction d'un taux fixe, de l'utilisation par session ou des services utilisés.

• Déploiement et mise en service des CPE, des DSLAM et des points de présence d'agrégation (POP).

• Le modèle d'entreprise du PAN. Le modèle inclut-il également la vente de services de gros tels que l'accès sécurisé à l'entreprise et les services à valeur ajoutée tels que la voix et la vidéo ? Les PNA et les PNS sont-ils la même entité ?

• Le modèle commercial de l'entreprise. Est-il comparable à un opérateur de services locaux indépendant (ESLT), à un opérateur de services locaux concurrentiel (ESLC) ou à un FAI?

• Types d'applications que le NSP offrira à l'abonné final.

• Volume de flux de données prévu en amont et en aval.

En gardant ces points à l'esprit, nous discuterons de la manière dont l'architecture PPPoA s'adaptera et s'adaptera à différents modèles commerciaux pour les fournisseurs de services et de la manière dont ces derniers peuvent en tirer parti.

Architecture réseau PPPoA typique

Le schéma suivant présente une architecture réseau PPPoA typique. Les clients utilisant des CPE se connectent au réseau du fournisseur de services via un DSLAM Cisco, qui se connecte à un agrégateur Cisco 6400 à l'aide d'ATM.

Considérations de conception pour l'architecture PPPoA

Dans la section « Considérations relatives à la mise en oeuvre » de ce document, les architectures PPPoA peuvent être déployées selon différents scénarios selon le modèle commercial du fournisseur de services. Dans cette section, nous aborderons les différentes possibilités et considérations que les fournisseurs de services doivent garder à l'esprit avant de déployer une solution.

Avant de déployer une architecture PPPoA et une solution particulière pour cette architecture, il est essentiel de comprendre le modèle commercial du fournisseur de services. Prenez en compte les services que le fournisseur de services proposera. Le fournisseur de services proposera-t-il un seul service, comme l'accès Internet haut débit à ses abonnés finaux, ou vendra-t-il des services de gros à différents FAI et fournira-t-il des services à valeur ajoutée à ces abonnés ? Le fournisseur de services les offrira-t-il tous ?

Dans le cas d'un accès Internet haut débit dans un environnement où NSP et NAP sont identiques, les sessions PPP de l'abonné doivent être interrompues dans le routeur d'agrégation déployé. Dans ce scénario, les fournisseurs de services doivent tenir compte du nombre de sessions PPP pouvant être interrompues sur un seul périphérique d'agrégation de routeur, de la manière dont les utilisateurs seront authentifiés, de la manière dont ils vont effectuer la comptabilité et du chemin vers Internet une fois les sessions utilisateur terminées. Selon le nombre de sessions et d’abonnés PPP, le routeur d’agrégation peut être un Cisco 6400 ou un Cisco 7200. Aujourd'hui, le Cisco 6400 avec 7 NRP (Node Route Procsers) peut terminer jusqu'à 14 000 sessions PPP. Le Cisco 7200 est limité à 2 000 sessions PPP. Ces numéros changeront avec les nouvelles versions. Consultez les notes de version et les documents produit pour connaître le nombre exact de sessions que chaque routeur d'agrégation peut prendre en charge.

Dans ce scénario, l'authentification et la comptabilisation des utilisateurs sont mieux gérées à l'aide d'un serveur RADIUS standard du secteur, qui peut authentifier un utilisateur en fonction de son nom d'utilisateur ou de l'identificateur de chemin virtuel/identificateur de canal virtuel (VPI/VCI) utilisé.

Pour l'accès Internet haut débit, les NSP facturent généralement aux clients un tarif forfaitaire. La plupart des déploiements actuels sont mis en oeuvre de cette manière. Lorsque NSP et NAP sont la même entité, les clients sont facturés à un tarif fixe pour l'accès et à un autre tarif fixe pour l'accès à Internet. Ce modèle change lorsque le fournisseur de services commence à offrir des services à valeur ajoutée. Les fournisseurs de services peuvent facturer le client en fonction du type de service et de la durée d'utilisation du service. Les clients se connectent à Internet via le routeur d'agrégation à l'aide de protocoles de routage tels que OSPF (Open Shortest Path First) ou EIGRP (Enhanced Interior Gateway Routing Protocol) à un routeur de périphérie qui pourrait exécuter le protocole BGP (Border Gateway Protocol).

Le fournisseur de services peut également fournir un accès Internet haut débit en transférant les sessions PPP entrantes des abonnés à un FAI distinct à l'aide de la tunnellisation L2TP/L2F. Lorsque le tunneling L2x est utilisé, il convient d'accorder une attention particulière à la manière dont la destination du tunnel peut être atteinte. Les options disponibles consistent à exécuter certains protocoles de routage ou à fournir des routes statiques dans le routeur d’agrégation. Les restrictions relatives à l'utilisation de tunnels L2TP ou L2F sont les suivantes : 1) le nombre de tunnels et le nombre de sessions pouvant être prises en charge dans ces tunnels ; et (2) l’utilisation de protocoles de routage incompatibles avec des FAI tiers, qui peuvent nécessiter l’utilisation de routes statiques.

Si le fournisseur de services propose des services à différents FAI ou passerelles d'entreprise à l'abonné final, il peut être nécessaire de mettre en oeuvre des fonctionnalités SSG sur le routeur d'agrégation. Cela permet à l'abonné de sélectionner différentes destinations de service à l'aide de la sélection de service basée sur le Web. Le fournisseur de services peut transférer les sessions PPP des abonnés vers leurs destinations sélectionnées en combinant toutes les sessions destinées au FAI en un seul circuit virtuel permanent pour le transport, ou si le fournisseur de services offre plusieurs niveaux de service, plusieurs circuits virtuels permanents peuvent être établis sur l'ensemble du coeur de réseau.

Dans un modèle de service de gros, le fournisseur de services ne peut pas utiliser les fonctionnalités SSG. Dans ce modèle, le fournisseur de services étend toutes les sessions PPP aux passerelles domestiques. Les passerelles domestiques fournissent des adresses IP à l'abonné final et authentifient l'utilisateur final.

Dans tous ces scénarios, il est important de déterminer comment le fournisseur de services peut offrir une qualité de service (QoS) différente pour différents services et comment il calcule l'allocation de bande passante. Actuellement, la manière dont la plupart des fournisseurs de services déploient cette architecture offre différentes qualités de services sur différents circuits virtuels permanents. Ils peuvent avoir des circuits virtuels permanents distincts sur le coeur de réseau pour les clients résidentiels et professionnels. L'utilisation de circuits virtuels permanents différents permet aux fournisseurs de services de spécifier une QoS différente pour différents services. De cette manière, la QoS peut être sur des circuits virtuels permanents distincts ou au niveau de la couche 3.

L’application de la QoS au niveau de la couche 3 nécessite que le fournisseur de services connaisse la destination finale, ce qui pourrait être un facteur limitatif. Mais, si elle est utilisée en combinaison avec la QoS de couche 2 (en l'appliquant sur différents circuits virtuels), elle peut être utile pour le fournisseur de services. La limite avec ce modèle est qu'il est fixe et que le fournisseur de services doit prévoir la QoS à l'avance. La qualité de service n'est pas appliquée de manière dynamique lors de la sélection du service. Actuellement, il n'existe aucune option permettant à un utilisateur de sélectionner différentes bandes passantes pour différents services en un clic de souris ; cependant, des efforts considérables ont été investis pour développer cette fonctionnalité.

Le déploiement, la gestion et le provisionnement des CPE peuvent être très difficiles dans cette architecture, car le CPE doit être configuré pour les noms d'utilisateur et les mots de passe. En guise de solution simple, certains fournisseurs de services utilisent le même nom d’utilisateur et le même mot de passe pour tous les CPE. Cela présente un risque important pour la sécurité. En outre, si le CPE doit ouvrir simultanément différentes sessions, des circuits virtuels supplémentaires doivent être provisionnés au CPE, au NAP et au NSP. Les DSLAM et les périphériques d’agrégation Cisco peuvent simplifier la configuration et le provisionnement des équipements CPE. Des outils de gestion de flux sont également disponibles pour le provisionnement de bout en bout des circuits virtuels permanents. Le provisionnement au niveau du NSP pour tant d'abonnés utilisant des circuits virtuels permanents est un facteur limitatif, car tous les différents circuits virtuels permanents doivent être gérés. En outre, il n'existe aucun moyen simple de provisionner les PVC 2000 sur un seul NRP en cliquant sur une souris ou en saisissant quelques touches.

Aujourd'hui, nous disposons de différentes applications de gestion pour différents composants de cette architecture, comme Viewrunner pour la DSLAM et SCM pour le Cisco 6400. Il n'existe pas de plate-forme de gestion unique qui approvisionne tous les composants. Il s'agit d'une limitation bien reconnue et un effort considérable est déployé pour disposer d'une application de gestion unique et complète permettant de provisionner le CPE, la DSLAM et le Cisco 6400. En outre, nous disposons actuellement d'une solution permettant de mettre en oeuvre PPPoA avec SVC, ce qui facilitera grandement le déploiement. PPPoA avec SVC permet également aux utilisateurs finaux de sélectionner la destination et la qualité de service de manière dynamique.

Un autre point important à garder à l'esprit pour les déploiements ADSL de grande envergure utilisant cette architecture est la communication entre le routeur d'agrégation et le serveur RADIUS. Si la lame NRP échoue lorsque plusieurs milliers de sessions PPP sont terminées sur un périphérique d'agrégation, toutes ces sessions PPP doivent être rétablies. Cela signifie que tous les abonnés doivent être authentifiés et leurs enregistrements comptables arrêtés et redémarrés une fois la connexion établie. Lorsque tant d'abonnés tentent d'être authentifiés en même temps, le canal vers le serveur RADIUS peut constituer un goulot d'étranglement. Il se peut que certains abonnés ne puissent pas être authentifiés, ce qui peut créer des problèmes pour le fournisseur de services.

Il est très important d'avoir une liaison au serveur RADIUS avec suffisamment de bande passante pour accueillir tous les abonnés en même temps. En outre, le serveur RADIUS doit être suffisamment puissant pour accorder des autorisations à tous les abonnés. Dans le cas de milliers d'abonnés, une option d'équilibrage de charge entre les serveurs RADIUS disponibles doit être envisagée. Cette fonctionnalité est disponible dans le logiciel Cisco IOS®.

En dernier lieu, le routeur d’agrégation doit fonctionner suffisamment pour accueillir de nombreuses sessions PPP. Appliquez les mêmes principes d'ingénierie de trafic que ceux utilisés par d'autres implémentations. Auparavant, l'utilisateur devait configurer des circuits virtuels permanents sur des sous-interfaces point à point. Aujourd'hui, le protocole PPPoA permet aux utilisateurs de configurer plusieurs circuits virtuels permanents sur des sous-interfaces multipoints et point à point. Chaque connexion PPPoA ne nécessite plus deux blocs de descripteurs d’interface (IDB), l’un pour l’interface d’accès virtuel et l’autre pour la sous-interface ATM. Cette amélioration augmente le nombre maximal de sessions PPPoA exécutées sur un routeur.

Le nombre maximal de sessions PPPoA prises en charge sur une plate-forme dépend des ressources système disponibles telles que la mémoire et la vitesse du processeur. Chaque session PPPoA prend une interface d'accès virtuelle. Chaque interface d'accès virtuel se compose d'un bloc de descripteurs d'interface matérielle et d'une paire de descripteurs d'interface logicielle (hwidb/swidb). Chaque largeur de bande prend environ 4,5 K. Chaque lame prend environ 2,5 K. Ensemble, les interfaces d'accès virtuel nécessitent 7,5 K. 2000 interfaces d'accès virtuel nécessitent 2000 * 7,5 000 ou 15 000 Mo. Pour exécuter 2000 sessions, un routeur a besoin de 15 millions supplémentaires. En raison de l’augmentation de la limite de session, le routeur doit prendre en charge davantage d’IDB. Cette prise en charge a un impact sur les performances en raison d'un plus grand nombre de cycles CPU pour exécuter plus d'instances de la machine d'état PPP.

Points clés de l'architecture PPPoA

Cette section décrit trois points clés de l'architecture PPPoA : le CPE, la gestion IP et l'accès à la destination du service.

En raison de la nature de la PAT, certaines applications qui incorporent des informations IP dans la charge utile ne peuvent pas fonctionner dans ce scénario. Pour résoudre ce problème, appliquez un sous-réseau d’adresses IP plutôt qu’une seule adresse IP.

Dans cette architecture, il est plus facile pour le NAP/NSP de se connecter par Telnet au CPE pour configurer et dépanner, car une adresse IP est attribuée au CPE.

Les CPE peuvent utiliser différentes options en fonction du profil de l'abonné. Par exemple, pour un utilisateur résidentiel, le CPE peut être configuré sans PAT/DHCP. Pour les abonnés avec plusieurs PC, les CPE peuvent être configurés soit pour PAT/DHCP, soit de la même manière que pour un utilisateur résidentiel. Si un téléphone IP est connecté au CPE, le CPE peut être configuré pour plusieurs circuits virtuels permanents.

Gestion IP

Dans l'architecture PPPoA, l'allocation d'adresses IP pour l'abonné CPE utilise la négociation IPCP, le même principe de PPP en mode de numérotation. Les adresses IP sont attribuées en fonction du type de service utilisé par un abonné. Si l'abonné n'a qu'un accès Internet depuis le NSP, le NSP mettra fin à ces sessions PPP de l'abonné et lui attribuera une adresse IP. L'adresse IP est attribuée à partir d'un pool défini localement, d'un serveur DHCP ou peut être appliquée à partir du serveur RADIUS. En outre, le FAI peut avoir fourni un ensemble d'adresses IP statiques à l'abonné et ne peut pas attribuer d'adresses IP de manière dynamique lorsque l'abonné initie la session PPP. Dans ce scénario, le fournisseur de services utilise uniquement le serveur RADIUS pour authentifier l'utilisateur.

Si l'abonné préfère disposer de plusieurs services, il se peut que le NSP doive implémenter SSG. Vous trouverez ci-dessous les possibilités d’attribution d’adresses IP.

• Le SP peut fournir une adresse IP à l'abonné via son pool local ou son serveur RADIUS. Une fois que l'utilisateur a sélectionné un service, le SSG transfère le trafic de l'utilisateur vers cette destination. Si le SSG utilise le mode proxy, la destination finale peut fournir une adresse IP, que le SSG utilisera comme adresse visible pour NAT.

• Les sessions PPP ne sont pas terminées sur le routeur d'agrégation du fournisseur de services. Ils sont soit tunnellisés, soit transférés vers la destination finale ou la passerelle domestique, ce qui finira par mettre fin aux sessions PPP. La destination finale ou la passerelle principale négocie le protocole IPCP avec l'abonné, fournissant ainsi une adresse IP dynamiquement. Les adresses statiques sont également possibles tant que la destination finale a attribué ces adresses IP et a une route vers elles.

Avant la version 12.0.5DC du logiciel Cisco IOS pour le NRP Cisco 6400, il n'y avait aucun moyen pour le fournisseur de services de fournir un sous-réseau d'adresses IP à l'abonné. La plate-forme Cisco 6400 et les CPE de la gamme Cisco 600 permettent de configurer dynamiquement des sous-réseaux IP sur le CPE lors de la négociation PPP. Une adresse IP de ce sous-réseau est attribuée au CPE et les adresses IP restantes sont attribuées dynamiquement aux stations via DHCP. Lorsque cette fonctionnalité est utilisée, les CPE n'ont pas besoin d'être configurés pour PAT, qui ne fonctionne pas avec certaines applications.

Comment la destination du service est atteinte

Dans les architectures PPPoA, la destination du service peut être atteinte de différentes manières. Voici quelques-unes des méthodes les plus couramment utilisées :

• Fermeture des sessions PPP chez le fournisseur de services

• Tunnellisation L2TP

• Utilisation de SSG

Dans les trois méthodes, il existe un ensemble fixe de circuits virtuels permanents défini du CPE au DSLAM, qui est commuté en un ensemble fixe de circuits virtuels permanents sur le routeur d’agrégation. Les circuits virtuels permanents sont mappés du DSLAM au routeur d’agrégation via un nuage ATM.

La destination du service peut également être atteinte à l'aide d'autres méthodes telles que PPPoA avec des circuits virtuels commutés ou Multiprotocol Label Switching/Virtual Private Network. Ces méthodes ne relèvent pas du présent document et seront examinées dans des documents distincts.

Terminaison du protocole PPP au niveau de l'agrégation

Les sessions PPP initiées par l'abonné sont terminées chez le fournisseur de services qui authentifie les utilisateurs à l'aide d'une base de données locale sur le routeur ou via des serveurs RADIUS. Une fois l'utilisateur authentifié, la négociation IPCP a lieu et l'adresse IP est attribuée au CPE. Une fois l’adresse IP attribuée, une route hôte est établie à la fois sur l’équipement d’abonné et sur le routeur d’agrégation. Les adresses IP attribuées à l'abonné, si elles sont légales, sont annoncées au routeur de périphérie. Le routeur de périphérie est la passerelle par laquelle l'abonné peut accéder à Internet. Si les adresses IP sont privées, le fournisseur de services les traduit avant de les annoncer au routeur de périphérie.

Tunnellisation L2TP/L2F

Les sessions PPP, en fonction du fournisseur de services ou de la société, passent en tunnel jusqu'au point de terminaison en amont à l'aide de L2TP ou L2F au lieu d'être terminées sur le routeur d'agrégation du fournisseur de services. Ce point de terminaison authentifie le nom d'utilisateur et l'abonné reçoit une adresse IP via DHCP ou un pool local. Pour ce scénario, il existe généralement un tunnel établi entre le concentrateur d'accès L2TP/serveur d'accès réseau (LAC/NAS) et la passerelle domestique ou le serveur de réseau L2TP (LNS). Le LAC authentifie la session entrante en fonction du nom de domaine ; le nom d'utilisateur est authentifié à la destination finale ou à la passerelle d'accueil.

Dans ce modèle, cependant, l'utilisateur ne peut avoir accès qu'à la destination finale et n'avoir accès qu'à une seule destination à la fois. Par exemple, si le CPE est configuré avec un nom d'utilisateur rtr@cisco.com, les PC derrière ce CPE peuvent uniquement avoir accès au domaine Cisco. S'ils veulent se connecter à un autre réseau d'entreprise, ils doivent modifier le nom d'utilisateur et le mot de passe sur le CPE pour refléter ce nom de domaine d'entreprise. Dans ce cas, la destination du tunnel est atteinte à l’aide d’un protocole de routage, de routes statiques ou d’un protocole IP classique sur ATM (si l’ATM est préféré comme couche 2).

Utilisation de la passerelle de sélection de service (SSG)

Le principal avantage de SSG par rapport au tunneling est que SSG fournit le mappage de services un à plusieurs, alors que le tunneling ne fournit que le mappage un à un. Cela devient très utile lorsqu'un utilisateur unique a besoin d'accéder à plusieurs services ou que plusieurs utilisateurs à un même emplacement ont besoin d'accéder à un service unique. SSG utilise le tableau de bord Web de sélection de services (SSD), qui se compose de différents services et est disponible pour l'utilisateur. L'utilisateur peut accéder simultanément à un ou plusieurs services. Un autre avantage de l'utilisation de SSG est que le fournisseur de services peut facturer l'utilisateur en fonction des services utilisés et de la durée de session, et que l'utilisateur peut activer et désactiver les services via le SSD.

Les utilisateurs sont authentifiés lorsque la session PPP arrive des abonnés. Les adresses IP sont attribuées aux utilisateurs à partir du pool local ou du serveur RADIUS. Une fois qu'un utilisateur est authentifié, un objet source est créé par le code SSG et l'utilisateur a accès à un réseau par défaut. Le réseau par défaut contient le serveur SSD. À l'aide d'un navigateur, l'utilisateur se connecte au tableau de bord, est authentifié par le serveur AAA et, en fonction du profil de l'utilisateur stocké dans le serveur RADIUS, un ensemble de services est proposé pour y accéder.

Chaque fois qu'un utilisateur authentifié sélectionne un service, le SSG crée un objet de destination pour cet utilisateur. L'objet de destination contient des informations telles que l'adresse de destination, l'adresse du serveur DNS pour cette destination et l'adresse IP source attribuée à partir de la passerelle domestique. Les paquets provenant du côté de l'utilisateur sont transférés vers la destination en fonction des informations contenues dans l'objet de destination.

SSG peut être configuré pour le service proxy, le transfert transparent ou PTA. Lorsqu'un abonné demande l'accès à un service proxy, le NRP-SSG transmet la demande d'accès au serveur RADIUS distant. Dès réception de l'acceptation d'accès, le SSG répond à l'abonné avec l'acceptation d'accès. Le SSG apparaît en tant que client du serveur RADIUS distant.

Le passage transparent permet au trafic d'abonnés non authentifiés d'être acheminé via le SSG dans l'une ou l'autre direction. Utilisez des filtres pour contrôler le trafic transparent.

PTA ne peut être utilisé que par des utilisateurs de type PPP. L'authentification, l'autorisation et la comptabilité sont effectuées exactement comme dans le type de service proxy. Un abonné se connecte à un service à l'aide d'un nom d'utilisateur du formulaire user@service. Le SSG le transfère au serveur RADIUS, qui charge ensuite le profil de service dans le SSG. Le SSG transfère la requête au serveur RADIUS distant, comme spécifié par l'attribut serveur RADIUS du profil de service. Une fois la demande authentifiée, une adresse IP est attribuée à l'abonné. Aucune NAT n'est effectuée. Tout le trafic utilisateur est agrégé sur le réseau distant. Avec PTA, les utilisateurs ne peuvent accéder qu'à un seul service et n'ont pas accès au réseau par défaut ou au SSD.

Description opérationnelle de l'architecture PPPoA

Lorsque le CPE est mis sous tension pour la première fois, il commence à envoyer des requêtes de configuration LCP au serveur d'agrégation. Le serveur d'agrégation, avec les circuits virtuels permanents configurés, envoie également la demande de configuration LCP sur une interface d'accès virtuel (associée au circuit virtuel permanent). Lorsque chacun voit la requête de configuration de l’autre, il accuse réception des requêtes et l’état LCP est ouvert.

Pour l’étape d’authentification, le CPE envoie la demande d’authentification au serveur d’agrégation. Selon sa configuration, le serveur authentifie l'utilisateur en fonction du nom de domaine (s'il est fourni) ou du nom d'utilisateur à l'aide de sa base de données locale ou de ses serveurs RADIUS. Si la demande de l'abonné est présentée sous la forme username@domainname, le serveur d'agrégation tentera de créer un tunnel vers la destination, s'il n'y en a pas déjà. Une fois le tunnel créé, le serveur d'agrégation transfère les requêtes PPP de l'abonné à la destination. La destination, à son tour, authentifie l'utilisateur et attribue une adresse IP. Si la demande de l'abonné n'inclut pas le nom de domaine, l'utilisateur est authentifié par la base de données locale. Si SSG est configuré sur le routeur d'agrégation, l'utilisateur peut accéder au réseau par défaut comme spécifié et peut obtenir une option pour sélectionner différents services.

Conclusion

PPPoA devient l'architecture la plus appropriée pour de nombreux fournisseurs de services, car elle est hautement évolutive, utilise des fonctionnalités SSG et assure la sécurité. Étant donné que l'architecture PPPoA était au centre de ce document, il n'a pas été possible de couvrir en profondeur des fonctionnalités telles que SSG. Ces fonctions seront abordées dans les documents suivants. Des exemples de configuration pour les différents scénarios abordés dans ce document seront également présentés et expliqués dans des documents distincts.

Informations connexes

• Informations d'assistance sur les produits DSL Cisco
• Support technique - Cisco Systems