Ethernet longue portée (LRE) et ligne numérique d'abonné (xDSL) : PPPoE/PPPoA (PPP sur Ethernet/PPP sur ATM)

Architecture de référence PPPoA

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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.

Supposition

L'architecture de référence assume le besoin de permettre d'accéder l'accès Internet à grande vitesse et l'accès d'entreprise à l'abonné final utilisant PPPoA comme circuit principal. Nous discuterons cette architecture basée sur les canaux virtuels privés (PVCs), la méthode utilisée le plus souvent dans des déploiements en cours. L'architecture utilisant les circuits virtuels commutés (SVC) sera discutée dans des d'autres documents.

Ce document est basé sur des déploiements existants aussi bien que des essais en interne de l'architecture.

Ce document a été écrit avec la supposition que le lecteur est bien informé et au courant des considérations de conception d'un fournisseur d'accès au réseau (PETIT SOMME) comme décrit dans le livre blanc sur l'architecture de base du pontage RFC1483.

Brief technique

Le Protocole point à point (PPP) (RFC 1331) fournit une méthode standard d'encapsuler des protocoles de couche plus élevée à travers des connexions point-à-point. Il étend la structure de paquet de High-Level Data Link Control (HDLC) avec un identificateur de protocole de 16 bits qui contient des informations sur le contenu du paquet.

