Ethernet longue portée (LRE) et ligne numérique d'abonné (xDSL) : Ligne d'abonné numérique à débit asymétrique (ADSL)

Architecture de référence de pontage RFC1483

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit l'architecture de bout en bout de Ligne d'abonné numérique à débit asymétrique (ADSL) en utilisant la transition RFC1483. Notez que la plupart des versions tôt des Modems de xDSL étaient des ponts entre les Ethernets 10BaseT au côté de hôte et RFC1483 a encapsulé des trames de passerelle du côté WAN. Même aujourd'hui, la majorité de la CPE ADSL (CPE) déployée dans le domaine sont en mode traversier pur.

Supposition

L'architecture de référence est conçue avec l'hypothèse de permettre d'accéder l'accès Internet à grande vitesse à l'abonné final utilisant le RFC1483 jetant un pont sur le modèle et l'atmosphère comme circuit principal. Le contenu du document est basé sur l'architecture des déploiements existants et de quelques essais en interne.

Brief technique

RFC1483 décrit deux différentes méthodes pour porter le trafic sans connexion d'interconnexion de réseau au-dessus d'un réseau atmosphère : Protocol Data Unit conduits (PDU) et PDU traversiers.

Le routage permet le multiplexage de plusieurs protocoles au-dessus d'un circuit virtuel ATM simple (circuit virtuel). Le protocole d'un PDU porté est identifié en préfixant le PDU avec une en-tête de Contrôle de la liaison logique (LLC) d'IEEE 802.2.

La transition exécute le protocole de couche plus élevée multiplexant implicitement par des circuits virtuels ATM. Le pour en savoir plus, se rapportent à RFC1483.

Ce document se réfère seulement des PDU traversiers.

Avantages et inconvénients de la transition RFC1483

Être suit un résumé des avantages et des inconvénients de l'architecture de pontage RFC1483. Cette architecture a quelques importants inconvénients, plus dont soyez inhérent au modèle traversier. Certains des inconvénients ont été notés pendant les déploiements sur ADSL aux sites client.

Avantages

  • Simple pour comprendre.

    La transition est très simple pour comprendre et implémenter parce qu'il n'y a aucun problème complexe tel que des conditions requises de routage ou d'authentification pour des utilisateurs.

  • Configuration minimale du CPE.

    Le fournisseur de services considère ceci important parce qu'il n'exige plus un grand nombre de déplacements entre sites et plus de besoins d'investir fortement dans le personnel pour le support des protocoles de plus haut niveau. Le CPE en mode de passerelle agit en tant que périphérique très simple. Le dépannage minimal est impliqué au CPE parce que tout qui entre des Ethernets passe directement au côté WAN.

  • Facile à installer.

    Il est facile installer architecture de pontage en raison de sa nature simpliste. Après que des circuits virtuels permanents de bout en bout (PVCs) soient établis, les activités telles que l'IP aux protocoles de couche supérieure deviennent transparentes.

  • Soutien multiprotocole de l'abonné.

    Quand le CPE est en jetant un pont sur le mode, on ne le concerne pas par quel protocole de couche supérieure est encapsulé.

  • Idéal pour l'accès Internet dans un environnement de seul utilisateur.

    Puisque le CPE agit en tant que boîtier décodeur, le dépannage complexe n'est pas exigé pour des protocoles de couche supérieure. Les PC d'extrémité n'exigent pas l'installation supplémentaire de client.

Inconvénients

  • La transition dépend largement des émissions pour établir la Connectivité.

    Les émissions entre les milliers d'utilisateurs sont en soi non-mesurables. Les raisons pour ceci sont que l'émission consomme la bande passante à travers la boucle du xDSL des utilisateurs, et l'émission exige des ressources au routeur de tête de réseau de répliquer des paquets pour l'émission au-dessus (atmosphère) des medias PVC point par point.

  • La transition est en soi non sécurisée et exige un environnement de confiance.

    Les réponses de Protocole ARP (Address Resolution Protocol) peuvent être charriées et une adresse réseau être détournées. Supplémentaire, des attaques d'émission peuvent être initiées sur le sous-réseau local, de ce fait refusant le service à tous les membres du sous-réseau local.

  • Le détournement d'adresse IP est possible.

