Arquitectura de línea de base PPPoA

Introducción

Este documento describe una arquitectura ADSL (End-to-End Asymmetric Digital Subscriber Line) usando el modo de transferencia PPPoA (Protocol over Asynchronous). Aunque la mayoría de las implementaciones se basan en la arquitectura de Bridging, el PPPoA está ganando gran aceptación y representará un porcentaje mayor de implementaciones de ADSL en el futuro.

Suposición

La arquitectura de línea de base asume la necesidad de proporcionar acceso a Internet de alta velocidad y acceso corporativo al suscriptor final utilizando PPPoA como estructura básica principal. Analizaremos esta arquitectura en función de los canales virtuales privados (PVC), el método utilizado con más frecuencia en las implementaciones actuales. La arquitectura que utiliza circuitos virtuales conmutados (SVC) se tratará en un documento aparte.

Este documento se basa en implementaciones existentes, así como en pruebas internas de la arquitectura.

Este documento se escribió suponiendo que el lector está familiarizado con las consideraciones de diseño de un proveedor de acceso a la red (NAP), como se describe en el informe técnico RFC1483 Bridging Baseline Architecture.

Resumen de tecnología

El protocolo punto a punto (PPP) (RFC 1331) proporciona un método estándar para encapsular protocolos de capa superior en conexiones punto a punto. Amplía la estructura de paquetes de High-Level Data Link Control (HDLC) con un identificador de protocolo de 16 bits que contiene información sobre el contenido del paquete.

El paquete contiene tres tipos de información:

• Protocolo de control de enlaces (LCP): negocia los parámetros de enlace, el tamaño del paquete o el tipo de autenticación

• Protocolo de control de red (NCP): contiene información sobre protocolos de capa superior, incluidos IP e IPX, y sus protocolos de control (IPCP para IP).

• Tramas de datos que contienen datos

PPP sobre capa 5 de adaptación ATM (AAL5) (RFC 2364) utiliza AAL5 como protocolo entramado, que admite tanto PVC como SVC. PPPoA se implementó principalmente como parte de ADSL. Se basa en RFC1483, que funciona en el modo LLC-SNAP o VC-Mux. Un dispositivo de equipo en las instalaciones del cliente (CPE) encapsula la sesión PPP basada en este RFC para el transporte a través del loop ADSL y el multiplexor de acceso a la línea del suscriptor digital (DSLAM).

Ventajas y desventajas de la arquitectura PPPoA

La arquitectura PPPoA hereda la mayor parte de las ventajas de PPP utilizadas en el modelo Dial. A continuación se enumeran algunos de los puntos clave.

Ventajas

• Autenticación por sesión basada en el protocolo de autenticación de contraseña (PAP) o el protocolo de autenticación por desafío mutuo (CHAP). Esta es la mayor ventaja de PPPoA, ya que la autenticación supera el agujero de seguridad en una arquitectura de conexión en puente.

• La contabilización por sesión es posible, lo que permite al proveedor de servicios cargar al suscriptor en función del tiempo de sesión por los diversos servicios ofrecidos. La contabilización por sesión permite a un proveedor de servicios ofrecer un nivel de acceso mínimo por un cargo mínimo y luego cobrar a los suscriptores por los servicios adicionales utilizados.

• Conservación de direcciones IP en el CPE. Esto permite al proveedor de servicios asignar sólo una dirección IP para un CPE, con el CPE configurado para la traducción de direcciones de red (NAT). Todos los usuarios detrás de un CPE pueden utilizar una única dirección IP para llegar a diferentes destinos. La sobrecarga de administración de IP para el proveedor de acceso de red/proveedor de servicios de red (NAP/NSP) para cada usuario individual se reduce al tiempo que se conservan las direcciones IP. Además, el proveedor de servicios puede proporcionar una subred pequeña de direcciones IP para superar las limitaciones de la traducción de direcciones de puerto (PAT) y NAT.

• Los NAP/NSP proporcionan acceso seguro a los gateways corporativos sin administrar PVC de extremo a extremo y utilizar el routing de capa 3 o los túneles de protocolo de reenvío de capa 2/protocolo de túnel de capa 2 (L2F/L2TP). Por lo tanto, pueden ampliar sus modelos de negocio para vender servicios al por mayor.