Le paquet contient trois types d'informations :

  • Le Link Control Protocol (LCP) ? négocie des paramètres de lien, la longueur de paquet, ou le type d'authentification

  • Protocole de contrôle de réseau (NCP) ? contient des informations sur des protocoles de couche plus élevée comprenant l'IP et l'IPX, et leurs protocoles de contrôle (IPCP pour l'IP)

  • Trames de données contenant des données

Le PPP au-dessus de l'adaptation ATM de couche 5 (AAL5) (RFC 2364) utilise AAL5 comme protocole tramé, qui prend en charge le PVC et le SVC. PPPoA a été principalement mis en application en tant qu'élément de l'ADSL. Il se fonde sur RFC1483, actionnant en l'un ou l'autre le mode logique du protocole d'accès (LLC-SNAP) ou du circuit virtuel-Mux de Contrôle-sous-réseau de lien. Un périphérique de la CPE (CPE) encapsule la session PPP basée sur ce RFC pour le transport à travers la boucle ADSL et le multiplexeur d'accès de ligne d'abonné numérique (DSLAM).

Avantages et inconvénients d'architecture de PPPoA

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

Avantages

  • Par authentification de session basée sur le Password Authentication Protocol (PAP) ou le protocole d'authentification CHAP (Challenge Handshake Authentication Protocol). C'est le plus grand avantage de PPPoA car l'authentification surmonte la faille de sécurité en architecture de pontage.

  • Par session la comptabilité est possible, qui permet au fournisseur de services pour charger l'abonné basé sur le temps de session pour de divers services offerts. Par session la comptabilité permet à un fournisseur de services d'offrir un niveau à accès minimum pour la charge minimale et puis de charger des abonnés pour des services supplémentaires utilisés.

  • Économie d'adresse IP au CPE. Ceci permet au fournisseur de services pour assigner seulement une adresse IP pour un CPE, avec le CPE configuré pour le Traduction d'adresses de réseau (NAT). Tous les utilisateurs derrière un CPE peuvent employer une adresse IP simple pour atteindre différentes destinations. Le temps système de Gestion IP pour le fournisseur d'accès au réseau/fournisseur de services réseau (NAP/NSP) pour chaque utilisateur individuel est réduit tout en économisant des adresses IP. Supplémentaire, le fournisseur de services peut fournir un petit sous-réseau des adresses IP pour surmonter les limites de translation d'adresses d'adresse du port (PAT) et NAT.

  • Les petits sommes/NSPs permettent d'accéder l'accès sécurisé aux passerelles d'entreprise sans gérer PVCs de bout en bout et utiliser le routage de la couche 3 ou posent 2 expédiant/tunnels du Layer 2 Tunneling Protocol (L2F/L2TP). Par conséquent, ils peuvent mesurer leurs modèles professionnels pour vendre des services en gros.

  • Dépannage différents des abonnés. Le NSP peut facilement identifier quels abonnés sont "Marche/Arrêt" basés sur les sessions PPP actives, plutôt que dépannage des groupes entiers comme cela est le cas pour l'architecture de pontage.

  • Le NSP peut oversubscribe en déployant des délais d'attente d'inactif et de session utilisant un serveur industriellement compatible de Service RADIUS (Remote Authentication Dial-In User Service) pour chaque abonné.

  • Fortement extensible comme nous pouvons terminer très un nombre élevé de sessions PPP sur un routeur d'agrégation. L'authentification, l'autorisation, et la comptabilité peuvent être manipulées pour chaque utilisateur à l'aide des serveurs RADIUS externes.

  • Utilisation optimale des caractéristiques sur le Passerelle de sélection de services (SSG).

Inconvénients

  • Seulement une session simple par CPE sur un canal virtuel (circuit virtuel). Puisque le nom d'utilisateur et mot de passe sont configurés sur le CPE, tous les utilisateurs derrière le CPE pour ce circuit virtuel particulier peuvent accéder à seulement un ensemble de services. Les utilisateurs ne peuvent pas sélectionner différents ensembles de services, bien qu'utilisant plusieurs VCs et l'établissement de différentes sessions PPP sur VCs différent est possible.

  • Plus grande complexité de l'installation CPE. Le personnel d'assistance au fournisseur de services doit être plus bien informé. Puisque le nom d'utilisateur et mot de passe sont configurés sur le CPE, l'abonné ou le constructeur CPE devra apporter des modifications d'installation. Utilisant plusieurs VCs augmente la complexité de configuration. Ceci, cependant, peut être surmonté par une caractéristique d'autoconfiguration qui n'est pas encore libérée.

  • Le fournisseur de services doit mettre à jour une base de données des noms d'utilisateur et mot de passe pour tous les abonnés. Si des tunnels ou les services proxys sont utilisés, alors l'authentification peut être faite sur la base du nom de domaine et l'authentification de l'utilisateur est faite à la passerelle d'entreprise. Ceci réduit la taille de la base de données que le fournisseur de services doit mettre à jour.

  • Si une adresse IP simple est fournie au CPE et au NAT/PAT est mise en application, certaines applications telles qu'IPTV, qui encastrent les informations IP dans la charge utile, ne fonctionneront pas. Supplémentaire, si une caractéristique d'IP de sous-réseau est utilisée, une adresse IP doit également être réservée pour le CPE.

Considérations d'implémentation pour l'architecture de PPPoA

Les points clé à considérer avant de mettre en application l'architecture de PPPoA incluent :

  • Le nombre d'abonnés qui seront entretenus actuellement et à l'avenir, comme ceci affecte le nombre de sessions PPP exigées.

  • Si les sessions PPP sont terminés au fournisseur de services ? routeur d'agrégation s ou expédié à d'autres passerelles d'entreprise ou fournisseurs d'accès Internet (ISP).

  • Si le fournisseur de services ou la destination définitive de service fournit l'adresse IP à l'abonné ? CPE s.

  • Si les adresses IP fournies sont public ou privées juridique. Est-ce que CPE allant faire NAT/PAT ou NAT sera exécuté est-il à la destination d'arrêt ?

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

  • Dans le cas de plus d'un utilisateur, si tout le besoin de l'utilisateur d'atteindre la même destination définitive ou service, ou eux tous ont différentes destinations de service.

  • Le fournisseur de services fournit-il des services à valeur ajoutée comme la Voix ou le vidéo ? Le fournisseur de services exige-t-il tous les abonnés à d'abord vont-ils à un réseau particulier avant d'atteindre une destination définitive ? Quand les abonnés utilisent SSG, vont-ils utiliser des services de fonction émulation, l'agrégation terminée par PPP (Pta), un périphérique de médiation, ou le proxy ?

  • Comment le fournisseur de services affiche des abonnés — basés sur un prix forfaitaire, par utilisation de session, ou des services utilisés.

  • Déploiement et ravitaillement de CPEs, de DSLAM et de points de présence d'agrégation (bruits).

  • Le modèle professionnel pour le PETIT SOMME. Le modèle inclut-il également vendre des services en gros comme l'accès sécurisé à l'entreprise et les services à valeur ajoutée comme la Voix et le vidéo ? Les petits sommes et le NSPs sont-ils la même entité ?

  • Le modèle professionnel de la société. Est-il comparable à un opérateur d'échanges locaux indépendant (ILEC), à un opérateur local concurrent (CLEC) ou à un ISP ?

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

  • En amont et en aval le volume anticipé de flux de données.

Maintenant ces points dans l'esprit, nous discuterons comment l'architecture de PPPoA s'adaptera et mesurera à différents modèles professionnels pour des fournisseurs de services et comment les fournisseurs peuvent bénéficier utilisant cette architecture.

Network Architecture typique de PPPoA

Le diagramme suivant affiche une architecture de réseau typique de PPPoA. Les clients utilisant CPEs se connectent au fournisseur de services par un DSLAM Cisco, qui se connecte à un agrégateur de Cisco 6400 utilisant l'atmosphère.

/image/gif/paws/12914/pppoa_arch_1.gif

Considérations de conception pour l'architecture de PPPoA

Dans la section de « considérations d'implémentation » de ce document, des architectures de PPPoA peuvent être déployées utilisant différents scénarios selon le fournisseur de services ? modèle professionnel s. Dans cette section, nous discuterons les différentes possibilités et considérations que les fournisseurs de services doivent maintenir dans l'esprit avant de déployer une solution.

Avant de déployer une architecture de PPPoA et une solution particulière pour cette architecture, il est essentiel de comprendre le fournisseur de services ? modèle professionnel s. Considérez les services que le fournisseur de services offrira. Le fournisseur de services offrira-t-il un service comme l'accès Internet à grande vitesse à ses abonnés finaux ou est-ce qu'il vendra des services en gros aux autres FAI et fournira des services à valeur ajoutée à ces abonnés ? Le fournisseur de services offrira-t-il tous ?

Dans le cas de l'accès Internet à grande vitesse dans un environnement où le NSP et le PETIT SOMME sont le même, l'abonné ? des sessions PPP s doivent être terminées dans le routeur d'agrégation déployé. Dans ce scénario, les fournisseurs de services doivent considérer combien de sessions PPP peuvent être terminées sur un périphérique d'agrégation de routeur unique, comment les utilisateurs vont être authentifiés, comment ils vont exécuter la comptabilité, et le chemin à l'Internet une fois que des sessions d'utilisateur sont terminées. Selon le nombre de sessions PPP et d'abonnés, le routeur d'agrégation pourrait être un Cisco 6400 ou un Cisco 7200. Aujourd'hui ? le Cisco 6400 s avec 7 processeurs d'artère de noeud (NRPs) peut terminer jusqu'à 14,000 sessions PPP. Le Cisco 7200 est limité à 2,000 sessions PPP. Ces nombres changeront avec de nouvelles releases. Veuillez vérifier les notes de mise à jour et des documents de produit pour le numéro exact de sessions que chaque routeur d'agrégation peut le prendre en charge.

L'authentification de l'utilisateur et la comptabilité dans les ces scénario mieux est manipulée à l'aide d'un serveur industriellement compatible de RAYON, qui peut authentifier un utilisateur basé sur le nom d'utilisateur ou l'identifiant de chemin virtuel/indentifiant de canal virtuel (VPI/VCI) étant utilisé.

Pour l'accès Internet à grande vitesse, NSPs affichent habituellement des clients par prix forfaitaire. La plupart des déploiements en cours sont mises en application de cette façon. Quand le NSP et le PETIT SOMME sont la même entité, des clients sont affichés à un taux fixe pour l'accès et à un taux fixe différent pour l'accès Internet. Ce modèle change quand le fournisseur de services met sur pied des services à valeur ajoutée de offre. Les fournisseurs de services peuvent charger le client en fonction sur le type de service et la durée le service est utilisée. Les clients se connectent à l'Internet par le routeur d'agrégation utilisant des protocoles de routage comme le Protocole OSPF (Open Shortest Path First) ou le Protocole EIGPR (Enhanced Interior Gateway Routing Protocol) à un routeur de périphérie qui pourrait être Protocole BGP (Border Gateway Protocol) courant.

Une autre option que le fournisseur de services a pour la fourniture de l'accès Internet à grande vitesse est d'expédier les sessions PPP entrantes des abonnés à un ISP distinct utilisant le Tunnellisation L2TP/L2F. Quand le Tunnellisation L2x est utilisé, la considération spéciale devrait être donnée pour la façon dont la destination de tunnel peut être atteinte. Les options disponibles sont au l'un ou l'autre exécuté quelques protocoles de routage ou fournissent les artères statiques dans le routeur d'agrégation. Les limites à l'aide des tunnels L2TP ou L2F sont : (1) le nombre de tunnels et le nombre de sessions qui peuvent être prises en charge dans des ces tunnels ; et (2) l'utilisation des protocoles de routage incompatibles avec les ISP de tiers, qui peuvent exiger utilisant les artères statiques.

Si le fournisseur de services offre des services pour des autres FAI ou des passerelles d'entreprise à l'abonné final, ils peuvent devoir implémenter des caractéristiques SSG sur le routeur d'agrégation. Ceci permet à l'abonné pour sélectionner différentes destinations de service à l'aide de la sélection de service par le Web. Le fournisseur de services peut ou les sessions PPP en avant d'abonnés à leurs destinations sélectionnées en combinant toutes les sessions destinées à l'ISP dans un PVC simple pour le transport, ou si le fournisseur de services offre des niveaux de plusieurs services, plus d'un PVC pourrait être établi à travers le noyau.

Dans un modèle en gros de service, le fournisseur de services peut ne pas utiliser des caractéristiques 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.

Une considération importante dans l'un de ces scénarios est comment le fournisseur de services peut offrir un différent Qualité de service (QoS) pour différents services et comment ils calculent l'allocation de bande passante. Actuellement, la manière la plupart des fournisseurs de services déploient les offres de cette architecture QoS différent sur PVCs différent. Ils peuvent avoir PVCs distinct sur le noyau pour des clients résidentiels et professionnels. Utilisant PVCs différent permet à des fournisseurs de services pour spécifier QoS différent pour différents services. De cette façon, QoS a pu être sur PVCs distinct ou à la couche 3.

L'application de QoS à la couche 3 exige du fournisseur de services de connaître la destination définitive, qui pourrait être un facteur de limitation. Mais, si utilisé en combination avec la couche 2 QoS (en l'appliquant sur VCs différent), il peut être utile pour le fournisseur de services. La limite avec ce modèle est qu'elle est réparée et le fournisseur de services doit provision pour QoS à l'avance. QoS n'obtient pas appliqué dynamiquement sur la sélection du service. Actuellement, il n'y a aucune option pour qu'un utilisateur sélectionne des bandes passantes différentes pour différents services avec un clic de la souris ; cependant, l'effort d'ingénierie significatif a été investi de développer cette caractéristique.

