Arquitetura de linha de base PPPoA

Introduction

Este documento descreve uma arquitetura fim-a-fim da Asymmetric Digital Subscriber Line (ADSL) usando o Point-to-Point Protocol over Asynchronous Transfer Mode (PPPoA). Embora a maioria das implementações seja baseada na arquitetura de Bridging, o PPPoA está ganhando uma popularidade tremenda e formará uma parcela maior das implementações de ADSL futuras.

Hipótese

A arquitetura de linha de base assume a necessidade de fornecer acesso à Internet de alta velocidade e acesso corporativo ao assinante final usando PPPoA como o backbone central. Discutiremos essa arquitetura com base em PVCs (private virtual channels, canais virtuais privados), o método usado com mais frequência nas implantações atuais. A arquitetura usando circuitos virtuais comutados (SVCs) será discutida em um artigo separado.

Este documento baseia-se em implantações existentes e em testes internos da arquitetura.

Este documento foi escrito com a suposição de que o leitor tem conhecimento e familiaridade com as considerações de projeto de um provedor de acesso à rede (NAP), conforme descrito no white paper RFC1483 Bridging Baseline Architecture.

Resumo técnico

O Protocolo Ponto a Ponto (PPP - Point-to-Point Protocol) (RFC 1331) fornece um método padrão de encapsulamento de protocolos de camada superior através de conexões ponto a ponto. Ele estende a estrutura de pacotes HDLC (High-Level Data Link Control) com um identificador de protocolo de 16 bits que contém informações sobre o conteúdo do pacote.

O pacote contém três tipos de informações:

• Link Control Protocol (LCP) - negocia parâmetros de link, tamanho do pacote ou tipo de autenticação

• Network Control Protocol (NCP) - contém informações sobre protocolos de camada superior incluindo IP e IPX e seus protocolos de controle (IPCP para IP)

• Quadros de dados contendo dados

O PPP sobre a camada de adaptação ATM 5 (AAL5) (RFC 2364) usa AAL5 como o protocolo enquadrado, que suporta PVC e SVC. O PPPoA foi implementado principalmente como parte do ADSL. Ele depende do RFC1483, operando no modo Logical Link Control-Subnetwork Access Protocol (LLC-SNAP) ou VC-Mux. Um dispositivo CPE (Customer Premises Equipment, equipamento das instalações do cliente) encapsula a sessão PPP com base nesse RFC para transporte através do loop ADSL e do DSLAM (Digital Subscriber Line Access Multiplexer, multiplexador de acesso de linha de assinante digital).

Vantagens e desvantagens da arquitetura PPPoA

A arquitetura PPPoA herda a maioria das vantagens do PPP usado no modelo de discagem. Alguns dos pontos principais estão listados abaixo.

Vantagens

• Autenticação por sessão com base no PAP (Password Authentication Protocol Protocolo de Autenticação de Senha) ou CHAP (Challenge Handshake Authentication Protocol Protocolo de Autenticação de Handshake de Desafio). Essa é a maior vantagem do PPPoA, pois a autenticação supera o buraco de segurança em uma arquitetura de bridging.

• A contabilidade por sessão é possível, o que permite ao provedor de serviços cobrar o assinante com base no tempo de sessão para vários serviços oferecidos. A contabilidade por sessão permite que um provedor de serviços ofereça um nível de acesso mínimo para taxa mínima e depois cobre aos assinantes pelos serviços adicionais usados.

• Conservação de endereço IP no CPE. Isso permite que o provedor de serviços atribua apenas um endereço IP para um CPE, com o CPE configurado para conversão de endereço de rede (NAT). Todos os usuários por trás de um CPE podem usar um único endereço IP para alcançar diferentes destinos. A sobrecarga de gerenciamento de IP para o provedor de acesso à rede/provedor de serviços de rede (NAP/NSP) para cada usuário individual é reduzida enquanto conserva endereços IP. Além disso, o provedor de serviços pode fornecer uma pequena sub-rede de endereços IP para superar as limitações da conversão de endereço de porta (PAT) e NAT.

• Os NAPs/NSPs fornecem acesso seguro a gateways corporativos sem gerenciar PVCs de ponta a ponta e usando roteamento de Camada 3 ou túneis de Encaminhamento de Camada 2/Protocolo de Encapsulamento de Camada 2 (L2F/L2TP). Por conseguinte, podem expandir os seus modelos de negócio para a venda de serviços grossistas.

