Ethernet de largo alcance (LRE) y Línea de suscriptor digital (xDSL) : Línea de suscriptor digital asimétrica (ADSL)

RFC1483 Arquitectura de línea de base de puente

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento describe la arquitectura de End-to-End Asymmetric Digital Subscriber Line (ADSL) cuando se utiliza el bridging de RFC1483. Observe que las primeras versiones de los módems xDSL eran Bridges entre la Ethernet 10BaseT en el lado del host y las tramas de Bridge encapsuladas de RFC1483 en el lado de WAN. Incluso actualmente, la mayoría de Customer Premises Equipment (CPE) de ADSL implementados en el campo están en modo de bridging puro.

Suposición

La arquitectura de línea de base se diseña con la asunción de proporcionar al suscriptor del acceso a Internet de alta velocidad al final que usa el modelo de Bridging del RFC1483 y la atmósfera como la estructura básica del núcleo. El contenido de este documento se basa en la arquitectura de los despliegues existentes y de algunas pruebas integradas.

Resumen de tecnología

El RFC1483 describe dos métodos distintos para llevar el tráfico de la interconexión de la red sin conexión sobre una red ATM: unidades de datos del protocolo de routing (PDU) y PDUs.

La encaminamiento permite la multiplexación de los protocolos múltiples sobre un solo circuito virtual ATM (VC). El protocolo de un PDU llevado es identificado prefijando el PDU con una encabezado del Logical Link Control (LLC) de IEEE 802.2.

El bridging realiza el protocolo de capa más alta que multiplexa implícito por los circuitos virtuales ATM. Para más información, refiera al RFC1483.

Este documento se refiere solamente a los PDUs.

Ventajas y desventajas de la conexión en puente de RFC1483

Lo que sigue es un resumen de las ventajas y desventajas de la arquitectura de Bridging del RFC1483. Esta arquitectura tiene algunas desventajas importantes, más cuyo sea inherente en el modelo de Bridging. Algunas de las desventajas fueron notadas durante las implementaciones de ADSL en los sitios del cliente.

Ventajas

  • Simple entender.

    El bridging es muy simple entender y implementar porque no hay temas complejos tales como encaminamiento o requisitos de autenticación para usuarios.

  • Configuración mínima del CPE.

    El proveedor de servicio considera que esto es importante porque ya no requiere una gran cantidad de rollos de cabezales y ya no necesita invertir en personal para brindar asistencia técnica sobre protocolos de mayor nivel. El CPE en modo de puente actúa como un dispositivo muy simple. El Troubleshooting mínimo está implicado en el CPE porque todo que viene adentro de los Ethernetes pasa directamente al lado de WAN.

  • Fácil instalar.

    La arquitectura de Bridging es fácil de instalar debido a su naturaleza simple. Después de que se establezcan los circuitos virtuales permanentes de extremo a extremo (PVC), las actividades tales como IP en los protocolos de la capa superiores llegan a ser transparentes.

  • Soporte multiprotocolo para el suscriptor.

    Cuando el CPE está en el Bridging Mode, no se refiere se está encapsulando a qué protocolo de la capa superior.

  • Ideal para el acceso a internet en un entorno de único usuario.

    Porque el CPE actúa como decodificador, el troubleshooting complejo no se requiere para los protocolos de la capa superiores. El extremo PC no requiere la instalación del cliente adicional.

Desventajas

  • El bridging depende pesadamente de los broadcasts para establecer la Conectividad.

    Los broadcasts entre miles de usuarios son intrínsecamente inaccesibles. Las razones de esto son que el broadcast consume el ancho de banda a través del loop xDSL de los usuarios, y el broadcast requiere los recursos en el router de centro distribuidor replicar los paquetes para el broadcast sobre (atmósfera PVC) los media de punto a punto.

  • El bridging es intrínsecamente inseguro y requiere un entorno confiable.

    Las contestaciones del Address Resolution Protocol (ARP) pueden ser spoofed y una dirección de red secuestrada. Además, los ataques del broadcast se pueden iniciar en la subred local, así negando el servicio a todos los miembros de la subred local.

  • El hijacking de la dirección IP es posible.