• Solución de problemas de suscriptores individuales. El NSP puede identificar fácilmente qué suscriptores están activos o desactivados en función de las sesiones PPP activas, en lugar de solucionar problemas de grupos enteros, como ocurre con la arquitectura de conexión en puente.

• El NSP puede suscribirse de forma excesiva implementando tiempos de espera inactivos y de sesión mediante un servidor de servicio de usuario de acceso telefónico de autenticación remota (RADIUS) estándar del sector para cada suscriptor.

• Altamente escalable ya que podemos terminar un número muy alto de sesiones PPP en un router de agregación. La autenticación, la autorización y la contabilización se pueden manejar para cada usuario mediante servidores RADIUS externos.

• Uso óptimo de las funciones del gateway de selección de servicios (SSG).

Desventajas

• Sólo una sesión por CPE en un canal virtual (VC). Dado que el nombre de usuario y la contraseña se configuran en el CPE, todos los usuarios detrás del CPE para ese VC particular pueden acceder sólo a un conjunto de servicios . Los usuarios no pueden seleccionar diferentes conjuntos de servicios, aunque es posible utilizar varios VC y establecer diferentes sesiones PPP en diferentes VC.

• Mayor complejidad de la configuración de CPE. El personal del soporte técnico del proveedor de servicios debe estar más informado. Dado que el nombre de usuario y la contraseña están configurados en el CPE, el suscriptor o el proveedor del CPE deberán realizar cambios en la configuración. El uso de varios VC aumenta la complejidad de la configuración. Esto, sin embargo, puede ser superado por una función de configuración automática que aún no se ha lanzado.

• El proveedor de servicios debe mantener una base de datos de nombres de usuario y contraseñas para todos los suscriptores. Si se utilizan túneles o servicios de proxy, la autenticación se puede realizar en función del nombre de dominio y la autenticación de usuario se realiza en el gateway corporativo. Esto reduce el tamaño de la base de datos que el proveedor de servicios debe mantener.

• Si se proporciona una única dirección IP al CPE y se implementa NAT/PAT, ciertas aplicaciones como IPTV, que incrustan información IP en la carga útil, no funcionarán. Además, si se utiliza una función de subred IP, también se debe reservar una dirección IP para el CPE.

Consideraciones de instrumentación para la arquitectura PPPoA

Los puntos clave que se deben tener en cuenta antes de implementar la arquitectura PPPoA son:

• El número de suscriptores que serán atendidos actualmente y en el futuro, ya que esto afecta el número de sesiones PPP requeridas.

• Si las sesiones PPP finalizan en el router de agregación del proveedor de servicios o se reenvían a otros gateways corporativos o proveedores de servicios de Internet (ISP).

• Si el proveedor de servicios o el destino final del servicio proporcionan la dirección IP al CPE del suscriptor.

• Si las direcciones IP proporcionadas son públicas o privadas legales. ¿El CPE va a hacer NAT/PAT o se realizará NAT en el destino de terminación?

• Perfiles de suscriptores finales, usuarios residenciales, clientes de pequeñas oficinas domésticas (SOHO) y teletrabajadores.

• En el caso de más de un usuario, si todos los usuarios necesitan alcanzar el mismo destino o servicio final, o si todos tienen destinos de servicio diferentes.

• ¿El proveedor de servicios proporciona algún servicio de valor añadido como voz o vídeo? ¿El proveedor de servicios requiere que todos los suscriptores primero se dirijan a una red determinada antes de alcanzar un destino final? Cuando los suscriptores utilizan SSG, ¿van a utilizar servicios de paso a través de PPP Terminated Aggregation (PTA), un dispositivo de mediación o proxy?

• Cómo factura el proveedor de servicios a los suscriptores, en función de una tarifa plana, el uso por sesión o los servicios utilizados.

• Implementación y aprovisionamiento de CPE, DSLAM y puntos de presencia de agregación (POP).

• El modelo de negocio para el NAP. ¿El modelo también incluye la venta de servicios al por mayor como acceso corporativo seguro y servicios de valor añadido como voz y vídeo? ¿Son los NAP y los NSP la misma entidad?

• El modelo de negocio de la empresa. ¿Es comparable con un operador de intercambio local (ILEC) independiente, un operador de intercambio local competitivo (CLEC) o un ISP?

• Los tipos de aplicaciones que el NSP ofrecerá al suscriptor final.

• El volumen previsto de flujo de datos ascendente y descendente.