• Troubleshooting de assinantes individuais. O NSP pode identificar facilmente quais assinantes estão ligados ou desligados com base em sessões PPP ativas, em vez de solucionar problemas de grupos inteiros, como é o caso da arquitetura de bridging.

• O NSP pode assinar em excesso ao implantar intervalos ociosos e de sessão usando um servidor RADIUS (Remote Authentication Dial-In User Service) padrão do setor para cada assinante.

• Altamente escalável, pois podemos encerrar um número muito alto de sessões PPP em um roteador de agregação. A autenticação, autorização e contabilização podem ser tratadas para cada usuário usando servidores RADIUS externos.

• Uso ideal dos recursos no Service Selection Gateway (SSG).

Desvantagens

• Apenas uma única sessão por CPE em um canal virtual (VC). Como o nome de usuário e a senha são configurados no CPE, todos os usuários por trás do CPE para esse VC específico podem acessar apenas um conjunto de serviços . Os usuários não podem selecionar diferentes conjuntos de serviços, embora seja possível usar vários VCs e estabelecer sessões PPP diferentes em VCs diferentes.

• Maior complexidade da configuração do CPE. O pessoal do help desk no provedor de serviços precisa ter mais conhecimento. Como o nome de usuário e a senha estão configurados no CPE, o assinante ou o fornecedor do CPE precisará fazer alterações na configuração. O uso de vários VCs aumenta a complexidade da configuração. Isso, no entanto, pode ser superado por um recurso de configuração automática que ainda não foi lançado.

• O provedor de serviços precisa manter um banco de dados de nomes de usuário e senhas para todos os assinantes. Se forem usados túneis ou serviços proxy, a autenticação poderá ser feita com base no nome do domínio e a autenticação do usuário será feita no gateway corporativo. Isso reduz o tamanho do banco de dados que o provedor de serviços precisa manter.

• Se um único endereço IP for fornecido ao CPE e NAT/PAT for implementado, alguns aplicativos como IPTV, que incorporam informações de IP no payload, não funcionarão. Além disso, se um recurso de sub-rede IP for usado, um endereço IP também deverá ser reservado para o CPE.

Considerações sobre a implementação da arquitetura PPPoA

Os pontos principais a serem considerados antes da implementação da arquitetura PPPoA incluem:

• O número de assinantes que serão atendidos no momento e no futuro, pois isso afeta o número de sessões PPP necessárias.

• Se as sessões PPP estão sendo terminadas no roteador de agregação do provedor de serviços ou encaminhadas para outros gateways corporativos ou provedores de serviços de Internet (ISPs).

• Se o provedor de serviços ou o destino final do serviço está fornecendo o endereço IP para o CPE do assinante.

• Se os endereços IP fornecidos são públicos ou privados legais. O CPE vai fazer NAT/PAT ou o NAT será executado no destino de terminação?

• Perfis de assinantes finais, usuários residenciais, clientes de escritórios domésticos de pequeno porte (SOHO) e trabalhadores à distância.

• No caso de mais de um usuário, se todos os usuários precisam alcançar o mesmo destino ou serviço final ou se todos têm destinos de serviço diferentes.

• O provedor de serviços está fornecendo algum serviço de valor agregado, como voz ou vídeo? O provedor de serviços exige que todos os assinantes acessem primeiro uma rede específica antes de alcançar um destino final? Quando os assinantes usam SSG, eles vão usar serviços de passagem, PTA (PPP Terminated Aggregation), um dispositivo de mediação ou proxy?

• Como o provedor de serviços cobra os assinantes — com base em uma taxa fixa, uso por sessão ou serviços usados.

• Implantação e provisionamento de CPEs, DSLAMs e pontos de agregação de presença (POPs).

• O modelo de negócios do NAP. O modelo também inclui a venda por atacado de serviços como acesso corporativo seguro e serviços de valor agregado, como voz e vídeo? Os NAPs e os NSPs são a mesma entidade?

• O modelo de negócios da empresa. É comparável a uma transportadora de câmbio local independente (ILEC), uma transportadora de troca local competitiva (CLEC) ou um ISP?