Le déploiement, la Gestion, et le ravitaillement CPE pourraient être très provocants en cette architecture, comme le CPE doit être configuré pour des noms d'utilisateur et mot de passe. Comme solution simple, certains de fournisseurs de services utilisent le même nom d'utilisateur et mot de passe pour tout le CPEs. Ceci présente un risque de sécurité significatif. Supplémentaire, si le CPE doit ouvrir simultanément différentes sessions, besoin supplémentaire de VCs de provisioned au CPE, PETIT SOMME et NSP. Les DSLAM Cisco et les périphériques d'agrégation ont la capacité de simplifier la configuration CPE et le ravitaillement. Traversez les outils de gestion sont également disponibles pour le ravitaillement de bout en bout PVC. Le ravitaillement au NSP pour tant d'abonnés utilisant PVCs est un facteur de limitation puisque tout le PVCs différent doit être géré. Supplémentaire, il n'y a aucun moyen simple du ravitaillement 2000 PVCs sur un NRP simple en cliquant sur une souris ou en écrivant peu de rappes de clé.

Aujourd'hui nous avons différentes applications d'administration pour différents composants de cette architecture, tels que Viewrunner pour le DSLAM et SCM pour le Cisco 6400 là n'est aucune plate-forme d'administration qui provision tous les composants. C'est une limite bien identifiée et le grand effort est investi d'avoir une application simple, d'administration exhaustive pour provision le CPE, le DSLAM et le Cisco 6400. En outre, nous avons actuellement une solution pour implémenter PPPoA avec le SVC, qui facilitera considérablement le déploiement. PPPoA avec le SVC permettra également aux utilisateurs finaux pour sélectionner la destination et le QoS dynamiquement.