Considérations d'implémentation

Considérez les questions suivantes avant de mettre en application l'architecture de pontage RFC1483.

  • Que le courant et les nombres prévus d'abonnés sont-ils à entretenir ?

  • Les abonnés doivent-ils communiquer les uns avec les autres ?

  • Ces abonnés les clients résidentiels sont-ils à utilisateur unique ? Entretenez-vous le petit bureau, les clients du bureau à domicile (SOHO) qui pourraient avoir un petit RÉSEAU LOCAL derrière le CPE ?

  • Quel est le déploiement et le ravitaillement de CPEs, de multiplexeurs d'accès de ligne d'abonné numérique (DSLAM) et de Posts Offices Protocol d'agrégation (bruits) ?

  • Sont-ils le fournisseur d'accès au réseau (PETIT SOMME) et le fournisseur de service réseau (NSP) la même entité ? Le modèle professionnel pour le PETIT SOMME implique-t-il également de vendre des services en gros tels que l'accès sécurisé à l'entreprise, et les services à valeur ajoutée tels que la Voix et le vidéo ?

  • Le NSP veut-il offrir des capacités de sélection de service ?

  • Comment la comptabilité et la facturation peuvent-elles être réalisées ? Est-il par utilisation, par bande passante, ou par service ?

  • Le modèle professionnel est-il de la société qui d'un opérateur d'échanges locaux indépendant (ILEC), de l'opérateur local concurrent (CLEC), ou du fournisseur de services Internet (ISP) ?

  • Quels types d'applications le NSP veut-il offrir à l'abonné final ?

  • Que le volume de flux de données est-il tous deux en amont et en aval ?

Ces points étant considéré, suivantes sont les descriptions de la façon dont l'architecture de pontage RFC1483 s'adaptera et mesurera à différents modèles professionnels.

Network Architecture

/image/gif/paws/12916/rfc_brdg_arch_1.gif

Pontage RFC1483 : Network Architecture

Considérations de conception

Comme précédemment mentionné, il y a quelques problèmes inhérents avec l'architecture de pontage RFC1483.

La fonction de pontage d'abonné IOS aborde certains de ces problèmes. L'application sélective des stratégies d'abonné aux contrôles de groupe de passerelle l'inondation des ARPs, les paquets inconnus, et d'autres avalent chaque boucle ADSL. Par exemple, en empêchant des ARPs d'être annoncée, un utilisateur hostile ne peut pas découvrir l'adresse IP d'un autre utilisateur.

Une autre solution est de mettre tous les abonnés dans une sous-interface simple. Le comportement traversier normal ne fera pas suivre à des trames le port sur lequel la trame a été reçue. Essentiellement, ceci impose un type d'abonné jetant un pont sur dans lequel tous les paquets entre les abonnés sont filtrés. Cependant, cette approche a les imperfections suivantes :

  • La stratégie d'abonné est seulement appliquée entre les sous-interfaces. Pour appliquer des stratégies d'abonné entre deux utilisateurs différents, chaque utilisateur doit être dans une sous-interface différente atmosphère.

  • Puisque la reproduction d'adresses de la couche 2-to-Layer 3 est apprise (par l'intermédiaire de l'ARP), les utilisateurs hostiles peuvent encore détourner la connexion d'autres utilisateurs. Ceci est fait en générant le trafic ARP avec l'adresse IP d'un autre utilisateur et en utilisant une adresse MAC différente.

Le deuxième scénario est plus sérieux pour le transporteur ou l'ISP. Dans cette situation, n'importe quel utilisateur peut assigner la mauvaise adresse à un PC ou à un périphérique raccordé à Ethernet tel qu'une imprimante, et pose des problèmes de connexion pour un autre utilisateur. Il est difficile d'indiquer exactement et corriger de telles erreurs ou attaques parce que le contrevenant peut être dépisté seulement en traçant l'adresse MAC du contrevenant.

Essai de quelques transporteurs à fonctionner autour de ce problème à côté d'isoler des utilisateurs à travers des groupes de passerelle, et à côté de mettre en application l'abonné jetant un pont sur à travers des sous-interfaces. Dans ce cas quand le Routage et mise en parallèle intégrés (IRB) est exigé, chaque utilisateur est assigné un seuls groupe de passerelle et Bridge Group Virtual Interface (BVI). Cette approche utilise deux interfaces par abonné et peut être provocante pour gérer.