Consideraciones de Implementación

Considere las preguntas siguientes antes de implementar la arquitectura de Bridging del RFC1483.

  • ¿Cuál son la corriente y los números previstos de suscriptores que se mantendrán?

  • ¿Los suscriptores necesitan comunicar con uno a?

  • ¿Son estos suscriptores clientes residenciales de usuario único? ¿Usted mantiene a los clientes del oficina pequeña, oficina en el hogar (SOHO) que pudieron tener un pequeño LAN detrás del CPE?

  • ¿Cuál es el despliegue y el abastecimiento de CPE, los Digital Subscriber Line Access Multiplexer (DSLAM) y protocolos Post Office Protocol de la agregación (estallidos)?

  • ¿Son el Network Access Provider (SIESTA) y el Network Service Provider (NSP) la misma entidad? ¿El modelo comercial para la SIESTA también implica el vender de los servicios mayoristas tales como acceso corporativo seguro, y servicios de valor agregado tales como Voz y vídeo?

  • ¿El NSP quiere ofrecer las capacidades de selección de servicios?

  • ¿Cómo puede la contabilidad y facturación ser alcanzada? ¿Es por el uso, por el ancho de banda, o por el servicio?

  • ¿Está el modelo comercial de la compañía que de una portadora de intercambio local independiente (ILEC), del operador de centrales locales en condiciones de competencia (CLEC), o del Proveedor de servicios de Internet (ISP)?

  • ¿Qué tipos de aplicaciones el NSP quiere para ofrecer al final al suscriptor?

  • ¿Cuál es volumen del flujo de datos ambos en sentido ascendente y descendentes?

Con estas puntas consideradas, de siguiente son las descripciones de cómo la arquitectura de Bridging del RFC1483 cabrá y escalará a diversos modelos comerciales.

Arquitectura de red

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

Conexión en puente RFC1483 Arquitectura de red

Aspectos del diseño

Como se mencionó anteriormente, hay algunos problemas inherentes con la arquitectura de Bridging del RFC1483.

El Subscriber Bridging Feature IOS aborda algunos de estos problemas. La aplicación selectiva de las políticas de suscriptor a un Grupo de Bridge controla la inundación de los ARP, de los paquetes desconocidos, y de otros abajo de cada loop de ADSL. Por ejemplo, evitando que los ARP sean transmitidos, un usuario hostil no puede descubrir la dirección IP de otro usuario.

Otra solución es poner a todos los suscriptores en una sola subinterfaz. El comportamiento normal de Bridging no transmitirá a las tramas el puerto en el cual la trama fue recibida. Esencialmente, esto aplica un tipo de Subscriber Bridging en quien todos los paquetes entre los suscriptores se filtren. Sin embargo, este acercamiento tiene los defectos siguientes:

  • La política de suscriptor es solamente aplicada entre las subinterfaces. Para aplicar las políticas de suscriptor entre dos diversos usuarios, cada usuario debe estar en una diversa subinterfaz ATM.

  • Puesto que la correspondencia de direcciones de la capa 2-to-Layer 3 es docta (vía el ARP), los usuarios hostiles pueden todavía secuestrar la conexión de otros usuarios. Esto es hecha generando el tráfico ARP con la dirección IP de otro usuario y usando una diversa dirección MAC.

El segundo escenario es más serio para el portador o el ISP. En esta situación, cualquier usuario puede asignar la dirección incorrecta a un PC o el dispositivo asociado a Ethernet tal como una impresora, y causa los Problemas de conexión para otro usuario. Tales errores o ataques son duros de establecer claramente y de corregir porque el delincuente puede ser seguido solamente localizando la dirección MAC del delincuente.

Algunos portadores intentan trabajar alrededor de este problema segregando a los usuarios a través de los Grupos de Bridge, y implementando el Subscriber Bridging a través de las subinterfaces. En este caso cuando se requiere el Integrated Routing and Bridging (IRB), asignan cada usuario un Grupo de Bridge único y el (BVI) del Interfaz Virtual de Bridge Group. Este acercamiento utiliza dos interfaces por el suscriptor y puede ser desafiador manejar.