Un autre point important à maintenir dans l'esprit pour de grands déploiements sur ADSL utilisant cette architecture est la transmission du routeur d'agrégation au serveur de RAYON. Si la lame NRP échoue quand plusieurs milliers de sessions PPP sont terminées sur un périphérique d'agrégation, toutes ces sessions PPP doivent être rétablies. Ceci signifie que tous les abonnés doivent être authentifiés et leurs enregistrements des comptes arrêtés et être redémarrés une fois que la connexion est établie. Quand l'essai de tant d'abonnés à obtenir authentifié en même temps, le canal au serveur de RAYON peut être un étranglement. Quelques abonnés peuvent ne pas pouvoir être authentifié et ceci peut créer des problèmes pour le fournisseur de services.

Il est très important d'avoir un lien au serveur de RAYON avec l'assez de bande passante pour rendre service à tous les abonnés en même temps. En outre, le serveur de RAYON devrait être assez puissant pour accorder des autorisations à tous les abonnés. Dans le cas des milliers d'abonnés, une option d'équilibrer la charge entre les serveurs disponibles de RAYON devrait être considérée. Cette caractéristique est disponible en logiciel de ½ du ¿  de Cisco IOSïÂ.

Comme considération finale, le routeur d'agrégation doit exécuter suffisamment pour rendre service à beaucoup de sessions PPP. Appliquez les mêmes principes d'ingénierie de trafic utilisés par d'autres réalisations. Précédemment, l'utilisateur a dû configurer PVCs sur des sous-interfaces point par point. Aujourd'hui PPPoA permet à des utilisateurs pour configurer plusieurs PVCs sur les sous-interfaces multipoints aussi bien que le Point à point. Chaque connexion de PPPoA n'exige plus deux blocs de descripteur d'interface (IDBs), un pour l'interface d'accès virtuelle et un pour la sous-interface atmosphère. Cette amélioration augmente le nombre maximal de sessions de PPPoA s'exécutant sur un routeur.

