Este documento descreve uma arquitetura fim-a-fim da Asymmetric Digital Subscriber Line (ADSL) que usa Point-to-Point Protocol over Ethernet (PPPoE).
No ambiente atual de tecnologias de acesso, é desejável conectar vários hosts em um local remoto através do mesmo dispositivo de acesso nas instalações do cliente. Também é essencial fornecer controle de acesso e funcionalidade de faturamento de maneira semelhante aos serviços de discagem que usam o PPP (Point-to-Point Protocol). Em muitas tecnologias de acesso, o método mais econômico de conectar vários hosts ao dispositivo de acesso nas instalações do cliente é via Ethernet. Além disso, é desejável manter o custo desse dispositivo o mais baixo possível e o requisito de configuração menor ou nenhum.
À medida que os clientes implantam ADSL, eles precisam oferecer suporte à autenticação e autorização no estilo PPP em uma grande base instalada de CPE (Customer Premises Equipment, equipamento local do cliente) de Bridging legado. O PPPoE fornece a capacidade de conectar uma rede de hosts por um dispositivo de acesso de bridging simples a um concentrador de acesso remoto ou concentrador de agregação. Com esse modelo, cada host usa sua própria pilha PPP. Portanto, ele apresenta ao usuário uma interface de usuário familiar. Você pode acessar o controle, a cobrança e o tipo de serviço por usuário, em vez de por local.
A arquitetura de linha de base pressupõe que estes itens sejam fornecidos:
Acesso à Internet de alta velocidade e acesso corporativo ao assinante final que usa PPPoE.
ATM como a tecnologia de backbone central, implementada pelo Cisco 6400 Universal Access Concentrator (UAC).
Essa restrição de implementação de design pode limitar o uso dessa arquitetura em outras plataformas, mas o PPPoE evolui constantemente. Leia as notas de versão mais recentes dos produtos relacionados para aproveitar os recursos novos e atualizados.
Este documento é baseado em implantações atuais, bem como testes internos que usam o Cisco 6400 UAC. Este documento é uma continuação do artigo PPPoA Baseline Architecture e faz referência a ele com frequência. Supõe-se que você tenha lido o white paper Arquitetura de linha de base do PPPoA e compreendido os fundamentos do PPP, e que tenha lido as notas de versão da versão mais recente do software.
Conforme especificado no RFC 2516, o PPPoE tem dois estágios distintos: um estágio de descoberta e um estágio de sessão do PPP. Quando um host inicia uma sessão PPPoE, ele deve primeiro executar a descoberta para identificar qual servidor pode atender à solicitação do cliente. Em segundo lugar, ele precisa identificar o endereço MAC Ethernet do peer e estabelecer uma ID de sessão PPPoE. Enquanto o PPP define uma relação ponto-a-ponto, a descoberta é inerentemente uma relação cliente-servidor.
No processo de descoberta, um host (o cliente) descobre um ou mais concentradores de acesso (os servidores) e seleciona um. Quando a descoberta é concluída com êxito, o host e o concentrador de acesso selecionado têm as informações para criar sua conexão ponto a ponto pela Ethernet. Depois que uma sessão PPP é estabelecida, o host e o concentrador de acesso devem alocar os recursos para uma interface virtual PPP (esse provavelmente não é o caso para todas as implementações). Para obter mais detalhes sobre a especificação PPPoE, consulte RFC 2516.
A arquitetura PPPoE herda a maioria das vantagens do PPP usado no modelo de discagem e na arquitetura PPPoA. Essas seções listam algumas vantagens e desvantagens importantes do PPPoE e como elas se diferenciam do PPPoA.
Estas são algumas vantagens chave do PPPoE e como elas se diferenciam do PPPoA:
Autenticação por sessão com base no Password Authentication Protocol (PAP) ou no Challenge Handshake Authentication Protocol (CHAP). Essa é a maior vantagem do PPPoE, já que a autenticação supera a brecha de segurança em uma arquitetura de bridging.
A contabilidade por sessão é possível, o que permite que o provedor de serviços cobre o assinante com base no tempo de sessão para vários serviços oferecidos. O provedor de serviços também pode exigir uma taxa de acesso mínima.
Você pode usar PPPoE em instalações de CPE atuais que não podem ser atualizadas para PPP ou que não têm a capacidade de executar PPPoA, que estende a sessão PPP sobre a LAN Ethernet ligada para o PC.
O PPPoE preserva a sessão ponto a ponto usada pelos Provedores de Serviços de Internet (ISPs) no modelo de discagem atual. O PPPoE é o único protocolo capaz de executar ponto a ponto pela Ethernet sem a necessidade de uma pilha de IP intermediária.
O Network Access Provider (NAP) ou o Network Service Provider (NSP) podem fornecer acesso seguro a um gateway corporativo sem o gerenciamento de circuitos virtuais permanentes (PVCs - Permanent Virtual Circuits) de ponta a ponta e sem o uso de roteamento de Camada 3 e/ou túneis L2TP (Layer 2 Tunneling Protocol). Isso torna o modelo de negócios da venda de serviços em larga escala e de redes privadas virtuais (VPNs) escalável.
O PPPoE pode fornecer um acesso de host (PC) a vários destinos em um determinado momento. Você pode ter várias sessões PPPoE por PVC.
O NSP pode fazer assinatura em excesso pela implantação de timeouts de sessão e ociosos com a ajuda de um servidor RADIUS (Remote Authentication Dial-In User Service) padrão do setor para cada assinante.
Você pode usar o PPP com o recurso de gateway de seleção de serviço (SSG).
Estas são algumas das principais desvantagens do PPPoE e como elas se diferenciam do PPPoA:
Você deve instalar o software cliente PPPoE em todos os hosts (PCs) que se conectam ao segmento Ethernet. Isso significa que o provedor de acesso deve manter o CPE e o software cliente no PC.
Como a implementação PPPoE usa o RFC 1483 Bridging, ela é susceptível a tempestades de broadcast e possíveis ataques de negação de serviço.
Estes são alguns pontos importantes a serem considerados antes da implementação deste tipo de arquitetura.
O número de assinantes com suporte. O número de servidores PPPoE necessários depende do número de sessões.
Se as sessões PPP são terminadas no roteador de agregação do provedor de serviços ou encaminhadas para outros gateways corporativos ou ISPs.
Se o provedor de serviços ou o destino final do serviço fornece o endereço IP.
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. Os assinantes finais exigem acesso simultâneo a vários destinos?
O software cliente PPPoE que o provedor de acesso usa e se o software foi testado, o sistema operacional que o host usa e se esse sistema operacional pode tomar uma decisão de roteamento inteligente.
Como o provedor de serviços fatura os assinantes com base em uma taxa única, uso por sessão ou serviços usados.
Implantação e fornecimento de CPEs, DSLAMs e pontos de presença de agregação (POPs).
O modelo de negócios para o NAP. O modelo também inclui a venda de serviços de atacado como acesso corporativo seguro e serviços de valor agregado como voz e vídeo? NAPs e NSPs são a mesma entidade?
O modelo de negócios da empresa. É comparável a uma empresa de intercâmbio local independente (ILEC), a uma empresa de intercâmbio local concorrente (CLEC) ou a um FSI?
Os tipos de aplicativos que o NSP oferece ao assinante final.
O volume de upstream e downstream antecipado do fluxo de dados. Considere o throughput de NRP, a engenharia de tráfego e quaisquer problemas de QoS.
Este documento discute como a arquitetura PPPoE se ajusta e se adapta a diferentes modelos de negócios para provedores de serviços e como os provedores podem se beneficiar com a ajuda dessa arquitetura.
Esta seção aborda questões que se aplicam especificamente à arquitetura PPPoE.
Antes da implantação de qualquer arquitetura, é essencial entender o modelo de negócios do provedor de serviços e quais serviços ele oferece. Você precisa conhecer o software cliente que é usado no PC. O software mais comum é o Routerware. Como o software cliente é instalado em um PC, o técnico do provedor de serviços precisa ter um bom conhecimento desse PC e de seu sistema operacional.
Conforme especificado no RFC 2516, a opção de unidade máxima de recepção (MRU) não deve negociar um tamanho maior que 1492. A Ethernet tem um tamanho máximo de payload de 1500 octetos. O cabeçalho PPPoE tem 6 octetos e o ID do protocolo PPP tem 2 octetos, portanto, a MTU (Unidade Máxima de Transmissão) do PPP não deve ser maior que 1492. Isso é obtido com a configuração de IP MTU 1492 para interfaces de modelo virtual PPPoE.
Por padrão, nenhuma interface de acesso virtual é pré-clonada quando um grupo PPPoE VPDN é configurado. Os usuários podem alterar o número máximo de interfaces de acesso virtual pré-clonadas emitindo o comando global virtual-template <number> pre-clone <number>.
Para proteger o roteador contra ataques de negação de serviço, o PPPoE (por padrão) permite que apenas uma sessão seja originada de um endereço MAC em um VC. Os usuários podem executar os comandos pppoe session-limit per-mac e pppoe session-limit per-vc para alterar os padrões.
O processo de contabilização, autorização e autenticação é o mesmo que o do PPPoA. A única diferença é que atualmente, a autenticação baseada em VPI/VCI, que está disponível para PPPoA e não está disponível para PPPoE, pode usar as arquiteturas L2TP e SSG para serviços de atacado.
O CPE é configurado para RFC 1483 Bridging puro. Cada CPE consome apenas um par VPI/VCI e todas as sessões PPPoE iniciadas pelos hosts por trás desse CPE são transportadas nesse único VC.
A alocação de endereço IP para o host individual que executa o cliente PPPoE baseia-se no mesmo princípio do PPP no modo de discagem - negociação IPCP. A origem do endereço IP depende do tipo de serviço que o assinante compra e onde as sessões PPP terminam. O PPPoE usa o recurso de rede de discagem do Microsoft Windows, e o endereço IP atribuído é refletido no adaptador PPP.
A atribuição de endereço IP pode vir do concentrador de acesso que termina as sessões PPPoE ou, no caso de L2TP, dos gateways domésticos. O endereço IP é atribuído a cada sessão PPPoE.
O CPE não pode fazer a conversão de endereço de rede/protocolo de configuração dinâmica de host (NAT/DHCP) porque está ligado e não há endereço IP alocado a ele.
Estas são as maneiras de alcançar o destino do serviço:
O término de sessões PPP no provedor de serviços
tunelamento L2TP
Com o uso do SSG
As explicações detalhadas dessas arquiteturas são abordadas em documentos separados.
Esta versão do software cliente PPPoE suporta os estágios de descoberta e sessão descritos no RFC 2516. Há quatro etapas para o estágio de descoberta. Ao concluir, ambos os peers sabem o ID da sessão PPPoE e o endereço Ethernet do peer, que juntos definem exclusivamente a sessão PPPoE. Estas são as etapas:
O host envia um pacote de iniciação por broadcast.
O host envia o pacote de iniciação de descoberta ativa (PADI - Ative Discovery Initiation) de PPPoE com destination_addr definido para o endereço de broadcast. O PADI consiste em uma tag que indica que tipo de serviço ele solicita.
Um ou mais concentradores de acesso enviam pacotes de oferta.
Quando o concentrador de acesso ou o roteador recebe um PADI que pode servir, ele envia um pacote de oferta de descoberta ativa (PADO) de PPPoE. destination_addr é o endereço unicast do host que enviou o PADI. Se o concentrador de acesso não puder atender o PADI, ele não deverá responder com um PADO. Desde que o PADI foi transmitido, o host pode receber mais de um PADO.
O host envia um pacote de solicitação de sessão unicast.
O host procura pelos pacotes PADO que recebe e escolhe um. A escolha é baseada nos serviços oferecidos por cada concentrador de acesso. Em seguida, o host envia um pacote PADR ao concentrador de acesso escolhido. O campo destination_addr é definido como o endereço Ethernet unicast do concentrador de acesso ou do roteador que envia o PADO.
O concentrador de acesso selecionado envia um pacote de confirmação.
Quando o concentrador de acesso recebe um pacote PADR, ele se prepara para iniciar uma sessão PPP. Ele gera um ID de sessão exclusivo para a sessão PPPoE e responde ao host com um pacote PADS (Ative Discovery Session-Confirmation, confirmação de sessão de descoberta ativa) PPPoE. O campo destination_addr é o endereço Ethernet unicast do host que envia o PADR.
Uma vez iniciada a sessão de PPPoE, os dados de PPP são enviados como em qualquer outro encapsulamento de PPP. Todos os pacotes Ethernet são unicast.
Um pacote PADT (ative discovery terminate) de PPPoE pode ser enviado pelo host ou pelo concentrador de acesso a qualquer momento depois que uma sessão é estabelecida para indicar que uma sessão de PPPoE foi terminada.
Para obter uma explicação mais detalhada, consulte o RFC 2516.
Para ADSL, o PPPoE ganha popularidade e fica atrás apenas do PPPoA.
RFC 2516 - Um método para transmitir PPP sobre Ethernet (PPPoE)
RFC 1483 - Encapsulamento multiprotocolo sobre camada de adaptação ATM 5
RFC 2364 - Ponto a ponto sobre AAL5
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
10-Dec-2001 |
Versão inicial |