• Os tipos de aplicativos que o NSP oferecerá ao assinante final.

• O volume upstream e downstream antecipado do fluxo de dados.

Tendo esses pontos em mente, discutiremos como a arquitetura PPPoA se ajusta e se adapta a diferentes modelos de negócios para provedores de serviços e como os provedores podem se beneficiar usando essa arquitetura.

Arquitetura típica de rede PPPoA

O diagrama a seguir mostra uma arquitetura de rede PPPoA típica. Os clientes que usam CPEs se conectam à rede do provedor de serviços através de um Cisco DSLAM, que se conecta a um agregador Cisco 6400 usando ATM.

Considerações sobre design da arquitetura PPPoA

Na seção "Considerações de implementação" deste documento, as arquiteturas PPPoA podem ser implantadas usando cenários diferentes, dependendo do modelo de negócios do provedor de serviços. Nesta seção, discutiremos as diferentes possibilidades e considerações que os provedores de serviços devem ter em mente antes de implantar uma solução.

Antes de implantar uma arquitetura PPPoA e uma solução específica para essa arquitetura, é essencial entender o modelo de negócios do provedor de serviços. Considere os serviços que o provedor de serviços oferecerá. O prestador de serviços oferecerá um serviço como o acesso à Internet de alta velocidade aos seus assinantes finais ou venderá serviços grossistas a diferentes ISPs e fornecerá serviços de valor acrescentado a esses assinantes? O provedor de serviços oferecerá todos eles?

No caso de acesso à Internet de alta velocidade em um ambiente em que o NSP e o NAP são iguais, as sessões PPP do assinante devem ser terminadas no roteador de agregação implantado. Neste cenário, os provedores de serviços precisam considerar quantas sessões PPP podem ser terminadas em um único dispositivo de agregação de roteador, como os usuários serão autenticados, como eles executarão a contabilidade e o caminho para a Internet quando as sessões de usuário forem terminadas. Dependendo do número de sessões PPP e assinantes, o roteador de agregação pode ser um Cisco 6400 ou um Cisco 7200. O Cisco 6400 atual com 7 processadores de rota de nós (NRPs) pode terminar até 14.000 sessões PPP. O Cisco 7200 é limitado a 2.000 sessões PPP. Esses números mudarão com novas versões. Verifique as notas de versão e os documentos do produto para saber o número exato de sessões que cada roteador de agregação pode suportar.

A autenticação e a contabilização de usuários neste cenário são melhor tratadas usando um servidor RADIUS padrão do setor, que pode autenticar um usuário com base no nome de usuário ou no identificador de caminho virtual/identificador de canal virtual (VPI/VCI) sendo usado.

Para acesso à Internet de alta velocidade, os NSPs geralmente faturam aos clientes uma taxa única. A maioria das implantações atuais está sendo implementada dessa forma. Quando o NSP e o NAP são a mesma entidade, os clientes são cobrados a uma taxa fixa para acesso e outra taxa fixa para acesso à Internet. Esse modelo muda quando o provedor de serviços começa a oferecer serviços de valor agregado. Os provedores de serviços podem cobrar do cliente com base no tipo de serviço e na duração do serviço. Os clientes se conectam à Internet através do roteador de agregação usando protocolos de roteamento como OSPF (Open Shortest Path First) ou EIGRP (Enhanced Interior Gateway Routing Protocol) a um roteador de borda que pode estar executando BGP (Border Gateway Protocol).

Outra opção que o provedor de serviços tem para fornecer acesso à Internet de alta velocidade é encaminhar as sessões de PPP recebidas dos assinantes para um ISP separado usando encapsulamento L2TP/L2F. Quando o tunelamento L2x é usado, deve-se considerar especialmente como o destino do túnel pode ser alcançado. As opções disponíveis são executar alguns protocolos de roteamento ou fornecer rotas estáticas no roteador de agregação. As limitações ao usar túneis L2TP ou L2F são: 1) O número de túneis e o número de sessões que podem ser suportadas nesses túneis; e (2) o uso de protocolos de roteamento incompatíveis com ISPs de terceiros, o que pode exigir o uso de rotas estáticas.

