RFC1483 Arquitectura de línea de base de puente

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 ha diseñado suponiendo proporcionar acceso a Internet de alta velocidad al suscriptor final utilizando el modelo de conexión en puente RFC1483 y ATM como estructura básica principal. El contenido de este documento se basa en la arquitectura de las implementaciones existentes y en algunas pruebas internas.

Resumen de tecnología

RFC1483 describe dos métodos diferentes para transportar tráfico de interconexión de red sin conexión a través de una red ATM: unidades de datos de protocolo ruteadas (PDU) y PDU puenteadas.

El routing permite la multiplexación de varios protocolos en un único circuito virtual ATM (VC). El protocolo de una PDU transportada se identifica mediante el prefijo de la PDU con un encabezado de control de link lógico (LLC) IEEE 802.2.

El puente realiza la multiplexación de protocolo de capa superior implícitamente por los circuitos virtuales ATM. Para obtener más información, consulte RFC1483.

Este documento se refiere solamente a PDU puenteadas.

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

A continuación se muestra un resumen de las ventajas y desventajas de la arquitectura de conexión en puente RFC1483. Esta arquitectura tiene algunas desventajas importantes, la mayoría inherentes al modelo de conexión en puente. Algunas de las desventajas se observaron durante las implementaciones de ADSL en las instalaciones de los clientes.

Ventajas

• Sencillo de entender.

  La conexión en puente es muy sencilla de comprender e implementar, ya que no hay problemas complejos como los requisitos de routing o autenticación para los 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. La solución de problemas mínima está involucrada en el CPE porque todo lo que llega de Ethernet pasa directamente al lado de la WAN.

• Fácil de instalar.

  La arquitectura de puentes es fácil de instalar debido a su naturaleza simplista. Después de establecer circuitos virtuales permanentes (PVC) de extremo a extremo, las actividades como la IP en los protocolos de capa superior se vuelven transparentes.

• Compatibilidad multiprotocolo para el suscriptor.

  Cuando el CPE está en modo de conexión en puente, no le preocupa qué protocolo de capa superior se está encapsulando.

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

  Debido a que el CPE actúa como decodificador, no se requiere una resolución de problemas compleja para los protocolos de capa superior. Los PC finales no requieren instalación de cliente adicional.

Desventajas

• El puente depende en gran medida de las transmisiones para establecer la conectividad.

  Las transmisiones entre miles de usuarios son inherentemente poco escalables. Las razones de esto son que la transmisión consume ancho de banda a través del loop xDSL de los usuarios, y la difusión requiere recursos en el router de cabecera para replicar paquetes para los medios de broadcast sobre punto a punto (PVC ATM).

• El puente es inherentemente inseguro y requiere un entorno de confianza.

  Las respuestas del protocolo de resolución de direcciones (ARP) se pueden falsificar y se puede secuestrar una dirección de red. Además, se pueden iniciar ataques de difusión en la subred local, denegando así el servicio a todos los miembros de la subred local.

• El secuestro de direcciones IP es posible.

Consideraciones de Implementación

Tenga en cuenta las siguientes preguntas antes de implementar la arquitectura de conexión en puente RFC1483.

• ¿Cuáles son los números actuales y previstos de suscriptores a los que se debe prestar servicio?

• ¿Los suscriptores necesitan comunicarse entre sí?

• ¿Estos suscriptores son clientes residenciales de un solo usuario? ¿Presta servicios a clientes de pequeñas oficinas y oficinas domésticas (SOHO) que pueden tener una pequeña LAN detrás del CPE?

• ¿Cuál es la implementación y el aprovisionamiento de CPE, multiplexores de acceso de línea de suscriptor digital (DSLAM) y protocolos de oficina de correo (POP) de agregación?

• ¿Son el proveedor de acceso a la red (NAP) y el proveedor de servicios de red (NSP) la misma entidad? ¿El modelo de negocio del NAP también implica la venta de servicios al por mayor como el acceso corporativo seguro y servicios de valor añadido como voz y vídeo?

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

• ¿Cómo se pueden conseguir la contabilidad y la facturación? ¿Es por uso, ancho de banda o por servicio?

• ¿El modelo de negocio de la empresa es el de un operador de intercambio local (ILEC) independiente, un operador de intercambio local (CLEC) competitivo o un proveedor de servicios de Internet (ISP)?

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

• ¿Qué es el volumen del flujo de datos tanto en sentido ascendente como descendente?

Teniendo en cuenta estos puntos, a continuación se describen cómo la arquitectura de conexión en puente RFC1483 se adaptará y ampliará a diferentes modelos de negocio.