Teniendo en cuenta estos puntos, analizaremos cómo se adaptará la arquitectura PPPoA a los diferentes modelos de negocio para los proveedores de servicios y cómo los proveedores pueden beneficiarse de esta arquitectura.

Arquitectura de red PPPoA típica

El siguiente diagrama muestra una arquitectura de red PPPoA típica. Los clientes que utilizan CPE se conectan a la red del proveedor de servicios a través de un Cisco DSLAM, que se conecta a un agregador Cisco 6400 mediante ATM.

Consideraciones de diseño para la arquitectura PPPoA

En la sección "Consideraciones de implementación" de este documento, las arquitecturas PPPoA se pueden implementar utilizando diferentes escenarios dependiendo del modelo de negocio del proveedor de servicios. En esta sección, analizaremos las diferentes posibilidades y consideraciones que los proveedores de servicios deben tener en cuenta antes de implementar una solución.

Antes de implementar una arquitectura PPPoA y una solución específica para esta arquitectura, es esencial comprender el modelo empresarial del proveedor de servicios. Considere los servicios que ofrecerá el proveedor de servicios. ¿Ofrecerá el proveedor de servicios un servicio como el acceso a Internet de alta velocidad a sus suscriptores finales o venderá servicios al por mayor a diferentes ISP y proporcionará servicios de valor añadido a esos suscriptores? ¿El proveedor de servicios les ofrecerá a todos?

En el caso de acceso a Internet de alta velocidad en un entorno donde el NSP y el NAP son iguales, las sesiones PPP del suscriptor deben terminar en el router de agregación implementado. En esta situación, los proveedores de servicios deben considerar cuántas sesiones PPP pueden terminar en un único dispositivo de agregación de router, cómo se autenticarán los usuarios, cómo se realizará la contabilidad y la trayectoria a Internet una vez que se terminen las sesiones de usuario. Según el número de sesiones PPP y suscriptores, el router de agregación podría ser un Cisco 6400 o un Cisco 7200. Cisco 6400 de hoy en día con procesadores de rutas de 7 nodos (NRP) puede finalizar hasta 14 000 sesiones PPP. El Cisco 7200 se limita a 2000 sesiones PPP. Estos números cambiarán con las nuevas versiones. Compruebe las notas de la versión y los documentos del producto para ver el número exacto de sesiones que puede admitir cada router de agregación.

La mejor forma de gestionar la autenticación y la contabilización de usuarios en este escenario es mediante un servidor RADIUS estándar del sector, que puede autenticar a un usuario basándose en el nombre de usuario o el identificador de ruta virtual/identificador de canal virtual (VPI/VCI) que se utiliza.

Para el acceso a Internet de alta velocidad, los NSP suelen facturar a los clientes una tarifa plana. La mayoría de las implementaciones actuales se están implementando de esta manera. Cuando NSP y NAP son la misma entidad, se factura a los clientes a un tipo fijo para el acceso y a otra tasa fija para el acceso a Internet. Este modelo cambia cuando el proveedor de servicios comienza a ofrecer servicios de valor añadido. Los proveedores de servicios pueden cobrar al cliente en función del tipo de servicio y la duración del servicio utilizado. Los clientes se conectan a Internet a través del router de agregación mediante protocolos de routing como Open Shortest Path First (OSPF) o Enhanced Interior Gateway Routing Protocol (EIGRP) a un router de borde que podría estar ejecutando Border Gateway Protocol (BGP).

Otra opción que tiene el proveedor de servicios para proporcionar acceso a Internet de alta velocidad es reenviar las sesiones PPP entrantes de los suscriptores a un ISP independiente usando la tunelización L2TP/L2F. Cuando se utiliza la tunelización L2x, se debe tener especialmente en cuenta cómo se puede alcanzar el destino del túnel. Las opciones disponibles son ejecutar algunos protocolos de ruteo o proporcionar rutas estáticas en el router de agregación. Las limitaciones al utilizar túneles L2TP o L2F son: (1) el número de túneles y el número de sesiones que pueden admitirse en dichos túneles; y (2) el uso de protocolos de ruteo incompatibles con los ISP de terceros, que pueden requerir el uso de rutas estáticas.