Les sessions de PPPoA de nombre maximal prises en charge sur une plate-forme dépend des ressources système disponibles telles que la mémoire et la vitesse du CPU. Chaque session de PPPoA prend une interface d'accès virtuelle. Chaque interface d'accès virtuelle se compose d'un bloc de descripteur d'interface de matériel et d'une paire du bloc de descripteur d'interface logicielle (hwidb/swidb). Chaque hwidb prend au sujet de 4.5K. Chaque swidb prend au sujet de 2.5K. Ensemble, les interfaces d'accès virtuelles exigent 7.5K. 2000 interfaces d'accès virtuelles exigent 2000 * 7.5K ou 15M. Pour exécuter 2000 sessions, un routeur a besoin d'un 15M supplémentaire. En raison de l'augmentation de la limite de session, le routeur doit prendre en charge plus d'IDBs. Ce support affecte la représentation due à plus de cycles CPU pour exécuter plus d'exemples de l'ordinateur d'état de PPP.

Points clé d'architecture de PPPoA

Cette section décrit trois points clé en architecture de PPPoA : la Gestion CPE, IP, et atteinte de la destination de service.

/image/gif/paws/12914/pppoa_arch_2.gif

En raison de la nature de PAT, certaines applications qui encastrent les 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 des adresses IP plutôt qu'une adresse IP simple.

