Este documento descreve a arquitetura de linha de assinante digital assimétrica (ADSL - Asymmetric Digital Subscriber Line) de ponta a ponta ao usar o RFC1483 Bridging. Observe que a maioria das versões anteriores dos modems xDSL eram bridges entre Ethernet 10BaseT no lado do host e quadros de bridge encapsulados RFC1483 no lado da WAN. Ainda hoje, a maioria dos equipamentos nas instalações do cliente (CPE) ADSL implantados no campo estão em modo de bridging puro.
A arquitetura de linha de base foi projetada com a suposição de fornecer acesso à Internet de alta velocidade para o assinante final usando o modelo RFC1483 Bridging e ATM como o backbone central. O conteúdo deste documento é baseado na arquitetura de implantações existentes e em alguns testes internos.
O RFC1483 descreve dois métodos diferentes para transportar tráfego de interconexão de rede sem conexão através de uma rede ATM: Routed Protocol Data Units (PDUs) e PDUs interligadas.
O roteamento permite a multiplexação de vários protocolos sobre um único circuito virtual ATM (VC - ATM Virtual Circuit). O protocolo de uma PDU transportada é identificado pela prefixação da PDU com um cabeçalho de Controle Lógico de Enlace (LLC - Logical Link Control) IEEE 802.2.
O bridging executa multiplexação de protocolo de camada superior implicitamente por circuitos virtuais ATM. Para obter mais informações, consulte RFC1483.
Este documento se refere somente a PDUs com bridge.
Veja a seguir um resumo das vantagens e desvantagens da arquitetura RFC1483 Bridging. Essa arquitetura tem algumas desvantagens importantes, a maioria inerente ao modelo de bridging. Algumas das desvantagens foram notadas durante implantações ADSL em locais do cliente.
Simples de entender.
O bridging é muito simples de entender e implementar porque não há problemas complexos, como requisitos de roteamento ou autenticação para os usuários.
Configuração mínima do CPE.
O provedor de serviço considera isso importante, pois não exige mais um grande número de visitas de técnicos e não precisa mais investir pesadamente em funcionários para o suporte de protocolos de nível superior. O CPE no modo de ligação age como um dispositivo muito simples. A solução de problemas mínima está envolvida no CPE porque tudo o que vem da Ethernet passa diretamente para o lado da WAN.
Fácil de instalar.
A arquitetura de bridging é fácil de instalar devido à sua natureza simplista. Depois que os PVCs (Permanent Virtual Circuits, circuitos virtuais permanentes) de ponta a ponta são estabelecidos, atividades como o IP nos protocolos da camada superior tornam-se transparentes.
Suporte multiprotocolo para o assinante.
Quando o CPE está no modo de bridging, ele não se preocupa com qual protocolo de camada superior está sendo encapsulado.
Ideal para acesso à Internet em um único ambiente de usuário.
Como o CPE atua como um decodificador de sinais, a solução de problemas complexos não é necessária para os protocolos da camada superior. Os computadores finais não exigem instalação de cliente adicional.
O bridging depende muito dos broadcasts para estabelecer a conectividade.
Os broadcasts entre milhares de usuários são inerentemente inescaláveis. As razões para isso são que o broadcast consome largura de banda através do loop xDSL dos usuários, e o broadcast requer recursos no roteador head-end para replicar pacotes para a mídia de broadcast sobre ponto-a-ponto (ATM PVC).
Bridging é inerentemente inseguro e requer um ambiente confiável.
As respostas do Address Resolution Protocol (ARP) podem ser falsificadas e um endereço de rede pode ser sequestrado. Além disso, os ataques de broadcast podem ser iniciados na sub-rede local, negando o serviço a todos os membros da sub-rede local.
O sequestro de endereços IP é possível.
Considere as seguintes perguntas antes de implementar a arquitetura de RFC1483 Bridging.
Quais são os números atuais e planejados de assinantes a serem atendidos?
Os assinantes precisam se comunicar?
Esses assinantes são clientes residenciais de usuário único? Você atende clientes de escritórios pequenos e escritórios domésticos (SOHO) que podem ter uma LAN pequena atrás do CPE?
Qual é a implantação e o provisionamento de CPEs, DSLAMs (digital subscriber line access multiplexers, multiplexadores de acesso à linha de assinantes digitais) e POPs (Agregação de Protocolos de Correio)?
O Network Access Provider (NAP) e o Network Service Provider (NSP) são a mesma entidade? O modelo de negócios para o NAP também envolve a venda de serviços grossistas, como acesso corporativo seguro e serviços de valor agregado, como voz e vídeo?
O NSP deseja oferecer recursos de seleção de serviços?
Como se pode conseguir a contabilidade e a faturação? É por uso, por largura de banda ou por serviço?
O modelo de negócio da empresa é o de uma operadora de troca local independente (ILEC), uma operadora de troca local competitiva (CLEC) ou um provedor de serviços de Internet (ISP)?
Que tipos de aplicativos o NSP deseja oferecer ao assinante final?
O que é o volume de fluxo de dados upstream e downstream?
Com esses pontos considerados, a seguir estão descrições de como a arquitetura RFC1483 Bridging se ajusta e se adapta a diferentes modelos de negócios.
RFC1483 Bridging: Arquitetura de rede
Como mencionado anteriormente, há alguns problemas inerentes com a arquitetura de RFC1483 Bridging.
O recurso IOS Subscriber Bridging aborda alguns desses problemas. A aplicação seletiva das políticas de assinante em um grupo de bridge controla a inundação de ARPs, pacotes desconhecidos e outros por cada loop ADSL. Por exemplo, ao impedir que os ARPs sejam transmitidos, um usuário hostil não pode descobrir o endereço IP de outro usuário.
Outra solução é colocar todos os assinantes em uma única subinterface. O comportamento de bridging normal não encaminhará quadros à porta na qual o quadro foi recebido. Essencialmente, isso impõe um tipo de bridging de assinante no qual todos os pacotes entre os assinantes são filtrados. No entanto, essa abordagem apresenta as seguintes falhas:
A política do assinante só é aplicada entre subinterfaces. Para aplicar políticas de assinante entre dois usuários diferentes, cada usuário deve estar em uma subinterface ATM diferente.
Como o mapeamento de endereços de Camada 2 para Camada 3 é aprendido (via ARP), usuários hostis ainda podem sequestrar a conexão de outros usuários. Isso é feito gerando tráfego ARP com o endereço IP de outro usuário e usando um endereço MAC diferente.
O segundo cenário é mais grave para a operadora ou ISP. Nessa situação, qualquer usuário pode atribuir o endereço errado a um PC ou dispositivo conectado à Ethernet, como uma impressora, e causar problemas de conexão para outro usuário. Esses erros ou ataques são difíceis de identificar e corrigir porque o infrator pode ser rastreado apenas rastreando o endereço MAC do infrator.
Algumas operadoras tentam contornar esse problema segregando usuários entre grupos de pontes e implementando o bridging de assinantes entre subinterfaces. Nesse caso, quando o roteamento e bridging integrados (IRB) são necessários, cada usuário recebe um grupo de bridge exclusivo e uma BVI (Bridge Group Virtual Interface). Essa abordagem usa duas interfaces por assinante e pode ser um desafio para gerenciar.
Esses problemas são abordados e resolvidos de algumas formas pelo recurso Routed Bridged Encapsulation (RBE), que foi introduzido no Cisco IOS® Software Release 12.0(5)DC no Cisco 6400.
Considerando algumas das desvantagens do bridging, você pode se perguntar por que a arquitetura de bridging seria implementada. A resposta é simples. A maioria dos CPEs ADSL instalados no campo são capazes apenas de encaminhar quadros em ponte. Nesses casos, o NSP deve implementar o bridging.
Atualmente, os CPEs podem fazer o Point-to-Point Protocol over ATM (PPPoA), RFC1483 Bridging e o roteamento RFC1483. O NSP determina se deve fazer bridging ou PPP. A decisão se baseia nas considerações de implementação mencionadas anteriormente, além dos prós e contras de cada arquitetura.
Mesmo com as desvantagens da arquitetura de bridging, ela pode ser adequada para um pequeno ISP (que pode não ser o NAP) ou um NAP/NSP que atenda a um número menor de assinantes. Nesses cenários, o NAP geralmente encaminha todo o tráfego do assinante para o ISP/NSP, que encerra esses assinantes. O NAP pode optar por fornecer tráfego de assinante usando ATM ou Frame Relay como o protocolo da camada 2.
Os NAPs que usam DSLAMs de geração atual podem transportar apenas o tráfego de assinante usando ATM. Nesse caso, o ISP deve encerrar circuitos virtuais permanentes (PVCs - Permanent Virtual Circuits) ATM para um roteador.
Se o ISP/NSP não tiver a interface ATM, uma interface serial regular com encapsulamento ATM Data Exchange Interface (DXI) (possivelmente em um dispositivo adicional) pode ser usada para aceitar as PDUs de entrada de ponte.
Em ambos os cenários, o NSP/ISP pode ter que configurar o IRB no roteador (exceto quando estiver usando encapsulamento ATM DXI ou no caso de bridging transparente). Hoje, a prática mais comum para terminar assinantes com bridge no roteador NSP/ISP é implementar o IRB. (Espera-se que os provedores de serviços migrem gradualmente para o RBE.)
Devido a algumas das limitações mencionadas acima, o NSP/ISP pode optar por configurar grupos de bridge separados para cada conjunto de assinantes ou configurar todos os assinantes em um grupo de bridge. A prática comum é configurar alguns grupos de bridge e, em seguida, configurar todos os assinantes em interfaces multiponto separadas. Como mencionado anteriormente, os assinantes sob a mesma interface multiponto podem não conseguir se comunicar entre si. Se determinados usuários precisarem se comunicar, configure esses assinantes em diferentes interfaces (eles ainda podem estar no mesmo grupo de bridge).
Para um pequeno ISP/NSP, os roteadores mais comuns usados para terminar assinantes com bridge são o Cisco 3810, o Cisco 3600 e o Cisco 7200. Para um ISP/NSP com uma grande base de assinantes, o Cisco 6400 é o preferido. Antes de calcular os requisitos de memória para esses roteadores, considere os mesmos fatores que para qualquer outro ambiente: número de usuários, largura de banda e recursos do roteador.
A seguir estão os pontos principais da arquitetura.
A Cisco oferece vários CPEs que operam com DSLAMs da Cisco e de outros fornecedores. A configuração de cada um desses CPEs é livre de problemas e não requer nenhuma entrada do assinante. O requisito principal é que o CPE defina um identificador de caminho virtual ATM/identificador de canal virtual (VPI/VCI). Isso permite que o CPE se treine com o DSLAM e comece a passar tráfego. Na maioria dos casos, o NAP opta por configurar o mesmo VPI/VCI para todos os assinantes. O NAP normalmente pré-provisiona o CPE antes de implantá-lo no local do assinante.
Na arquitetura de bridging, a principal consideração para o CPE e sua implantação é como o NAP gerenciará o CPE após sua instalação no campo. Isso é uma preocupação porque o bridging não exige um endereço IP para o CPE. No entanto, os Cisco CPEs podem ser provisionados com um endereço IP no modo de bridging. O NAP pode usar esse recurso para executar telnet para o CPE para coletar estatísticas ou para ajudar o assinante na solução de problemas. Para permitir que os CPEs sejam gerenciados por meio dos DSLAMs, uma nova funcionalidade de elemento proxy está sendo adicionada.
No modo de bridging, se nenhum endereço IP de gerenciamento for atribuído ao CPE, o operador só poderá gerenciar o CPE através da porta de gerenciamento do CPE. Se um endereço IP de gerenciamento for atribuído, o operador poderá usar um navegador HTTP para gerenciar o dispositivo. No entanto, essa opção geralmente não está disponível.
Quando o CPE está no modo de bridging, o destino do serviço (que pode ser o NSP/ISP) deve fornecer um endereço IP que será usado como gateway padrão para os PCs atrás do CPE. Esses PCs devem ser definidos para o gateway padrão correto. Caso contrário, mesmo que o modem seja treinado (o que significa que a camada física está boa entre o CPE e o DSLAM), o assinante pode não conseguir transmitir tráfego. Isso não é um problema se o DHCP (Dynamic Host Configuration Protocol) for usado para atribuir endereços DHCP ao assinante, pois o roteador padrão é retornado pelo servidor DHCP.
RFC1483 Bridging: Gerenciamento de IP
Em um ambiente com bridge, os endereços IP são alocados às estações finais por um servidor DHCP localizado no destino do serviço, geralmente na rede NSP/ISP. Essa é a abordagem mais comum e é implementada pela maioria dos NSPs/ISPs usando esse modelo.
Outra abordagem é fornecer endereços IP estáticos aos assinantes. Nesse caso, uma sub-rede de endereços IP ou um único endereço IP é alocado por assinante, dependendo dos requisitos do assinante. Por exemplo, os assinantes que desejam hospedar um servidor Web ou um servidor de e-mail precisarão de um conjunto de endereços IP em vez de um único endereço IP. O problema com isso é que o NSP/ISP precisa fornecer endereços IP públicos e pode rapidamente ficar sem eles.
Alguns NSPs/ISPs forneceram endereços IP privados para seus assinantes. Em seguida, eles executam a Network Address Translation (NAT) no roteador de destino do serviço.
Os NSPs/ISPs que fornecem uma sub-rede completa para um grupo de bridge (com mais de um assinante) devem saber que um usuário pode atribuir o endereço errado a um PC ou dispositivo conectado à Ethernet, como uma impressora, e causar problemas de conexão para outro usuário.
Também é possível que um NSP/ISP restrinja o número de PCs que podem acessar o serviço ao mesmo tempo. Isso é feito configurando-se o número máximo de usuários na interface Ethernet.
No entanto, esse método apresenta a seguinte falha. Se três PCs estiverem configurados para usar o serviço e um dos assinantes adicionar uma impressora de rede (que tem seu próprio endereço MAC) durante um tempo em que um dos PCs está ocioso, o endereço MAC do PC desaparecerá da entrada ARP do CPE.
Se a impressora ficar ativa enquanto o PC estiver ocioso, o endereço MAC da impressora será inserido na entrada ARP. Quando um usuário decide usar este PC para acessar a Internet, ele não estará disponível porque o CPE já permitiu três entradas MAC. A estratégia de limitar usuários no CPE pode ser usada, mas deve-se ter cuidado ao fixar os números.
RFC1483 Bridging: PVC de ponta a ponta
Em uma arquitetura de PVC de ponta a ponta com bridging, o destino do serviço é alcançado pela criação de PVCs entre cada salto. No entanto, o gerenciamento desses PVCs pode ser desafiador para o NAP/NSP. Além disso, o número de PVCs que podem ser definidos através da nuvem ATM é limitado. Essa limitação afeta muitos dos NAPs/NSPs que adotam um modelo completo de PVC. Para cada assinante haverá um conjunto fixo e único de VPIs/VCIs ao longo de todo o caminho. Os SVCs (Switched Virtual Circuits, circuitos virtuais comutados) ajudam a superar alguns desses problemas, e muitos provedores de acesso estão migrando para redes de núcleo habilitadas por IP para resolver o problema de esgotamento do VC.
O NSP/ISP também tem a opção de usar a funcionalidade do Cisco Service Selection Gateway (SSG) para fornecer serviços diferentes aos assinantes.
Nessa arquitetura, o acesso seguro a um gateway corporativo é obtido ao terminar o PVC de tráfego do assinante diretamente no roteador corporativo na Camada 2. As arquiteturas baseadas em PVC são inerentemente seguras ao compartilhar dados com outros destinos de serviço.
RFC1483 Bridging: Descrição operacional
O CPE do Cisco 6xx assume como padrão o modo de roteamento. Portanto, quando é configurado para o modo de bridging e instalado no local do assinante com os divisores/microfiltros necessários, ele treina automaticamente ao ligar. Quando o CPE é acionado, ele indica que a camada física entre o CPE e o DSLAM está boa. Dependendo de como o endereço IP da estação final é configurado (ou seja, se é atribuído através de um servidor DHCP ou se é um endereço IP estático com informações de gateway padrão), ele pode se comunicar com o destino do serviço.
A seguir está uma descrição do fluxo de pacotes.
Os dados do usuário são encapsulados no IEEE 802.3 a partir do PC e entram no Cisco 6xx CPE. Ele é encapsulado em um cabeçalho Logical Link Control/Subnetwork Access Protocol (LLC/SNAP), que, por sua vez, é encapsulado na camada de adaptação ATM 5 (AAL5) e entregue à camada ATM.
As células ATM são então moduladas pela tecnologia de transmissão ADSL, modulação de Amplitude sem operadora e Fase (CAP - Carrierless Amplitude and Phase) ou DMT (Discrete Multi-Tone) e enviadas pelo fio para o DSLAM. No DSLAM, esses sinais modulados são recebidos pela primeira vez pelo divisor POTS, que verifica se a frequência do sinal está abaixo ou acima de 4 kHz. Depois de identificar os sinais como acima de 4 kHz, eles passam para a unidade de transmissão ADSL - escritório central (ATU-C) na DSLAM.
A ATU-C demodula o sinal e recupera as células ATM, que são então passadas para a placa de interface de rede (NIC) no dispositivo de multiplexação (MUX). A placa de rede examina as informações de VPI/VCI do lado do assinante no cabeçalho ATM e toma a decisão de switching para outro VPI/VCI que será encaminhado ao roteador de destino do serviço. Depois que o roteador de destino do serviço recebe essas células em uma interface ATM específica, ele as reagrupa, examina a camada superior e passa as informações para a interface BVI. A interface BVI examina as informações da Camada 3 e decide onde o pacote deve ser entregue.
O modelo RFC1483 Bridging é mais adequado para ISPs menores ou acesso corporativo para os quais a escalabilidade não se torna um problema. Como é muito simples entender e implementar, ele se tornou a escolha de muitos ISPs menores. No entanto, como resultado de alguns problemas de segurança e escalabilidade, a arquitetura de bridging está perdendo sua popularidade. Os NSPs/ISPs estão optando pelo RBE ou mudando para PPPoA ou PPPoE, que são altamente escaláveis e muito seguros, mas mais complexos e difíceis de implementar.