Arquitectura de red

Conexión en puente RFC1483 Arquitectura de red

Aspectos del diseño

Como se mencionó anteriormente, hay algunos problemas inherentes con la arquitectura de conexión en puente RFC1483.

La función de conexión en puente del suscriptor IOS aborda algunos de estos problemas. La aplicación selectiva de políticas de suscriptor a un grupo de bridges controla la inundación de ARP, paquetes desconocidos y otros en cada loop ADSL. Por ejemplo, al impedir que se emitan ARP, un usuario hostil no puede detectar la dirección IP de otro usuario.

Otra solución es colocar a todos los suscriptores en una sola subinterfaz. El comportamiento de bridging normal no reenviará tramas al puerto en el que se recibió la trama. Básicamente, esto aplica un tipo de conexión en puente de suscriptores en el que se filtran todos los paquetes entre suscriptores. Sin embargo, este enfoque presenta los siguientes defectos:

• La política del suscriptor sólo se aplica entre subinterfaces. Para aplicar políticas de suscriptor entre dos usuarios diferentes, cada usuario debe estar en una subinterfaz ATM diferente.

• Dado que se aprende la asignación de direcciones de capa 2 a capa 3 (a través de ARP), los usuarios hostiles todavía pueden secuestrar la conexión de otros usuarios. Esto se hace generando tráfico ARP con la dirección IP de otro usuario y utilizando una dirección MAC diferente.

El segundo escenario es más grave para el portador o ISP. En esta situación, cualquier usuario puede asignar la dirección incorrecta a un PC o dispositivo conectado a Ethernet, como una impresora, y causar problemas de conexión a otro usuario. Esos errores o ataques son difíciles de identificar y corregir, ya que sólo se puede rastrear al delincuente rastreando la dirección MAC del delincuente.

Algunos operadores tratan de solucionar este problema segregando a los usuarios entre los grupos de bridges e implementando el bridging de suscriptores entre las subinterfaces. En este caso, cuando se requiere routing y puente integrados (IRB), se asigna a cada usuario un grupo de puente único y una interfaz virtual de grupo de puente (BVI). Este enfoque utiliza dos interfaces por suscriptor y puede resultar difícil de administrar.

Estos problemas se resuelven de alguna manera mediante la función Routed Bridged Encapsulation (RBE) que se introdujo en la versión 12.0(5)DC del software Cisco IOS® en el Cisco 6400.

Teniendo en cuenta algunas de las desventajas de la conexión en puente, puede que se pregunte por qué la arquitectura de conexión en puente alguna vez se implementaría. La respuesta es simple. La mayoría de los CPE ADSL instalados en el campo sólo pueden reenviar tramas puenteadas. En estos casos, el NSP debe implementar el bridging.

Hoy en día, los CPE pueden realizar el protocolo punto a punto sobre ATM (PPPoA), el puente RFC1483 y el routing RFC1483. El NSP determina si se debe hacer bridging o PPP. La decisión se basa en las consideraciones de implementación mencionadas anteriormente, además de los pros y los contras de cada arquitectura.

Incluso con las desventajas de la arquitectura de conexión en puente, puede ser adecuada para un ISP pequeño (que puede no ser el NAP) o un NAP/NSP que atienda a un número menor de suscriptores. En estos escenarios, el NAP generalmente reenvía todo el tráfico del suscriptor al ISP/NSP, que termina con esos suscriptores. El NAP podría optar por proporcionar tráfico de suscriptor mediante ATM o Frame Relay como protocolo de Capa 2.

Los NAP que utilizan DSLAM de generación actual sólo pueden transportar tráfico de suscriptores mediante ATM. En este caso, el ISP debe finalizar los circuitos virtuales permanentes (PVC) ATM en un router.

Si el ISP/NSP no tiene la interfaz ATM, se puede utilizar una interfaz serial normal con encapsulación ATM Data Exchange Interface (DXI) (posiblemente en un dispositivo adicional) para aceptar las PDU con puente entrantes.

En ambos escenarios, el NSP/ISP puede tener que configurar el IRB en el router (excepto cuando se usa encapsulation ATM DXI o en el caso de conexión en puente transparente). Hoy en día, la práctica más común para terminar los suscriptores puenteados en el router NSP/ISP es implementar IRB. (Se espera que los proveedores de servicios migren gradualmente a RBE).