En cette architecture il est plus facile que le NAP/NSP au telnet dans le CPE de configurer et dépanner puisqu'une adresse IP est assignée au CPE.

CPEs peut utiliser différentes options selon l'abonné ? profil s. Par exemple, parce que un utilisateur résidentiel le CPE peut être configuré sans PAT/DHCP. Pour des abonnés avec plus d'un PC, CPEs peut être configuré pour PAT/DHCP ou la même manière que cela d'un utilisateur résidentiel. S'il y a un téléphone IP connecté au CPE, le CPE peut être configuré pour plus d'un PVC.

Gestion IP

pppoa_arch_3.gif

En architecture de PPPoA, l'allocation d'adresse IP pour le CPE d'abonné utilise la négociation IPCP, le même principe du PPP en mode de numérotation. Des adresses IP sont allouées selon le type de service des utilisations d'un abonné. Si l'abonné a seulement l'accès Internet du NSP, le NSP terminera ces sessions PPP de l'abonné et assignera une adresse IP. L'adresse IP est allouée d'un groupe localement défini, un serveur DHCP, ou peut être appliquée du serveur de RAYON. En outre, l'ISP a pu avoir fourni un ensemble d'adresses IP statiques à l'abonné et peut ne pas assigner des adresses IP dynamiquement quand l'abonné initie la session PPP. Dans ce scénario, le fournisseur de services utilisera seulement le serveur de RAYON pour authentifier l'utilisateur.

Si l'abonné préfère avoir des plusieurs services disponibles, le NSP peut devoir implémenter SSG. Être suivent des possibilités pour assigner des adresses IP.

  • Le fournisseur de services peut fournir une adresse IP à l'abonné par son groupe local ou serveur de RAYON. Après que l'utilisateur sélectionne un service, le SSG en avant l'utilisateur ? le trafic s à cette destination. Si le SSG utilise le mode proxy, la destination définitive peut fournir une adresse IP, que le SSG utilisera comme adresse visible pour NAT.

  • Les sessions PPP n'obtiennent pas terminé sur le fournisseur de services ? routeur d'agrégation s. Ils sont percés un tunnel ou expédiés à la destination définitive ou à la passerelle domestique, qui termineront par la suite les sessions PPP. La destination définitive ou la passerelle domestique est en pourparlers IPCP avec l'abonné, fournissant de ce fait une adresse IP dynamiquement. Les adresses statiques sont également possibles tant que la destination définitive a alloué ces adresses IP et a une artère à elles.

Avant la version du logiciel Cisco IOS 12.0.5DC pour le Cisco 6400 NRP, il n'y avait aucune manière pour que le fournisseur de services fournisse un sous-réseau des IP address à l'abonné. La plate-forme et la gamme Cisco 600 CPEs de Cisco 6400 permettent des sous-réseaux IP à configurer dynamiquement sur le CPE pendant la négociation PPP. Une adresse IP de ce sous-réseau est assignée au CPE et les adresses IP restantes sont dynamiquement allouées aux stations par le DHCP. Quand cette caractéristique est utilisée, CPEs n'a pas besoin d'être configuré pour PAT, qui ne fonctionne pas avec quelques applications.

Comment la destination de service est atteinte