Si el proveedor de servicios ofrece servicios para diferentes ISP o gateways corporativos al suscriptor final, es posible que necesiten implementar funciones SSG en el router de agregación. Esto permite al suscriptor seleccionar destinos de servicio diferentes mediante la selección de servicio basada en Web. El proveedor de servicios puede reenviar las sesiones PPP de los suscriptores a sus destinos seleccionados mediante la combinación de todas las sesiones destinadas al ISP en un único PVC para transporte, o si el proveedor de servicios ofrece varios niveles de servicio, se podría establecer más de un PVC a través del núcleo.

En un modelo de servicio al por mayor, el proveedor de servicios no puede utilizar funciones SSG. En este modelo, el proveedor de servicios extiende todas las sesiones PPP a los gateways de inicio. Los gateways de inicio proporcionan direcciones IP al suscriptor final y autentican al usuario final.

Una consideración importante en cualquiera de estos escenarios es cómo el proveedor de servicios puede ofrecer una calidad de servicio (QoS) diferente para los diferentes servicios y cómo calculan la asignación de ancho de banda. Actualmente, la forma en que la mayoría de los proveedores de servicios implementan esta arquitectura ofrece diferentes QoS en diferentes PVC. Es posible que tengan PVC separados en el núcleo para los clientes residenciales y empresariales. El uso de diferentes PVC permite a los proveedores de servicios especificar diferentes QoS para diferentes servicios. De esta manera, QoS podría estar en PVC separados o en la Capa 3.

La aplicación de QoS en la capa 3 requiere que el proveedor de servicios conozca el destino final, lo que podría ser un factor limitante. Pero, si se utiliza en combinación con QoS de capa 2 (aplicándola en diferentes VC), puede ser útil para el proveedor de servicios. La limitación de este modelo es que es fijo y el proveedor de servicios necesita aprovisionar QoS por adelantado. QoS no se aplica dinámicamente en la selección del servicio. Actualmente, no hay opción para que un usuario seleccione diferentes anchos de banda para diferentes servicios con un solo clic del ratón; sin embargo, se han realizado importantes esfuerzos de ingeniería para desarrollar esta función.

La implementación, la gestión y el aprovisionamiento de CPE podrían resultar muy complicados en esta arquitectura, ya que el CPE debe configurarse para nombres de usuario y contraseñas. Como solución sencilla, algunos proveedores de servicios utilizan el mismo nombre de usuario y contraseña para todos los CPE. Esto presenta un riesgo de seguridad significativo. Además, si el CPE necesita abrir simultáneamente diferentes sesiones, es necesario aprovisionar VC adicionales en el CPE, NAP y NSP. Los DSLAM y los dispositivos de agregación de Cisco pueden simplificar la configuración y el aprovisionamiento de CPE. Las herramientas de gestión de flujo también están disponibles para el aprovisionamiento integral de PVC. El aprovisionamiento en el NSP para tantos suscriptores que utilizan PVC es un factor limitante, ya que se deben administrar todos los diferentes PVC. Además, no existe una forma sencilla de aprovisionar 2000 PVC en un único NRP haciendo clic con el ratón o introduciendo algunas teclas.

Hoy en día tenemos diferentes aplicaciones de gestión para los diferentes componentes de esta arquitectura, como Viewrunner para el DSLAM y SCM para el Cisco 6400. No hay una única plataforma de gestión que proporcione todos los componentes. Se trata de una limitación reconocida y se está haciendo un gran esfuerzo para disponer de una única aplicación de gestión completa para aprovisionar CPE, DSLAM y Cisco 6400. Además, actualmente tenemos una solución para implementar PPPoA con SVC, lo que facilitará enormemente la implementación. PPPoA con SVC también permitirá a los usuarios finales seleccionar el destino y QoS dinámicamente.

Otro punto importante que se debe tener en cuenta para las implementaciones de ADSL de gran tamaño que utilizan esta arquitectura es la comunicación del router de agregación al servidor RADIUS. Si el blade NRP falla cuando varios miles de sesiones PPP terminan en un dispositivo de agregación, todas esas sesiones PPP deben restablecerse. Esto significa que todos los suscriptores deben ser autenticados y sus registros contables se detienen y se reinician una vez que se establece la conexión. Cuando tantos suscriptores tratan de autenticarse al mismo tiempo, la canalización al servidor RADIUS puede ser un cuello de botella. Es posible que algunos suscriptores no puedan autenticarse y esto puede crear problemas para el proveedor de servicios.