Estos problemas son abordados y resueltos en cierto modo por la característica del (RBE) del Routed Bridged Encapsulation que fue introducida en el Software Release 12.0(5)DC del ½ del ¿Â de Cisco IOSï en el Cisco 6400.

En vista de algunas de las desventajas del bridging, usted puede ser que se pregunte porqué la arquitectura de Bridging sería implementada nunca. La respuesta es simple. La mayor parte de ADSL CPEs instalado en el campo es capaz solamente de las tramas Bridged de la expedición. En estos casos, el NSP debe implementar el bridging.

Hoy, CPEs puede hacer el protocolo Point-to-Point sobre la atmósfera (PPPoA), el RFC1483 que interliga, y el rutear del RFC1483. El NSP determina si hacer el bridging o el PPP. La decisión se basa en las consideraciones de instrumentación mencionadas anterior, además de los pros - y - contra de cada arquitectura.

Incluso con las desventajas de la arquitectura de Bridging, puede ser conveniente para un pequeño ISP (que pueda no ser la SIESTA) o un NAP/NSP que sirve un número más pequeño de suscriptores. En estos escenarios, la SIESTA generalmente adelante todo el tráfico del suscriptor al ISP/NSP, que termina a esos suscriptores. La SIESTA podía elegir proporcionar el tráfico del suscriptor usando la atmósfera o el Frame Relay como el protocolo de la capa 2.

Las siestas usando la generación actual DSLAM pueden transportar solamente el tráfico del suscriptor usando la atmósfera. En este caso, el ISP debe terminar los circuitos virtuales permanentes atmósfera (PVC) a un router.

Si el ISP/NSP no tiene la interfaz ATM, una interfaz serial regular con el Interfaz de intercambio de datos (DXI) del ATM de encapsulado (posiblemente en un dispositivo adicional) se puede utilizar para validar los PDUs entrantes.

En ambos escenarios, el NSP/ISP puede tener que configurar el IRB en el router (excepto al usar el ATM de encapsulado DXI o en el caso de Puente transparente). Hoy, la mayoría de la práctica común para terminar a los suscriptores Bridged en el router NSP/ISP es implementar el IRB. (Se espera que los proveedores de servicio emigren gradualmente al RBE.)

Debido a algunas de las limitaciones mencionadas anteriormente, el NSP/ISP puede optar configurar a los grupos de Bridges diferentes para cada conjunto de los suscriptores o configurar a todos los suscriptores en un Grupo de Bridge. La práctica común es configurar a algunos Grupos de Bridge, y después configura a todos los suscriptores bajo interfaces multipunto separadas. Según lo mencionado anterior, los suscriptores bajo misma interfaz multipunto pueden no poder comunicar con uno a. Si la necesidad de ciertos usuarios de comunicar, configura a esos suscriptores bajo diversas interfaces (pueden todavía estar en el mismo Grupo de Bridge).

Para un pequeño ISP/NSP, la mayoría de los routeres comunes usados para terminar a los suscriptores Bridged son Cisco 3810, Cisco 3600, y Cisco 7200. Para un ISP/NSP con una base de suscriptores grande, se prefiere el Cisco 6400. Antes de calcular los requisitos de memoria para este Routers, considere los mismos factores que para cualquier otro entorno: número de usuarios, de ancho de banda, y de recursos del router.

Puntos principales de esta arquitectura

Los siguientes son los puntos claves de la arquitectura.

CPE

Cisco ofrece diverso CPEs que actúa con Cisco y el no Cisco DSLAM. La configuración para cada uno de estos CPEs es problema libre y no requiere ninguna entrada del suscriptor. El requisito principal es que el CPE define un identificador /virtual del canal del identificador del trayecto virtual ATM (VPI/VCI). Esto permite que el CPE entrene para arriba con el DSLAM y comience a pasar el tráfico. En la mayoría de los casos, la SIESTA opta configurar el mismo VPI/VCI para todos los suscriptores. De la SIESTA las PRE-disposiciones generalmente el CPE antes de desplegarlo en la ubicación del suscriptor.