Se o provedor de serviços oferecer serviços para diferentes ISPs ou gateways corporativos para o assinante final, ele pode precisar implementar os recursos SSG no roteador de agregação. Isso permite que o assinante selecione diferentes destinos de serviço usando a seleção de serviço baseada na Web. O provedor de serviços pode encaminhar sessões PPP de assinantes para seus destinos selecionados combinando todas as sessões destinadas ao ISP em um único PVC para transporte ou, se o provedor de serviços oferecer vários níveis de serviço, mais de um PVC poderia ser estabelecido através do núcleo.

Em um modelo de serviço de atacado, o provedor de serviços não pode usar os recursos SSG. Nesse modelo, o provedor de serviços estende todas as sessões PPP para os gateways domésticos. Os gateways domésticos fornecem endereços IP ao assinante final e autenticam o usuário final.

Uma consideração importante em qualquer um desses cenários é como o provedor de serviços pode oferecer uma qualidade de serviço (QoS) diferente para diferentes serviços e como eles calculam a alocação de largura de banda. Atualmente, a maneira como a maioria dos provedores de serviços implanta essa arquitetura oferece QoS diferente em PVCs diferentes. Eles podem ter PVCs separados no núcleo para clientes residenciais e comerciais. O uso de PVCs diferentes permite que os provedores de serviços especifiquem QoS diferentes para serviços diferentes. Dessa forma, a QoS pode estar em PVCs separados ou na Camada 3.

A aplicação da QoS na camada 3 exige que o provedor de serviços conheça o destino final, o que pode ser um fator limitante. Mas, se usado em combinação com a QoS da camada 2 (aplicando-a em VCs diferentes), pode ser útil para o provedor de serviços. A limitação desse modelo é que ele é fixo e o provedor de serviços precisa provisionar a QoS com antecedência. A QoS não é aplicada dinamicamente na seleção do serviço. Atualmente, não há opção para um usuário selecionar diferentes larguras de banda para diferentes serviços com um clique do mouse; no entanto, foi investido um esforço significativo de engenharia para desenvolver esse recurso.

A implantação, o gerenciamento e o provisionamento do CPE podem ser muito desafiadores nessa arquitetura, pois o CPE precisa ser configurado para nomes de usuário e senhas. Como uma solução simples, alguns provedores de serviços estão usando o mesmo nome de usuário e senha para todos os CPEs. Isso apresenta um risco de segurança significativo. Além disso, se o CPE precisa abrir sessões diferentes simultaneamente, VCs adicionais precisam ser provisionados no CPE, NAP e NSP. Os DSLAMs e dispositivos de agregação da Cisco têm a capacidade de simplificar a configuração e o provisionamento do CPE. As ferramentas de gerenciamento de passagem de fluxo também estão disponíveis para provisionamento completo de PVC. O provisionamento no NSP para tantos assinantes que usam PVCs é um fator limitante, pois todos os PVCs diferentes devem ser gerenciados. Além disso, não há uma maneira simples de provisionar 2000 PVCs em um único NRP, clicando em um mouse ou inserindo alguns pressionamentos de tecla.

Hoje temos diferentes aplicativos de gerenciamento para diferentes componentes dessa arquitetura, como o Viewrunner para DSLAM e SCM para o Cisco 6400. Não há uma única plataforma de gerenciamento que provisione todos os componentes. Essa é uma limitação bem reconhecida e um grande esforço está sendo investido para ter um único aplicativo de gerenciamento abrangente para provisionar o CPE, DSLAM e o Cisco 6400. Além disso, atualmente temos uma solução para implementar PPPoA com SVC, o que facilitará muito a implantação. O PPPoA com SVC também permitirá que os usuários finais selecionem o destino e a QoS dinamicamente.

Outro ponto importante a ser lembrado para grandes implantações ADSL usando essa arquitetura é a comunicação do roteador de agregação ao servidor RADIUS. Se o blade NRP falhar quando vários milhares de sessões PPP são terminadas em um dispositivo de agregação, todas essas sessões PPP devem ser restabelecidas. Isso significa que todos os assinantes devem ser autenticados e seus registros contábeis parados e reiniciados assim que a conexão for estabelecida. Quando tantos assinantes tentam se autenticar ao mesmo tempo, o pipe para o servidor RADIUS pode ser um gargalo. Alguns assinantes podem não ser autenticados e isso pode criar problemas para o provedor de serviços.