Es muy importante tener un link al servidor RADIUS con suficiente ancho de banda para alojar a todos los suscriptores al mismo tiempo. Además, el servidor RADIUS debe ser lo suficientemente potente como para conceder permisos a todos los suscriptores. En el caso de miles de suscriptores, se debe considerar una opción para balancear la carga entre los servidores RADIUS disponibles. Esta función está disponible en Cisco IOS® Software.

Como consideración final, el router de agregación debe funcionar lo suficiente para acomodar muchas sesiones PPP. Aplique los mismos principios de ingeniería de tráfico utilizados por otras implementaciones. Anteriormente, el usuario tenía que configurar los PVC en subinterfaces punto a punto. Actualmente, PPPoA permite a los usuarios configurar varios PVC en subinterfaces multipunto así como punto a punto. Cada conexión PPPoA ya no requiere dos bloques de descriptor de interfaz (IDB), uno para la interfaz de acceso virtual y otro para la subinterfaz ATM. Esta mejora aumenta el número máximo de sesiones PPPoA que se ejecutan en un router.

El número máximo de sesiones PPPoA soportadas en una plataforma depende de los recursos del sistema disponibles, como la memoria y la velocidad de la CPU. Cada sesión PPPoA toma una interfaz de acceso virtual. Cada interfaz de acceso virtual consta de un bloque descriptor de interfaz de hardware y un par de bloque descriptor de interfaz de software (hwidb/swidb). Cada switch toma aproximadamente 4.500. Cada switch tarda unos 2,5 K. Juntos, las interfaces de acceso virtual requieren 7,500. Las 2000 interfaces de acceso virtual requieren 2000 * 7.5K o 15M. Para ejecutar 2000 sesiones, un router necesita un 15M adicional. Debido al aumento en el límite de sesión, el router necesita soportar más IDB. Este soporte afecta el rendimiento debido a que hay más ciclos de CPU para ejecutar más instancias de la máquina de estado PPP.

Puntos clave de la arquitectura PPPoA

Esta sección describe tres puntos clave en la arquitectura PPPoA: CPE, IP Management y alcanzar el destino del servicio.

Debido a la naturaleza de PAT, ciertas aplicaciones que incrustan información IP en la carga útil no pueden funcionar en este escenario. Para resolver este problema, aplique una subred de direcciones IP en lugar de una sola dirección IP.

En esta arquitectura, es más fácil para NAP/NSP conectar Telnet en el CPE para configurar y resolver problemas, ya que una dirección IP se asigna al CPE.

Los CPE pueden utilizar diferentes opciones dependiendo del perfil del suscriptor. Por ejemplo, para un usuario residencial, el CPE se puede configurar sin PAT/DHCP. Para los suscriptores con más de un PC, los CPE se pueden configurar para PAT/DHCP o de la misma manera que para un usuario residencial. Si hay un teléfono IP conectado al CPE, el CPE se puede configurar para más de un PVC.

Administración de IP

En la arquitectura PPPoA, la asignación de dirección IP para el CPE del suscriptor utiliza la negociación IPCP, el mismo principio de PPP en el modo de marcado. Las direcciones IP se asignan en función del tipo de servicio que utiliza un suscriptor. Si el suscriptor sólo tiene acceso a Internet desde el NSP, el NSP terminará esas sesiones PPP del suscriptor y asignará una dirección IP. La dirección IP se asigna desde un conjunto definido localmente, un servidor DHCP o se puede aplicar desde el servidor RADIUS. Además, es posible que el ISP haya proporcionado un conjunto de direcciones IP estáticas al suscriptor y no pueda asignar direcciones IP dinámicamente cuando el suscriptor inicia la sesión PPP. En esta situación, el proveedor de servicios utilizará sólo el servidor RADIUS para autenticar al usuario.

Si el suscriptor prefiere tener varios servicios disponibles, es posible que el NSP necesite implementar SSG. A continuación se muestran las posibilidades de asignar direcciones IP.

• El SP puede proporcionar una dirección IP al suscriptor a través de su pool local o servidor RADIUS. Después de que el usuario seleccione un servicio, el SSG reenvía el tráfico del usuario a ese destino. Si el SSG utiliza el modo proxy, el destino final puede proporcionar una dirección IP, que el SSG utilizará como dirección visible para NAT.