Debido a algunas de las limitaciones mencionadas anteriormente, el NSP/ISP puede optar por configurar grupos de puente independientes para cada conjunto de suscriptores o configurar todos los suscriptores en un grupo de puente. La práctica común es configurar algunos grupos de puente y luego configurar todos los suscriptores en interfaces multipunto separadas. Como se mencionó anteriormente, los suscriptores de la misma interfaz multipunto pueden no poder comunicarse entre sí. Si ciertos usuarios necesitan comunicarse, configure esos suscriptores bajo diferentes interfaces (todavía pueden estar en el mismo grupo de puentes).

Para un ISP/NSP pequeño, los routers más comunes utilizados para finalizar suscriptores con puente son los 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 estos routers, considere los mismos factores que para cualquier otro entorno: número de usuarios, ancho de banda y recursos de router.

Puntos principales de esta arquitectura

A continuación se muestran los puntos clave de la arquitectura.

CPE

Cisco ofrece varios CPE que funcionan con DSLAM de Cisco y de otros fabricantes. La configuración para cada uno de estos CPE está libre de problemas y no requiere ninguna entrada del suscriptor. El requisito principal es que el CPE defina un identificador de trayecto virtual ATM/identificador de canal virtual (VPI/VCI). Esto permite al CPE capacitarse con el DSLAM y comenzar a pasar tráfico. En la mayoría de los casos, el NAP opta por configurar el mismo VPI/VCI para todos los suscriptores. El NAP suele preaprovisionar el CPE antes de implementarlo en la ubicación del suscriptor.

En la arquitectura de conexión en puente, la principal consideración para el CPE y su implementación es cómo el NAP administrará el CPE después de que se instale en el campo. Esto es un problema porque el bridging no requiere una dirección IP para el CPE. Sin embargo, los CPE de Cisco se pueden aprovisionar con una dirección IP en el modo de conexión en puente. El NAP puede utilizar esta función para comunicarse a través de Telnet con el CPE para recopilar estadísticas o para ayudar al suscriptor a resolver problemas. Para permitir que los CPE se administren a través de los DSLAM, se agrega nueva funcionalidad de elemento proxy.

En el modo de conexión en puente, si no se asigna ninguna dirección IP de administración al CPE, el operador sólo puede administrar el CPE a través del puerto de administración del CPE. Si se asigna una dirección IP de administración, el operador puede utilizar un explorador de protocolo de transferencia de hipertexto (HTTP) para administrar el dispositivo. Sin embargo, esta opción generalmente no está disponible.

Cuando el CPE está en modo de conexión en puente, el destino del servicio (que podría ser el NSP/ISP) debe proporcionar una dirección IP que se utilizará como gateway predeterminado para los PC detrás del CPE. Estos PC deben configurarse en el gateway predeterminado correcto. De lo contrario, incluso si el módem está entrenado (lo que significa que la capa física es buena entre el CPE y el DSLAM), es posible que el suscriptor no pueda pasar tráfico. Este no es un problema si se utiliza el protocolo de configuración dinámica de host (DHCP) para asignar direcciones DHCP del suscriptor porque el router predeterminado es devuelto por el servidor DHCP.

Administración de IP

Conexión en puente RFC1483 Administración de IP

En un entorno puenteado, las direcciones IP son asignadas a las estaciones finales por un servidor DHCP ubicado en el destino del servicio, generalmente en la red NSP/ISP. Este es el enfoque más común y es implementado por la mayoría de los proveedores de servicios de Internet/proveedores de servicios de Internet que utilizan este modelo.

Otro enfoque es proporcionar direcciones IP estáticas a los suscriptores. En este caso, se asigna una subred de direcciones IP o una única dirección IP por suscriptor, según los requisitos del suscriptor. Por ejemplo, los suscriptores que deseen alojar un servidor Web o un servidor de correo electrónico necesitarán un conjunto de direcciones IP en lugar de una única dirección IP. El problema con esto es que el NSP/ISP tiene que proporcionar direcciones IP públicas y puede quedarse sin ellas rápidamente.

Algunos NSP/ISP han proporcionado direcciones IP privadas a sus suscriptores. A continuación, realizan la traducción de direcciones de red (NAT) en el router de destino del servicio.

Los NSP/ISP que proporcionan una subred completa para un grupo de bridges (con más de un suscriptor) deben saber que un usuario puede asignar la dirección incorrecta a un PC o dispositivo conectado a Ethernet, como una impresora, y causar problemas de conexión para otro usuario.

También es posible que un NSP/ISP restrinja el número de PC que pueden acceder al servicio a la vez. Esto se hace configurando el número máximo de usuarios en la interfaz Ethernet.

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