En arquitectura de Bridging, la consideración principal para el CPE y su despliegue es cómo la SIESTA manejará el CPE después de que esté instalada en el campo. Esto es una preocupación porque el interligar no requiere una dirección IP para el CPE. Sin embargo, los Ciscos CPE pueden ser aprovisionado con una dirección IP en el Bridging Mode. La SIESTA puede utilizar esta característica a Telnet al CPE para recoger las estadísticas o para ayudar al suscriptor con el troubleshooting. Para permitir que CPEs sea manejado con los DSLAM, se está agregando la nueva funcionalidad del elemento proxy.

En el Bridging Mode, si no se asigna ningún IP Address de administración al CPE, el operador puede manejar solamente el CPE a través del puerto de administración del CPE. Si se asigna un IP Address de administración, el operador puede utilizar a un navegador del Hypertext Transfer Protocol (HTTP) para manejar el dispositivo. Sin embargo, esta opción no está generalmente disponible.

Cuando el CPE está en el Bridging Mode, el destino del servicio (que podría ser el NSP/ISP) debe proporcionar una dirección IP que sea utilizada como el default gateway para los PC detrás del CPE. Estos PC se deben fijar al gateway predeterminada correcta. Si no, incluso si se entrena el módem (que significa que la Capa física es buena entre el CPE y el DSLAM), el suscriptor puede no poder pasar el tráfico. Esto no es un problema si el Protocolo de configuración dinámica de host (DHCP) se utiliza para asignar los DHCP Address del suscriptor porque al servidor DHCP vuelve al router predeterminado.

Administración de IP

rfc_brdg_arch_2.gif

Conexión en puente RFC1483 Administración de IP

En un Bridged Environment, los IP Addresses son al final estaciones afectadas un aparato de un servidor DHCP situado en el destino del servicio, generalmente en la red NSP/ISP. Éste es el acercamiento más común y es implementado por la mayoría del NSPs/ISPs usando este modelo.

Otro acercamiento es proporcionar los IP Address estáticos a los suscriptores. En este caso, una subred de los IP Addresses o una sola dirección IP se afecta un aparato por el suscriptor, dependiendo de los requerimientos del suscriptor. Por ejemplo, los suscriptores que quieren al servidor Web del host A o a un servidor de correo electrónico necesitarán un conjunto de los IP Addresses bastante que una sola dirección IP. El problema con esto es que el NSP/ISP tiene que proporcionar a los IP Address públicos y puede ejecutarse rápidamente de ellos.

Algún NSPs/ISPs ha proporcionado a los IP Address privados a sus suscriptores. Entonces realizan el Network Address Translation (NAT) en el router del destino del servicio.

El NSPs/ISPs que proporciona una subred completa para un Grupo de Bridge (con más de un suscriptor) debe saber que un usuario puede asignar a la dirección incorrecta a un PC o a un dispositivo asociado a Ethernet, tal como una impresora, y causa los Problemas de conexión para otro usuario.

Es también posible que un NSP/ISP restrinja el número de PC que puedan acceder el servicio al mismo tiempo. Esto es hecha configurando a los Usuarios máximos en la interfaz de Ethernet.

Sin embargo, este método tiene el defecto siguiente. Si tres PC se configuran para utilizar el servicio y uno de los suscriptores agrega una impresora de red (que tenga su propia dirección MAC) durante una época en que uno de los PC está ocioso, la dirección MAC PC desaparecerá de la entrada ARP del CPE.

¿Si la impresora llega a ser activa mientras que un PC está ocioso, la impresora? el MAC address s será ingresado en la entrada ARP. Cuando un usuario decide utilizar este PC para acceder Internet, será inasequible porque el CPE ha permitido ya tres entradas MAC. La estrategia de limitación de usuarios en el CPE puede ser utilizada, pero el cuidado se debe admitir reparando los números.

Cómo se llega a un destino de servicio

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

Conexión en puente RFC1483 PVC de punta a punta