Ces questions sont abordées et résolues par certains côtés par la caractéristique traversière conduite de l'encapsulation (RBE) qui a été introduite dans la version de logiciel 12.0(5)DC de Cisco IOSÝ sur le Cisco 6400.

Vu certains des inconvénients de la transition, vous pourriez se demander pourquoi l'architecture de pontage serait jamais mise en application. La réponse est simple. La majeure partie de l'ADSL CPEs installé dans le domaine est capable seulement des trames pontées d'expédition. Dans des ces cas, le NSP doit implémenter la transition.

Aujourd'hui, CPEs peut faire le protocole point-à-point au-dessus du routage atmosphère (PPPoA), RFC1483 jetant un pont sur, et RFC1483. Le NSP détermine si faire la transition ou le PPP. La décision est basée sur les considérations d'implémentation citées précédemment, en plus des avantages - et - des inconvénients de chaque architecture.

Même avec les inconvénients de l'architecture de pontage, il peut convenir à un petit ISP (qui peut ne pas être le PETIT SOMME) ou un NAP/NSP servant un plus petit nombre d'abonnés. Dans ces scénarios, le PETIT SOMME habituellement en avant tout le trafic d'abonné à l'ISP/NSP, qui termine ces abonnés. Le PETIT SOMME a pu choisir de fournir le trafic d'abonné utilisant l'atmosphère ou le Relais de trames comme protocole de la couche 2.

Les petits sommes utilisant des DSLAM de la génération actuelle peuvent seulement transporter le trafic d'abonné utilisant l'atmosphère. Dans ce cas, l'ISP devrait terminer des circuits virtuels permanents atmosphère (PVCs) à un routeur.

Si l'ISP/NSP n'a pas l'interface ATM, une interface série régulière avec l'interface d'échange de données d'encapsulation ATM (DXI) (probablement sur un périphérique supplémentaire) peut être utilisée pour recevoir les PDU traversiers entrants.