En architectures de PPPoA, la destination de service peut être atteinte dans différentes manières. Certaines des méthodes le plus généralement déployées sont :

  • Terminaison des sessions PPP au fournisseur de services

  • Tunnellisation L2TP

  • Utilisant SSG

Dans chacune des trois méthodes il y a un ensemble fixe de PVC défini du CPE au DSLAM qui est commuté à un ensemble fixe de PVC sur le routeur d'agrégation. Le PVCs sont tracés du DSLAM au routeur d'agrégation par un nuage ATM.

La destination de service peut également être atteinte utilisant d'autres méthodes un tel PPPoA avec des SVC, ou commutation par étiquette multiprotocole/réseau privé virtuel. Ces méthodes sont hors de portée de ce document et seront discutées en d'autres documents.

Terminaison du PPP à l'agrégation

pppoa_arch_4.gif

Les sessions PPP initiées par l'abonné sont terminées au fournisseur de services qui authentifie des utilisateurs utilisant une base de données locale sur le routeur ou par des serveurs de RAYON. Après que l'utilisateur soit authentifié, la négociation IPCP a lieu et l'adresse IP est assignée au CPE. Après que l'adresse IP ait été assignée, il y a une route hôte a établi sur le CPE et sur le routeur d'agrégation. Les adresses IP allouées à l'abonné, si juridiques, 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 à l'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

pppoa_arch_5.gif

Les sessions PPP, selon le fournisseur de services ou la société, percent un tunnel au point d'arrêt en amont utilisant L2TP ou L2F au lieu de l'terminaison sur le fournisseur de services ? routeur d'agrégation s. Ce point d'arrêt authentifie le nom d'utilisateur et l'abonné est assigné une adresse IP par l'intermédiaire du DHCP ou d'un groupe local. Pour ce scénario il y a habituellement un tunnel établi entre le concentrateur L2TP Access/serveur d'accès à distance (LAC/NAS) et la passerelle domestique ou le serveur de réseau L2TP (LNS). Le LAC authentifie la session entrante basée sur le nom de domaine ; le nom d'utilisateur est authentifié à la destination définitive ou à la passerelle domestique.