É muito importante ter um link para o servidor RADIUS com largura de banda suficiente para acomodar todos os assinantes ao mesmo tempo. Além disso, o servidor RADIUS deve ser potente o suficiente para conceder permissões a todos os assinantes. No caso de milhares de assinantes, deve ser considerada uma opção de balanceamento de carga entre os servidores RADIUS disponíveis. Este recurso está disponível no software Cisco IOS®.

Como uma consideração final, o roteador de agregação deve ter desempenho suficiente para acomodar muitas sessões PPP. Aplique os mesmos princípios de engenharia de tráfego usados por outras implementações. Anteriormente, o usuário tinha que configurar PVCs em subinterfaces ponto-a-ponto. Hoje, o PPPoA permite que os usuários configurem vários PVCs em subinterfaces multiponto, bem como ponto a ponto. Cada conexão PPPoA não exige mais dois blocos descritores de interface (IDBs), um para a interface de acesso virtual e um para a subinterface ATM. Essa melhoria aumenta o número máximo de sessões PPPoA em execução em um roteador.

O número máximo de sessões PPPoA suportadas em uma plataforma depende dos recursos disponíveis do sistema, como memória e velocidade da CPU. Cada sessão PPPoA usa uma interface de acesso virtual. Cada interface de acesso virtual consiste em um bloco descritor de interface de hardware e um par de bloco descritor de interface de software (hwidb/swidb). Cada hwidb leva cerca de 4,5 mil. Cada swidb leva cerca de 2,5 K. Juntas, as interfaces de acesso virtual exigem 7,5 K. 2000 interfaces de acesso virtual exigem 2000 * 7,5 K ou 15 M. Para executar 2000 sessões, um roteador precisa de 15M adicionais. Devido ao aumento no limite de sessão, o roteador precisa suportar mais IDBs. Esse suporte afeta o desempenho devido a mais ciclos de CPU para executar mais instâncias do computador de estado PPP.

Pontos chave da arquitetura PPPoA

Esta seção descreve três pontos principais na arquitetura PPPoA: o CPE, o gerenciamento de IP e o destino do serviço.

Devido à natureza do PAT, certos aplicativos que incorporam informações de IP no payload não podem funcionar neste cenário. Para resolver esse problema, aplique uma sub-rede de endereços IP em vez de um único endereço IP.

Nessa arquitetura, é mais fácil para o NAP/NSP fazer Telnet no CPE configurar e solucionar problemas, já que um endereço IP é atribuído ao CPE.

Os CPEs podem usar opções diferentes dependendo do perfil do assinante. Por exemplo, para um usuário residencial, o CPE pode ser configurado sem PAT/DHCP. Para assinantes com mais de um PC, os CPEs podem ser configurados para PAT/DHCP ou da mesma forma que um usuário residencial. Se houver um telefone IP conectado ao CPE, o CPE poderá ser configurado para mais de um PVC.

Gerenciamento de IP

Na arquitetura PPPoA, a alocação de endereço IP para o CPE do assinante usa negociação IPCP, o mesmo princípio do PPP no modo de discagem. Os endereços IP são alocados dependendo do tipo de serviço que um assinante usa. Se o assinante tiver apenas acesso à Internet do NSP, o NSP encerrará essas sessões PPP do assinante e atribuirá um endereço IP. O endereço IP é alocado de um pool definido localmente, um servidor DHCP ou pode ser aplicado a partir do servidor RADIUS. Além disso, o ISP pode ter fornecido um conjunto de endereços IP estáticos para o assinante e pode não atribuir endereços IP dinamicamente quando o assinante inicia a sessão PPP. Neste cenário, o provedor de serviços usará apenas o servidor RADIUS para autenticar o usuário.

Se o assinante preferir ter vários serviços disponíveis, o NSP pode precisar implementar o SSG. A seguir estão as possibilidades de atribuição de endereços IP.

• A controladora de armazenamento pode fornecer um endereço IP ao assinante através de seu pool local ou servidor RADIUS. Depois que o usuário seleciona um serviço, o SSG encaminha o tráfego do usuário para esse destino. Se o SSG estiver usando o modo proxy, o destino final pode fornecer um endereço IP, que o SSG usará como o endereço visível para NAT.