En una arquitectura PVC de punta a punta con el bridging, el destino del servicio es alcanzado por la creación de los PVC entre cada salto. Sin embargo, la Administración de estos PVC puede ser desafiadora para el NAP/NSP. Además, el número de PVC que se puedan definir a través de la nube ATM es limitado. Esta limitación afecta a muchas de las siestas/NSP que adoptan un modelo de punta a punta PVC. Para cada suscriptor habrá un fijo, conjunto único de VPIs/VCIs a lo largo de la trayectoria entera. Los circuitos virtuales conmutados (SVC) ayudan a superar algunos de estos problemas, y muchos proveedores de acceso están emigrando núcleo con capacidad IP a las redes para solucionar el problema del agotamiento del VC.

El NSP/ISP también tiene la opción de usar las funciones del gateway de selección de los servicios de Cisco (SSG) para proporcionar diversos servicios a los suscriptores.

En esta arquitectura, el acceso asegurado a un gateway corporativo es alcanzado terminando el PVC derecho del tráfico del suscriptor en el router corporativo en la capa 2. Las arquitecturas de PVC son intrínsecamente seguras al compartir los datos con los destinos del otro servicio.

Descripción de la funcionalidad

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

Conexión en puente RFC1483 Descripción de la funcionalidad

Los valores por defecto del CPE de Cisco 6xx al modo de ruteo. Por lo tanto, cuando se configura para el Bridging Mode y está instalado en la ubicación del suscriptor con los bifurcadores necesarios/los microfiltros, entrena para arriba automáticamente sobre el poder para arriba. Cuando el CPE entrena para arriba, indica que la Capa física entre el CPE y el DSLAM está muy bien. ¿Dependiendo cómo de la estación terminal? se configura la dirección IP s (es decir, si está asignado vía un servidor DHCP o es un IP Address estático con la información de gateway predeterminado), él puede entonces comunicar con el destino del servicio.

Lo que sigue es una descripción del flujo de paquetes.

Los datos de usuario se encapsulan en IEEE 802.3 del PC y ingresan el CPE del ½ 6xx del ¿Â de CiscoïÂ. Entonces se encapsulan en una encabezado del protocolo logical link control/subnetwork access (LLC/SNAP), que a su vez se encapsula en el ½ 5 (AAL5) del ¿Â del layerï de la adaptación ATM y se entrega a la capa ATM.

La tecnología de transmisión ADSL entonces modulan, la modulación o el Discrete Multi-Tone (DMT) de la Amplitud sin portadora y de la fase (CASQUILLO), y se envían a las células ATM sobre el alambre al DSLAM. En el DSLAM, estas señales moduladas primero son recibidas por el divisor de POTS, que marca debajo de si la frecuencia de la señal está o sobre 4 kHz. Después de que identifique las señales como sobre 4 kHz, las pasa a la unidad de transmisión ADSL - oficina central (ATU-C) en el DSLAM.

El ATU-C desmodula la señal y extrae a las células ATM, que entonces se pasan al Network Interface Cards (NIC) en el dispositivo de multiplexión (MUX). El NIC mira la información del VPI/VCI del lado del suscriptor en el encabezado ATM y toma la decisión de Switching a otro VPI/VCI que sean remitidos al router del destino del servicio. Después de que el router del destino del servicio reciba estas células en una interfaz ATM determinada, las vuelve a montar, mira la capa superior, y pasa la información a la interfaz BVI. La interfaz BVI mira la información de la capa 3 y decide a donde está ser entregada el paquete.

Conclusión

El modelo de Bridging del RFC1483 es más conveniente para ISP más pequeños o el acceso corporativo para los cuales el scalability no se convierta en un problema. Porque es muy simple entender y implementar, se ha convertido en la opción de muchos ISP más pequeños. Sin embargo, como resultado de alguna Seguridad y problemas de ampliación, la arquitectura de Bridging está perdiendo su renombre. El NSPs/ISPs está optando por el RBE o se está moviendo hacia el PPPoA o el pppoe, que son altamente scalable y muy seguros, pero más complejo y difícil implementar.


Información Relacionada


Document ID: 12916