Dans ce modèle, cependant, l'utilisateur peut seulement avoir accès à la destination définitive et peut accéder à seulement une destination à la fois. Par exemple, si le CPE est configuré avec un nom d'utilisateur de rtr@cisco.com, les PC derrière ce CPE peuvent seulement avoir accès au domaine de Cisco. S'ils veulent se connecter à un autre réseau d'entreprise, ils doivent changer le nom d'utilisateur et mot de passe sur le CPE pour refléter ce nom de domaine entreprise. La destination de tunnel dans ce cas est atteinte à l'aide d'un protocole de routage, des artères statiques, ou de faire l'IP sur ATM classique (si l'atmosphère est préférée en tant que couche 2).

Utilisant le Passerelle de sélection de services (SSG)

/image/gif/paws/12914/pppoa_arch_6.gif

L'avantage principal de SSG au-dessus du Tunnellisation est que SSG fournit le mappage d'un-à-beaucoup de services, tandis que le perçage d'un tunnel fournit seulement le mappage linéaire. Ceci devient très utile quand un seul utilisateur a besoin de l'accès aux plusieurs services, ou des plusieurs utilisateurs à un emplacement simple chaque accès du besoin à un seul service. SSG utilise le tableau de bord de sélection de service par le Web (disque transistorisé), qui se compose de différents services et est à la disposition de l'utilisateur. L'utilisateur peut accéder à un service ou plusieurs services en même temps. Un autre avantage d'utiliser SSG est que le fournisseur de services peut afficher l'utilisateur basé sur les services utilisés et le temps de session, et l'utilisateur peut tourner des services en marche et en arrêt par le disque transistorisé.

/image/gif/paws/12914/pppoa_arch_7.gif

Des utilisateurs sont authentifiés pendant que la session PPP entre des abonnés. Des utilisateurs sont assignés des adresses IP du groupe local ou du serveur de RAYON. Après qu'un utilisateur soit avec succès authentifié, un objet de source est créé par le code SSG et l'utilisateur est donné l'accès à un réseau par défaut. Le réseau par défaut contient le serveur disque transistorisé. Utilisant un navigateur, les logins d'utilisateur au tableau de bord, authentifié par l'AAA est-il le serveur, et selon l'utilisateur ? le profil s enregistré dans le serveur de RAYON, est offert un ensemble de services à accéder à.

Chaque fois que un utilisateur authentifié sélectionne un service, le SSG crée un objet de destination pour cet utilisateur. L'objet de destination contient les informations telles que l'adresse de destination, l'adresse de serveur de DNS pour cette destination, et l'adresse IP source assignée de la passerelle domestique. Paquets étant livré dedans de l'utilisateur ? le côté s sont expédiés à la destination basée sur les informations contenues dans l'objet de destination.

SSG peut être configuré pour le service proxy, la connexion transparente, ou la Pta. Quand un abonné demande l'accès à un service proxy, le NRP-SSG passera l'Access-demande au serveur RADIUS distant. Lors de recevoir l'Access-recevoir, le SSG répond à l'abonné avec l'Access-recevoir. Le SSG apparaît en tant que client au serveur RADIUS distant.

La connexion transparente permet le trafic d'abonné unauthenticated à conduire par le SSG dans l'un ou l'autre de direction. Filtres d'utilisation pour contrôler le trafic de connexion transparente.

La Pta peut seulement être utilisée par des utilisateurs de Ppp-type. L'authentification, l'autorisation et la comptabilité est exécutée exactement comme dans le type de service proxy. Un abonné ouvre une session à un service utilisant un nom d'utilisateur de la forme user@service. Le SSG en avant qui au serveur de RAYON, qui charge alors le service profile au SSG. Le SSG en avant la demande au serveur RADIUS distant comme spécifié par le service profile ? attribut de serveur de RAYON s. Après que la demande soit authentifiée, une adresse IP est assignée à l'abonné. Pas NAT est exécuté. Tout le trafic d'utilisateur est agrégé au réseau distant. Avec la Pta, les utilisateurs peuvent accéder à seulement un service et n'auront pas accès au réseau par défaut ou au disque transistorisé.

Description opérationnelle d'architecture de PPPoA

Quand le CPE est d'abord mis sous tension, il commence envoyer des demandes de configuration LCP au serveur d'agrégation. Le serveur d'agrégation, avec le PVCs configuré, envoie également la demande de configuration LCP sur une interface d'Access virtuelle (associée avec le PVC). Quand chacun voit la demande de configuration de l'autre, ils reconnaissent les demandes et l'état LCP est ouvert.

Pour l'étape d'authentification, le CPE envoie la demande d'authentification au serveur d'agrégation. Le serveur, selon sa configuration, l'un ou l'autre authentifie l'utilisateur basé sur le nom de domaine (si fourni), ou le nom d'utilisateur utilisant sa base de données locale ou serveurs de RAYON. Si la demande de l'abonné est sous forme d'username@domainname, le serveur d'agrégation essayera de créer un tunnel à la destination, si on n'est pas déjà là. Après que le tunnel soit créé, le serveur d'agrégation en avant les demandes de PPP de l'abonné à la destination. La destination, consécutivement, authentifie l'utilisateur et assigne 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 de sélectionner différents services.

Conclusion

PPPoA devient l'architecture la plus appropriée pour beaucoup de fournisseurs de services parce qu'il est fortement extensible, utilise la fonctionnalité SSG, et fournit la Sécurité. Puisque le centre de ce document était architecture de PPPoA, il n'était pas possible de couvrir des caractéristiques comme SSG en profondeur. Ces caractéristiques seront couvertes en journal ultérieur. Des configurations d'échantillon pour les différents scénarios discutés dans ce document seront également présentées et expliquées en d'autres documents.


Informations connexes


Document ID: 12914