Si la impresora se activa mientras un PC está inactivo, se ingresará la dirección MAC de la impresora en la entrada ARP. Cuando un usuario decide utilizar este PC para acceder a Internet, no estará disponible porque el CPE ya ha permitido tres entradas MAC. Se puede utilizar la estrategia de limitar los usuarios en el CPE, pero se debe tener cuidado al fijar los números.

Cómo se llega a un destino de servicio

Conexión en puente RFC1483 PVC de extremo a extremo

En una arquitectura PVC de extremo a extremo con conexión en puente, el destino del servicio se alcanza mediante la creación de PVC entre cada salto. Sin embargo, la administración de estos PVC puede ser un reto para el NAP/NSP. Además, el número de PVC que se pueden definir a través de la nube ATM es limitado. Esta limitación afecta a muchos de los NAP/NSP que adoptan un modelo de PVC de extremo a extremo. Para cada suscriptor habrá un conjunto fijo y único de VPI/VCI a lo largo de toda la trayectoria. Los circuitos virtuales conmutados (SVC) ayudan a superar algunos de estos problemas, y muchos proveedores de acceso están migrando a redes de núcleo habilitadas para IP para resolver el problema del agotamiento de los VC.

El NSP/ISP también tiene la opción de utilizar la función Cisco Service Selection Gateway (SSG) para proporcionar diferentes servicios a los suscriptores.

En esta arquitectura, el acceso seguro a un gateway corporativo se logra terminando el PVC de tráfico del suscriptor directamente en el router corporativo en la Capa 2. Las arquitecturas basadas en PVC son inherentemente seguras cuando se comparten datos con otros destinos de servicio.

Descripción de la funcionalidad

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

El CPE 6xx de Cisco adopta de forma predeterminada el modo de routing. Por lo tanto, cuando se configura para el modo de conexión en puente e se instala en la ubicación del suscriptor con los divisores/microfiltros necesarios, se entrena automáticamente al encenderse. Cuando el CPE se entrena, indica que la capa física entre el CPE y el DSLAM está bien. Según cómo se configure la dirección IP de la estación final (es decir, si se asigna a través de un servidor DHCP o si es una dirección IP estática con información de gateway predeterminada), puede comunicarse con el destino del servicio.

A continuación se muestra una descripción del flujo de paquetes.

Los datos del usuario se encapsulan en IEEE 802.3 desde el PC e ingresan en el CPE 6xx de Cisco. Luego se encapsula en un encabezado Logical Link Control/Subnetwork Access Protocol (LLC/SNAP), que a su vez se encapsula en la capa 5 de adaptación ATM (AAL5) y se entrega a la capa ATM.

A continuación, las celdas ATM se modulan mediante la tecnología de transmisión ADSL, la modulación de amplitud sin portadora y fase (CAP) o el multitono discreto (DMT), y se envían a través del cable al DSLAM. En el DSLAM, estas señales moduladas son recibidas primero por el divisor POTS, que verifica si la frecuencia de la señal es inferior o superior a 4 kHz. Después de identificar las señales como las que se encuentran por encima de 4 kHz, las pasa a la Unidad de transmisión ADSL - Oficina central (ATU-C) en el DSLAM.

El ATU-C desmonta la señal y recupera las celdas ATM, que luego se pasan a la tarjeta de interfaz de red (NIC) en el dispositivo de multiplexación (MUX). La NIC observa la información VPI/VCI del lado del suscriptor en el encabezado ATM y toma la decisión de conmutación a otro VPI/VCI que será reenviado al router de destino del servicio. Después de que el router de destino de servicio recibe estas celdas en una interfaz ATM determinada, las reensambla, mira la capa superior y pasa la información a la interfaz BVI. La interfaz BVI observa la información de la Capa 3 y decide dónde se enviará el paquete.

Conclusión

El modelo de conexión en puente RFC1483 es más adecuado para los ISP más pequeños o el acceso corporativo para los que la escalabilidad no se convierte en un problema. Como es muy fácil de entender e implementar, se ha convertido en la elección de muchos ISP más pequeños. Sin embargo, como resultado de algunos problemas de seguridad y escalabilidad, la arquitectura de conexión en puente está perdiendo popularidad. Los NSP/ISP están optando por el RBE o se mueven hacia PPPoA o PPPoE, que son altamente escalables y muy seguros, pero más complejos y difíciles de implementar.

Información Relacionada

• Soporte técnico de DSL
• Soporte Técnico - Cisco Systems