Dans les deux scénarios, le NSP/ISP peut devoir configurer IRB sur le routeur (excepté en utilisant encapsulation ATM DXI ou dans le cas du Pontage transparent). Aujourd'hui, la plupart de pratique commune pour terminer des abonnés pontés sur le routeur NSP/ISP est d'implémenter IRB. (On s'attend à ce que les fournisseurs de services migrent graduellement vers RBE.)

En raison de certaines des limites mentionnées ci-dessus, le NSP/ISP peut choisir de configurer des groupes de ponts séparés pour chaque ensemble d'abonnés ou de configurer tous les abonnés dans un groupe de passerelle. La pratique commune est de configurer quelques groupes de passerelle, et puis configure tous les abonnés sous les interfaces multipoints distinctes. Comme cité précédemment, les abonnés sous la même interface multipoint peuvent ne pas pouvoir communiquer les uns avec les autres. Si certain besoin de l'utilisateur de communiquer, configurent ces abonnés sous différentes interfaces (ils peuvent encore être dans le même groupe de passerelle).

Pour un petit ISP/NSP, les Routeurs les plus communs utilisés pour terminer des abonnés pontés sont Cisco 3810, Cisco 3600, et Cisco 7200. Pour un ISP/NSP avec une grande base d'abonnés, le Cisco 6400 est préféré. Avant de calculer les mémoires réquises pour ces Routeurs, considérez les mêmes facteurs que pour n'importe quel autre environnement : nombre d'utilisateurs, de bande passante, et de ressources en routeur.

Points clé de cette architecture

Être suivent les points clé de l'architecture.

CPE

Cisco offre divers CPEs qui fonctionnent avec Cisco et non-Cisco DSLAM. La configuration pour chacun de ces CPEs est problème libre et n'exige aucune entrée de l'abonné. L'exigence fondamentale est que le CPE définissent un identifiant de chemin virtuel ATM/indentifiant de canal virtuel (VPI/VCI). Ceci permet au CPE pour s'exercer avec le DSLAM et pour commencer passer le trafic. Dans la plupart des exemples, le PETIT SOMME choisit de configurer le même VPI/VCI pour tous les abonnés. De PETIT SOMME les pré-dispositions habituellement le CPE avant de le déployer à l'emplacement de l'abonné.

En architecture de pontage, la considération principale pour le CPE et son déploiement est comment le PETIT SOMME gèrera le CPE après qu'il soit installé dans le domaine. C'est un souci parce que la transition n'exige pas une adresse IP pour le CPE. Cependant, des Cisco CPE peuvent provisioned avec une adresse IP pour jeter un pont sur le mode. Le PETIT SOMME peut employer cette caractéristique au telnet au CPE pour recueillir des statistiques ou pour aider l'abonné avec le dépannage. Pour permettre CPEs à gérer par les DSLAM, la nouvelle fonctionnalité d'élément de proxy est ajoutée.

En jetant un pont sur le mode, si aucune adresse IP de Gestion n'est assignée au CPE, l'opérateur peut seulement gérer le CPE par le port de gestion CPE. Si une adresse IP de Gestion est assignée, l'opérateur peut utiliser un navigateur de Protocole HTTP (Hypertext Transfer Protocol) pour gérer le périphérique. Cependant, cette option n'est généralement pas disponible.

Quand le CPE est en jetant un pont sur le mode, la destination de service (qui pourrait être le NSP/ISP) devrait fournir une adresse IP qui sera utilisée comme passerelle par défaut pour les PC derrière le CPE. Ces PC doivent être placés à la passerelle par défaut correcte. Autrement, même si le modem est formé (qui signifie que la couche physique est bonne entre le CPE et le DSLAM), l'abonné peut ne pas pouvoir passer le trafic. Ce n'est pas une question si le protocole DHCP (DHCP) est utilisé pour assigner des adresses DHCP d'abonné parce que le routeur par défaut est retourné par le serveur DHCP.

Gestion IP

rfc_brdg_arch_2.gif

Pontage RFC1483 : Gestion IP

Dans un environnement ponté, les adresses IP sont allouées aux stations d'extrémité par un serveur DHCP situé à la destination de service, habituellement dans le réseau NSP/ISP. C'est l'approche la plus commune et est mise en application par la plupart de NSPs/ISP utilisant ce modèle.

Une autre approche est de fournir des adresses IP statiques aux abonnés. Dans ce cas, un sous-réseau des adresses IP ou une adresse IP simple est alloué par abonné, selon les exigences d'abonné. Par exemple, les abonnés voulant héberger un serveur Web ou un serveur de mail auront besoin d'un ensemble d'adresses IP plutôt qu'une adresse IP simple. Le problème avec ceci est que le NSP/ISP doit fournir des adresses IP publique et peut rapidement manquer de elles.

Un certain NSPs/ISP ont fourni des adresses IP privées à leurs abonnés. Ils exécutent alors le Traduction d'adresses de réseau (NAT) au routeur de destination de service.

NSPs/ISP qui fournissent un plein sous-réseau pour un groupe de passerelle (avec plus d'un abonné) devrait savoir qu'un utilisateur peut assigner la mauvaise adresse à un PC ou à un périphérique raccordé à Ethernet, tel qu'une imprimante, et pose des problèmes de connexion pour un autre utilisateur.

Il est également possible que un NSP/ISP limite le nombre de PC qui peuvent accéder au service en même temps. Ceci est fait en configurant les utilisateurs maximum sur l'interface Ethernet.

Cependant, cette méthode a l'imperfection suivante. Si trois PC sont configurés pour utiliser le service et un des abonnés ajoute une imprimante en réseau (qui a sa propre adresse MAC) pendant un moment où un des PC est de veille, l'adresse MAC du PC disparaîtra de l'entrée d'ARP du CPE.

Si l'imprimante devient active tandis qu'un PC est de veille, l'imprimante ? l'adresse MAC s sera écrite dans l'entrée d'ARP. Quand un utilisateur décide d'utiliser ce PC pour accéder à l'Internet, il sera indisponible parce que le CPE a déjà permis trois entrées de MAC. La stratégie de limiter des utilisateurs sur le CPE peut être utilisée, mais le soin devrait être rentré réparant les nombres.

Comment une destination de service est atteinte

/image/gif/paws/12916/rfc_brdg_arch_3.gif

Pontage RFC1483 : PVC de bout en bout

En architecture de bout en bout PVC avec la transition, la destination de service est atteinte par la création de PVCs entre chaque saut. Cependant, la Gestion des ces PVCs peut être provocante pour le NAP/NSP. Supplémentaire, le nombre de PVCs qui peut être défini par le nuage ATM est limité. Cette limite affecte plusieurs des petits sommes/NSPs qui adoptent un modèle de bout en bout PVC. Pour chaque abonné il y aura un ensemble fixe et seul de VPIs/VCIs le long du chemin entier. Les circuits virtuels commutés (SVC) aident à surmonter certains de ces problèmes, et beaucoup de fournisseurs Internet migrent vers de principaux réseaux IP-activés pour résoudre le problème de l'épuisement de circuit virtuel.

Le NSP/ISP a également l'option d'employer la fonctionnalité de la passerelle de sélection de Cisco Service (SSG) pour fournir différents services aux abonnés.

En cette architecture, l'accès sécurisé à une passerelle d'entreprise est réalisé en terminant le PVC du trafic d'abonné directement dans le routeur entreprise à la couche 2. Les architectures à base de PVC sont en soi sécurisées en partageant des données avec d'autres destinations de service.

Description opérationnelle

/image/gif/paws/12916/rfc_brdg_arch_4.gif

Pontage RFC1483 : Description opérationnelle

Le CPE de Cisco 6xx se transfère sur conduire le mode. Par conséquent, quand il est configuré pour jeter un pont sur le mode et installé à l'emplacement de l'abonné avec les distributeurs/microfiltres nécessaires, il s'exerce automatiquement lors de l'alimentation. Quand le CPE s'exerce, il indique que la couche physique entre le CPE et le DSLAM est bien. Selon comment la station d'extrémité ? l'adresse IP s est configurée (c'est-à-dire, s'il est assigné par l'intermédiaire d'un serveur DHCP ou c'est une adresse IP statique avec les informations sur la passerelle par défaut), il peut alors communiquer avec la destination de service.

Être suit une description de l'écoulement des paquets.

Les données d'utilisateur sont encapsulées dans l'IEEE 802.3 du PC et écrivent le CPE CiscoÝ6xx. Il est alors encapsulé dans une en-tête du protocole d'accès de Logical Link Control/sous-réseau (LLC/SNAP), qui est encapsulée dans l'adaptation layerÝ5 (AAL5) atmosphère et consécutivement remise à la couche atmosphère.

Les cellules atmosphère sont alors modulées par la technologie de transmission en ADSL, la modulation d'amplitude de Carrierless et de phase (CAP) ou la Multi-tonalité discrète (DMT), et envoyées au-dessus du fil au DSLAM. Au DSLAM, ces signaux modulés sont d'abord reçus par le répartiteur POTS, qui vérifie au-dessous de si la fréquence du signal est ou au-dessus du KHZ 4. Après qu'il identifie les signaux comme au-dessus du KHZ 4, il les passe à l'unité de transmission en ADSL - le bureau central (ATU-C) dans le DSLAM.

L'ATU-C démodule le signal et récupère les cellules atmosphère, qui sont alors passées au network interface card (NIC) dans le périphérique de multiplexage (MUX). Le NIC regarde les informations du côté des abonnés VPI/VCI dans l'en-tête ATM et prend la décision de commutation à un autre VPI/VCI qui sera expédié au routeur de destination de service. Après que le routeur de destination de service reçoive ces cellules sur une interface ATM particulière, elle les rassemble, regarde la couche supérieure, et passe les informations à l'interface BVI. L'interface BVI regarde les informations de la couche 3 et décide où le paquet doit être livré.

Conclusion

Le RFC1483 jetant un pont sur le modèle est plus approprié aux petits FAI ou à l'accès d'entreprise pour lesquels l'évolutivité ne devient pas une question. Puisqu'il est très simple de comprendre et implémenter, c'est devenu le choix de beaucoup de petits FAI. Cependant, en raison de quelques Sécurité et problèmes d'évolutivité, l'architecture de pontage perd sa popularité. NSPs/ISP optent pour RBE ou se déplacent vers PPPoA ou PPPoE, qui sont fortement extensibles et très sécurisés, mais plus complexe et difficile à implémenter.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 12916