• Las sesiones PPP no finalizan en el router de agregación del proveedor de servicios. Se tunelizan o se reenvían al gateway de destino final o al gateway de inicio, que finalmente terminará las sesiones PPP. El gateway de destino final o de inicio negocia IPCP con el suscriptor, proporcionando así una dirección IP dinámicamente. Las direcciones estáticas también son posibles siempre y cuando el destino final haya asignado esas direcciones IP y tenga una ruta hacia ellas.

Antes de Cisco IOS Software Release 12.0.5DC para Cisco 6400 NRP, no había manera de que el proveedor de servicios proporcionara una subred de direcciones IP al suscriptor. La plataforma Cisco 6400 y los CPE de la serie Cisco 600 permiten que las subredes IP se configuren dinámicamente en el CPE durante la negociación PPP. Una dirección IP de esta subred se asigna al CPE y las direcciones IP restantes se asignan dinámicamente a las estaciones a través de DHCP. Cuando se utiliza esta función, no es necesario configurar CPE para PAT, que no funciona con algunas aplicaciones.

Cómo se llega al destino de servicio

En las arquitecturas PPPoA, el destino del servicio se puede alcanzar de diferentes maneras. Algunos de los métodos más implementados son:

• Finalización de sesiones PPP en el proveedor de servicios

• Tunelización L2TP

• Uso de SSG

En los tres métodos hay un conjunto fijo de PVC definidos desde el CPE al DSLAM que se conmuta a un conjunto fijo de PVC en el router de agregación. Los PVC se mapean desde el DSLAM al router de agregación a través de una nube ATM.

El destino del servicio también se puede alcanzar usando otros métodos como PPPoA con SVC, o Multiprotocol Label Switching/Virtual Private Network. Estos métodos están fuera del alcance del presente documento y se examinarán en documentos separados.

Finalización de PPP en la Agregación

Las sesiones PPP iniciadas por el suscriptor se terminan en el proveedor de servicio que autentica a los usuarios usando una base de datos local en el router o a través de los servidores RADIUS. Después de autenticar al usuario, se realiza la negociación IPCP y la dirección IP se asigna al CPE. Una vez asignada la dirección IP, hay una ruta de host establecida tanto en el CPE como en el router de agregación. Las direcciones IP asignadas al suscriptor, si son legales, se anuncian al router de borde. El router de borde es el gateway a través del cual el suscriptor puede acceder a Internet. Si las direcciones IP son privadas, el proveedor de servicios las traduce antes de anunciarlas al router de borde.

Tunelización L2TP/L2F

Las sesiones PPP, en función del proveedor de servicios o la corporación, se conectan al punto de terminación ascendente mediante L2TP o L2F en lugar de terminarse en el router de agregación del proveedor de servicios. Este punto de terminación autentica el nombre de usuario y al suscriptor se le asigna una dirección IP a través de DHCP o un conjunto local. Para este escenario, normalmente hay un túnel establecido entre el concentrador de acceso L2TP/servidor de acceso a la red (LAC/NAS) y el gateway residencial o el servidor de red L2TP (LNS). El LAC autentica la sesión entrante basándose en el nombre de dominio; el nombre de usuario se autentica en el gateway de destino final o de inicio.

En este modelo, sin embargo, el usuario sólo puede tener acceso al destino final y sólo puede acceder a un destino a la vez. Por ejemplo, si el CPE se configura con un nombre de usuario de rtr@cisco.com, los PC detrás de ese CPE sólo pueden tener acceso al dominio de Cisco. Si desean conectarse a otra red corporativa, deben cambiar el nombre de usuario y la contraseña en el CPE para reflejar ese nombre de dominio corporativo. En este caso, el destino del túnel se alcanza mediante un protocolo de ruteo, rutas estáticas o IP clásica sobre ATM (si se prefiere el ATM como Capa 2).

Uso de Service Selection Gateway (SSG)

La principal ventaja de SSG sobre la tunelización es que SSG proporciona la asignación de servicios uno a varios, mientras que la tunelización sólo proporciona la asignación uno a uno. Esto resulta muy útil cuando un único usuario necesita acceder a varios servicios o cuando varios usuarios en una única ubicación necesitan acceder a un servicio único. SSG utiliza el panel de selección de servicios (SSD) basado en Web, que consta de distintos servicios y está disponible para el usuario. El usuario puede acceder a uno o varios servicios a la vez. Otra ventaja de utilizar SSG es que el proveedor de servicios puede facturar al usuario en función de los servicios utilizados y el tiempo de sesión, y el usuario puede activar y desactivar los servicios a través de la SSD.