• As sessões PPP não são terminadas no roteador de agregação do provedor de serviços. Eles são encapsulados ou encaminhados para o destino final ou gateway local, que terminará as sessões PPP. O destino final ou gateway local negocia IPCP com o assinante, fornecendo assim um endereço IP dinamicamente. Os endereços estáticos também são possíveis, desde que o destino final tenha alocado esses endereços IP e tenha uma rota para eles.

Antes do Cisco IOS Software Release 12.0.5DC para o Cisco 6400 NRP, não havia como o provedor de serviços fornecer uma sub-rede de endereços IP ao assinante. A plataforma Cisco 6400 e os CPEs da série Cisco 600 permitem que as sub-redes IP sejam configuradas dinamicamente no CPE durante a negociação do PPP. Um endereço IP dessa sub-rede é atribuído ao CPE e os endereços IP restantes são alocados dinamicamente para as estações através do DHCP. Quando esse recurso é usado, os CPEs não precisam ser configurados para PAT, o que não funciona com alguns aplicativos.

Como o destino de serviço é alcançado

Nas arquiteturas PPPoA, o destino do serviço pode ser alcançado de diferentes maneiras. Alguns dos métodos implantados com mais frequência são:

• Terminando sessões PPP no provedor de serviços

• Encapsulamento L2TP

• Usando SSG

Em todos os três métodos, há um conjunto fixo de PVCs definido do CPE para o DSLAM que é comutado para um conjunto fixo de PVCs no roteador de agregação. Os PVCs são mapeados do DSLAM para o roteador de agregação através de uma nuvem ATM.

O destino do serviço também pode ser alcançado usando outros métodos, como PPPoA com SVCs ou Multiprotocol Label Switching/Virtual Private Network. Esses métodos estão além do escopo deste documento e serão discutidos em documentos separados.

Terminando PPP na agregação

As sessões PPP iniciadas pelo assinante são terminadas no provedor de serviços que autentica os usuários usando um banco de dados local no roteador ou através de servidores RADIUS. Depois que o usuário é autenticado, a negociação IPCP ocorre e o endereço IP é atribuído ao CPE. Depois que o endereço IP tiver sido atribuído, há uma rota de host estabelecida no CPE e no roteador de agregação. Os endereços IP atribuídos ao assinante, se legais, são anunciados ao roteador de borda. O roteador de borda é o gateway através do qual o assinante pode acessar a Internet. Se os endereços IP forem privados, o provedor de serviços os converterá antes de anunciá-los ao roteador de borda.

Encapsulamento L2TP/L2F

As sessões PPP, dependendo do provedor de serviços ou da corporação, fazem um túnel até o ponto de terminação upstream usando L2TP ou L2F em vez de serem terminadas no roteador de agregação do provedor de serviços. Esse ponto de terminação autentica o nome de usuário e o assinante recebe um endereço IP por DHCP ou um pool local. Para esse cenário, geralmente há um túnel estabelecido entre o L2TP Access Concentrator/Network Access Server (LAC/NAS) e o gateway residencial ou o L2TP Network Server (LNS). O LAC autentica a sessão de entrada com base no nome do domínio; o nome de usuário é autenticado no destino final ou no gateway residencial.

Nesse modelo, no entanto, o usuário só pode ter acesso ao destino final e pode acessar apenas um destino por vez. Por exemplo, se o CPE estiver configurado com um nome de usuário rtr@cisco.com, os PCs por trás desse CPE só poderão ter acesso ao domínio Cisco. Se eles quiserem se conectar a outra rede corporativa, precisarão alterar o nome de usuário e a senha no CPE para refletir esse nome de domínio corporativo. O destino do túnel nesse caso é alcançado usando um protocolo de roteamento, rotas estáticas ou fazendo IP sobre ATM clássico (se o ATM for preferido como Camada 2).

Usando o Gateway de Seleção de Serviço (SSG)

A principal vantagem do SSG em relação ao tunelamento é que o SSG fornece mapeamento de serviços um para muitos, enquanto o tunelamento fornece apenas um mapeamento um para um. Isso se torna muito útil quando um único usuário precisa de acesso a vários serviços, ou vários usuários em um único local, cada um precisa de acesso a um serviço exclusivo. O SSG usa o Service Selection Dashboard (SSD) baseado na Web, que consiste em serviços diferentes e está disponível para o usuário. O usuário pode acessar um ou vários serviços de uma só vez. Outra vantagem do uso do SSG é que o provedor de serviços pode cobrar o usuário com base nos serviços usados e no tempo de sessão, e o usuário pode ligar e desligar os serviços através do SSD.

Os usuários são autenticados à medida que a sessão PPP entra dos assinantes. Os usuários recebem endereços IP do pool local ou do servidor RADIUS. Depois que um usuário é autenticado com êxito, um objeto de origem é criado pelo código SSG e o usuário recebe acesso a uma rede padrão. A rede padrão contém o servidor SSD. Usando um navegador, o usuário faz login no Painel, é autenticado pelo servidor AAA e, dependendo do perfil do usuário armazenado no servidor RADIUS, é oferecido um conjunto de serviços para acessar.

Cada vez que um usuário autenticado seleciona um serviço, o SSG cria um objeto de destino para esse usuário. O objeto de destino contém informações como o endereço de destino, o endereço do servidor DNS desse destino e o endereço IP de origem atribuído do gateway de origem. Os pacotes que chegam do lado do usuário são encaminhados ao destino com base nas informações contidas no objeto de destino.

O SSG pode ser configurado para serviço proxy, passagem transparente ou PTA. Quando um assinante solicita acesso a um serviço proxy, o NRP-SSG passará a solicitação de acesso para o servidor RADIUS remoto. Ao receber o access-accept, o SSG responde ao assinante com o access-accept. O SSG aparece como um cliente para o servidor RADIUS remoto.

A passagem transparente permite que o tráfego de assinante não autenticado seja roteado através do SSG em qualquer direção. Use filtros para controlar o tráfego de passagem transparente.

O PTA só pode ser usado por usuários do tipo PPP. Autenticação, Autorização e Contabilidade são executadas exatamente como no tipo de serviço proxy. Um assinante faz login em um serviço usando um nome de usuário do formulário user@service. O SSG encaminha isso para o servidor RADIUS, que, em seguida, carrega o perfil de serviço para o SSG. O SSG encaminha a solicitação ao servidor RADIUS remoto conforme especificado pelo atributo de servidor RADIUS do perfil de serviço. Depois que a solicitação é autenticada, um endereço IP é atribuído ao assinante. Nenhum NAT é executado. Todo o tráfego do usuário é agregado à rede remota. Com o PTA, os usuários podem acessar apenas um serviço e não terão acesso à rede padrão ou ao SSD.

Descrição operacional da arquitetura PPPoA

Quando o CPE é ligado pela primeira vez, ele começa a enviar solicitações de configuração de LCP para o servidor de agregação. O servidor de agregação, com os PVCs configurados, também envia a solicitação de configuração do LCP em uma Interface de Acesso Virtual (associada ao PVC). Quando cada um vê a solicitação de configuração do outro, ele confirma as solicitações e o estado do LCP é aberto.

Para o estágio de autenticação, o CPE envia a solicitação de autenticação ao servidor de agregação. O servidor, dependendo de sua configuração, autentica o usuário com base no nome de domínio (se fornecido) ou o nome de usuário usando seu banco de dados local ou servidores RADIUS. Se a solicitação do assinante estiver na forma de username@domainname, o servidor de agregação tentará criar um túnel para o destino, se um ainda não estiver lá. Depois que o túnel é criado, o servidor de agregação encaminha as solicitações PPP do assinante para o destino. O destino, por sua vez, autentica o usuário e atribui um endereço IP. Se a solicitação do assinante não incluir o nome de domínio, o usuário será autenticado pelo banco de dados local. Se o SSG estiver configurado no roteador de agregação, o usuário poderá acessar a rede padrão conforme especificado e poderá obter uma opção para selecionar serviços diferentes.

Conclusão

O PPPoA está se tornando a arquitetura mais adequada para muitos provedores de serviços porque é altamente escalável, usa a funcionalidade SSG e fornece segurança. Como o foco deste documento era a arquitetura PPPoA, não foi possível cobrir em detalhes recursos como SSG. Esses recursos serão abordados em documentos subsequentes. Exemplos de configurações para os diferentes cenários discutidos neste documento também serão apresentados e explicados em documentos separados.

Informações Relacionadas

• Informações de Suporte do Produto DSL Cisco
• Suporte Técnico - Cisco Systems