Los usuarios se autentican cuando la sesión PPP llega de los suscriptores. A los usuarios se les asignan direcciones IP desde el grupo local o el servidor RADIUS. Después de que un usuario se autentica correctamente, el código SSG crea un objeto de origen y se le da acceso a una red predeterminada. La red predeterminada contiene el servidor SSD. Con un explorador, el usuario inicia sesión en el Panel, es autenticado por el servidor AAA y, según el perfil del usuario almacenado en el servidor RADIUS, se le ofrece un conjunto de servicios a los que acceder.

Cada vez que un usuario autenticado selecciona un servicio, el SSG crea un objeto de destino para ese usuario. El objeto de destino contiene información como la dirección de destino, la dirección del servidor DNS para ese destino y la dirección IP de origen asignada desde el gateway de inicio. Los paquetes que llegan del lado del usuario se reenvían al destino según la información contenida en el objeto de destino.

SSG se puede configurar para el servicio proxy, el paso a través transparente o PTA. Cuando un suscriptor solicita acceso a un servicio proxy, el NRP-SSG pasará la solicitud de acceso al servidor RADIUS remoto. Al recibir access-accept, el SSG responde al suscriptor con access-accept. El SSG aparece como un cliente en el servidor RADIUS remoto.

El paso a través transparente permite que el tráfico del suscriptor no autenticado se rutee a través del SSG en cualquier dirección. Utilice filtros para controlar el tráfico de paso transparente.

Los usuarios de tipo PPP sólo pueden utilizar PTA. La autenticación, autorización y contabilidad se realiza exactamente como en el tipo de servicio proxy. Un suscriptor inicia sesión en un servicio usando un nombre de usuario del formulario user@service. El SSG lo reenvía al servidor RADIUS, que luego carga el perfil de servicio al SSG. El SSG reenvía la solicitud al servidor RADIUS remoto según lo especificado por el atributo de servidor RADIUS del perfil de servicio. Después de autenticar la solicitud, se asigna una dirección IP al suscriptor. No se realiza NAT. Todo el tráfico de usuarios se agrega a la red remota. Con PTA, los usuarios pueden acceder a un solo servicio y no tendrán acceso a la red predeterminada o a la SSD.

Descripción del funcionamiento de la arquitectura PPPoA

Cuando el CPE se enciende por primera vez, comienza a enviar solicitudes de configuración LCP al servidor de agregación. El servidor de agregación, con los PVC configurados, también envía la solicitud de configuración de LCP en una interfaz de acceso virtual (asociada con el PVC). Cuando cada uno ve la solicitud de configuración del otro, reconoce las solicitudes y se abre el estado LCP.

Para la etapa de autenticación, el CPE envía la solicitud de autenticación al servidor de agregación. El servidor, dependiendo de su configuración, autentica al usuario según el nombre de dominio (si se suministra) o el nombre de usuario usando su base de datos local o servidores RADIUS. Si la solicitud del suscriptor se encuentra en la forma de username@domainname, el servidor de agregación intentará crear un túnel al destino, si uno no está ya allí. Después de crear el túnel, el servidor de agregación reenvía las solicitudes PPP del suscriptor al destino. El destino, a su vez, autentica al usuario y asigna una dirección IP. Si la solicitud del suscriptor no incluye el nombre de dominio, la base de datos local autentica al usuario. Si SSG está configurado en el router de agregación, el usuario puede acceder a la red predeterminada según se ha especificado y puede obtener una opción para seleccionar diferentes servicios.

Conclusión

PPPoA se está convirtiendo en la arquitectura más adecuada para muchos proveedores de servicios porque es altamente escalable, utiliza la funcionalidad SSG y proporciona seguridad. Dado que el objetivo de este artículo era la arquitectura PPPoA, no fue posible cubrir en profundidad características como SSG. Estas funciones se tratarán en documentos posteriores. Las configuraciones de muestra para los diferentes escenarios que se tratan en este documento también se presentarán y explicarán en documentos independientes.

Información Relacionada

• Información de soporte de producto de Cisco DSL
• Soporte Técnico - Cisco Systems