Visão geral da rede de acesso ao assinante de banda larga
Visão geral da rede de acesso ao assinante
Um ambiente de acesso ao assinante pode incluir vários componentes, incluindo tecnologias de acesso ao assinante e protocolos de autenticação.
As tecnologias de acesso aos assinantes incluem:
Servidor de protocolo dinâmico de configuração de host (DHCP)
Servidor DHCP local
Servidor DHCP externo
Protocolo de ponto a ponto (PPP)
Os protocolos de autenticação de assinantes incluem o servidor RADIUS.
A Figura 1 mostra um exemplo de uma rede básica de acesso ao assinante.

Esse recurso requer uma licença. Para entender mais sobre o licenciamento de acesso ao assinante, veja a visão geral do licenciamento de acesso ao assinante. Consulte o Guia de licenciamento da Juniper para obter informações gerais sobre o gerenciamento de licenças. Consulte as folhas de dados do produto nos roteadores da Série MX para obter detalhes ou entrar em contato com sua equipe de conta da Juniper ou com o parceiro Juniper.
Visão geral do nó de acesso multisserviço
Um nó de acesso multisserviços é um termo mais amplo que se refere a um grupo de dispositivos de agregação comumente usados. Esses dispositivos incluem multiplexadores de acesso de linha de assinantes digitais (DSLAMs) usados em redes xDSL, terminação de linha óptica (OLT) para redes PON/FTTx e switches de ethernet para conexões Ethernet ativas. As MSANs modernas costumam oferecer suporte a todas essas conexões, além de fornecer conexões para circuitos adicionais, como o serviço telefônico simples e antigo (chamado de POTS) ou o Digital Signal 1 (DS1 ou T1).
A função definidora de um nó de acesso multisserviço é agregar tráfego de vários assinantes. No nível físico, o MSAN também converte tráfego da última milha de tecnologia (por exemplo, ADSL) para ethernet para entrega aos assinantes.
Você pode categorizar amplamente as MSANs em três tipos com base em como elas encaminham o tráfego na rede:
Layer–2 MSAN— Esse tipo de MSAN é essencialmente um switch de Camada 2 (embora normalmente não seja um switch em pleno funcionamento) com alguns aprimoramentos relevantes. Essas MSANs usam comutação Ethernet (ou ATM) para encaminhar tráfego. O MSAN encaminha todo o tráfego de assinantes upstream para um roteador de borda que atua como o ponto de controle centralizado e impede a comunicação direta do assinante ao assinante. A agregação de enlaces de ethernet (LAG) oferece a resiliência nesse tipo de rede.
Os DSLAMs de camada 2 não conseguem interpretar o IGMP, de modo que não podem replicar seletivamente os canais IPTV.
Layer–3 aware MSAN— Esse MSAN consciente de IP pode interpretar e responder às solicitações de IGMP replicando localmente um fluxo multicast e encaminhando o fluxo para qualquer assinante que o solicite. A consciência da camada 3 é importante ao oferecer suporte ao tráfego IPTV para realizar mudanças de canal (às vezes referidas como zaps de canal). AS MSANs estáticas com reconhecimento de IP sempre recebem todos os canais de televisão multicast. Eles não têm a capacidade de solicitar que canais específicos sejam encaminhados ao DSLAM. Os DSLAMs dinâmicos com reconhecimento de IP, no entanto, podem informar a rede para começar (ou descontinuar) o envio de canais individuais para o DSLAM. Configurar proxy IGMP ou IGMP bisbilhotando o DSLAM realiza essa função.
Layer–3 MSAN— Essas MSANs usam a funcionalidade de roteamento IP em vez de tecnologias de Camada 2 para encaminhar tráfego. A vantagem desse método de encaminhamento é a capacidade de suportar vários links upstream indo para diferentes roteadores upstream e melhorando a resiliência da rede. No entanto, para alcançar esse nível de resiliência, você deve atribuir uma sub-rede IP separada a cada MSAN, adicionando um nível de complexidade que pode ser mais difícil de manter ou gerenciar.
Ao escolher um tipo de MSAN, consulte a Figura 2:

Opções de agregação DE MSAN da Ethernet
Cada MSAN pode se conectar diretamente a um roteador de borda (roteador de serviços de banda larga ou roteador de serviços de vídeo), ou um dispositivo intermediário (por exemplo, um switch Ethernet) pode agregar tráfego MSAN antes de ser enviado ao roteador de serviços. A Tabela 1 lista os possíveis métodos de agregação de MSAN e em que condições eles são usados.
Método |
Quando usado |
---|---|
Conexão direta |
Cada MSAN se conecta diretamente ao roteador de serviços de banda larga e roteador de serviços de vídeo opcionais. |
Conexão do switch de agregação de ethernet |
Cada MSAN se conecta diretamente a um switch Ethernet intermediário. O switch, por sua vez, se conecta ao roteador de serviços de banda larga ou roteador opcional de serviços de vídeo. |
Conexão de agregação de anel de ethernet |
Cada MSAN se conecta a uma topologia em anel de MSANs. O MSAN de ponta cabeça (o dispositivo mais próximo do roteador de borda upstream) se conecta ao roteador de serviços de banda larga. |
Você pode usar diferentes métodos de agregação em diferentes partes da rede. Você também pode criar várias camadas de agregação de tráfego dentro da rede. Por exemplo, um MSAN pode se conectar a um terminal de escritório central (COT), que por sua vez se conecta a um switch de agregação Ethernet, ou você pode criar vários níveis de switches de agregação de Ethernet antes de se conectar ao roteador de borda.
Conexão direta
No método de conexão direta, cada MSAN tem uma conexão ponto a ponto com o roteador de serviços de banda larga. Se existir um escritório central intermediário, o tráfego de várias MSANs pode ser combinado em uma única conexão usando multiplexação de divisão de onda (WDM). Você também pode conectar o MSAN a um roteador de serviços de vídeo. No entanto, esse método de conexão exige que você use um MSAN de Camada 3 que tenha a capacidade de determinar qual link usar ao encaminhar o tráfego.
Ao usar o método de conexão direta, lembre-se do seguinte:
Recomendamos essa abordagem quando possível para simplificar o gerenciamento de rede.
Como várias MSANs são usadas para se conectar ao roteador de serviços, e as MSANs de Camada 3 geralmente exigem um custo de equipamento mais alto, esse método raramente é usado em um modelo de gerenciamento de assinantes multiedge.
A conexão direta é normalmente usada quando a maioria dos links MSAN são utilizados menos de 33% e há pouco valor na combinação de tráfego de várias MSANs.
Conexão do switch de agregação de ethernet
Um switch de agregação de Ethernet agrega tráfego de várias MSANs downstream em uma única conexão ao roteador de serviços (roteador de serviços de banda larga ou roteador de serviços de vídeo opcionais).
Ao usar o método de conexão de switch de agregação Ethernet, lembre-se do seguinte:
A agregação de ethernet é normalmente usada quando a maioria dos links MSAN são utilizados acima de 33% ou para agregar tráfego de MSANs de menor velocidade (por exemplo, 1 Gbps) a uma conexão de velocidade mais alta com o roteador de serviços (por exemplo, 10 Gbps).
Você pode usar um roteador da Série MX como um switch de agregação Ethernet. Para obter informações sobre a configuração do roteador da Série MX em cenários de Camada 2, consulte o guia de usuário de redes Ethernet para roteadores da Série MX.
Conexão de agregação de anel
Em uma topologia em anel, o MSAN remoto que se conecta aos assinantes é chamado de terminal remoto (RT). Esse dispositivo pode estar localizado na planta externa (OSP) ou em um escritório central remoto (CO). O tráfego atravessa o anel até chegar ao terminal central do escritório (COT) na ponta da frente do anel. O COT então se conecta diretamente ao roteador de serviços (roteador de serviços de banda larga ou roteador de serviços de vídeo).
O RT e o COT devem suportar o mesmo protocolo de resiliência em anel.
Você pode usar um roteador da Série MX em uma topologia de agregação de anel Ethernet. Para obter informações sobre a configuração do roteador da Série MX em cenários de Camada 2, consulte o guia de usuário de redes Ethernet para roteadores da Série MX.
Visão geral do LDP Pseudowire Autosensing
Um pseudowire é um link virtual que é usado para transportar um serviço de Camada 2 em uma rede de borda ou acesso MPLS. Em uma típica rede de borda de banda larga ou borda empresarial, uma ponta de um pseudowire é terminada como um circuito de Camada 2 em um nó de acesso, e a outra extremidade é terminada como um circuito de Camada 2 em um nó de serviço que serve como um nó de agregação ou uma rede núcleo MPLS. Tradicionalmente, ambos os endpoints são provisionados manualmente por meio da configuração. A autosensão pseudowire LDP introduz um novo modelo de provisionamento que permite que endpoints pseudowire sejam provisionados e desprovisionados automaticamente em nós de serviço com base em mensagens de sinalização LDP. Esse modelo pode facilitar o provisionamento de pseudowires em grande escala. Um nó de acesso usa LDP para sinalizar identidade pseudowire e atributos a um nó de serviço. A identidade é autenticada por um servidor RADIUS e depois usada em conjunto com os atributos sinalizados pelo LDP e os atributos passados pelo servidor RADIUS para criar a configuração de endpoint pseudowire, incluindo o circuito de Camada 2.
- Histórico de terminação de entrada pseudowire
- Abordagem de autosensibilidade pseudowire
- Configuração de amostra
Histórico de terminação de entrada pseudowire
Em um acesso de banda larga habilitado para MPLS ou uma rede de borda empresarial, os pseudowires Ethernet são comumente usados como interfaces virtuais para conectar nós de acesso a nós de serviço. Cada pseudowire transporta o tráfego bidirecional de um ou vários assinantes de banda larga ou clientes de borda comercial entre um nó de acesso e um par de nós de serviço. A criação do pseudowire é geralmente iniciada pelo nó de acesso, com base na configuração estática ou detecção dinâmica de um novo assinante de banda larga ou cliente de borda empresarial que chega em uma porta voltada para o cliente no nó de acesso.
Idealmente, o nó de acesso deve criar um pseudowire por porta cliente, onde todos os assinantes ou clientes hospedados pela porta são mapeados para o pseudowire. A alternativa é onde há um pseudowire por porta de cliente (S-VLAN), e todos os assinantes ou clientes que compartilham uma S-VLAN comum na porta são mapeados para o pseudowire. Em ambos os casos, o pseudowire é sinalizado no modo bruto.
O S-VLAN, se não for usado para delimitar o serviço no nó de serviço ou combinado com c-VLAN para distinguir assinantes ou clientes, será retirado antes que o tráfego seja encapsulado em carga pseudowire e transportado para o nó de serviço. Os assinantes ou clientes individuais podem se distinguir pelo C-VLAN, ou por um cabeçalho de Camada 2, como DHCP e PPP, que será transportado em carga pseudowire para o nó de serviço. No nó de serviço, o pseudowire é encerrado. Assinantes ou clientes individuais são então desmultipledos e modelados como interfaces de assinantes de banda larga, interfaces de borda de negócios (por exemplo, PPPoE), interfaces Ethernet ou interfaces IP. As interfaces de Ethernet e IP podem ser anexadas ainda mais a instâncias de serviço, como instâncias VPLS e VPN de Camada 3.
No Junos OS, a terminação de entrada de pseudowire em nós de serviço é suportada através do uso de interfaces físicas e lógicas de serviço pseudowire. Essa abordagem é considerada superior em escalabilidade à abordagem antiga baseada em interface de túnel lógica, devido à sua capacidade de multiplexação e desmultiplemento de assinantes ou clientes em um único pseudowire. Para cada pseudowire, uma interface física de serviço pseudowire é criada em um mecanismo de encaminhamento de pacotes selecionado, que é chamado de mecanismo âncora de encaminhamento de pacotes. Além dessa interface física de serviço pseudowire, uma interface lógica ps.0 (interface lógica de transporte) é criada, e um circuito de Camada 2 ou VPN de Camada 2 é criado para hospedar a interface lógica ps.0 como uma interface de anexo.
O circuito de Camada 2 ou VPN de Camada 2 permite a sinalização pseudowire em direção ao nó de acesso, e a interface lógica ps.0 serve a função da interface voltada para a borda do cliente para o pseudowire. Além disso, uma ou várias interfaces lógicas ps.n (também conhecidas como interfaces lógicas de serviço, onde n>0) podem ser criadas na interface física do serviço pseudowire para modelar fluxos individuais de assinantes/clientes como interfaces lógicas. Essas interfaces podem então ser anexadas aos serviços de borda de banda larga e negócios desejados ou instâncias VPN de Camada 2 ou Camada 3.
Observe que o objetivo do mecanismo de encaminhamento de pacotes âncora é designar o Mecanismo de encaminhamento de pacotes para processar o tráfego bidirecional do pseudowire, incluindo encapsulamento, decapsulação, VLAN mux ou demux, QoS, policiamento, modelagem e muito mais.
Para o Junos OS Release 16.2 e anterior, a criação e exclusão das interfaces físicas de serviço pseudowire, interfaces lógicas de serviço pseudowire, circuitos de Camada 2 e VPNs de Camada 2 para terminação de entrada pseudowire dependem da configuração estática. Essa não é considerada a melhor opção sob a perspectiva de escalabilidade, eficiência e flexibilidade, especialmente em uma rede onde cada nó de serviço pode potencialmente hospedar um grande número de pseudowires. O objetivo é ajudar os provedores de serviços a sair da configuração estática no provisionamento e deprovisionamento da rescisão de entrada de pseudowire em nós de serviço.
Abordagem de autosensibilidade pseudowire
Na abordagem de autosensibilidade pseudowire, um nó de serviço usa a mensagem de mapeamento de rótulos LDP recebida de um nó de acesso como um gatilho para gerar configuração dinamicamente para uma interface física de serviço pseudowire, uma interface lógica de serviço pseudowire, um circuito de Camada 2. Da mesma forma, ele usa a mensagem de retirada do rótulo LDP recebida do nó de acesso e do evento de sessão LDP como gatilhos para remover a configuração gerada. Em autosensibilidade pseudowire, assume-se que os nós de acesso são os iniciadores da sinalização pseudowire, e nós de serviço são os alvos. Em uma rede onde um serviço pode ser hospedado por vários nós de serviço para redundância ou balanceamento de carga, isso também fornece nós de acesso com um modelo de seleção e conexão para o estabelecimento de serviços. O fluxo de controle básico de autosensibilidade pseudowire é mostrado na Figura 3

O procedimento básico de fluxo de controle de autosensibilidade pseudowire é o seguinte:
O equipamento de instalações do cliente (CPE) entra em operação e envia um quadro Ethernet com C-VLAN para o terminador de linha óptica (OLT). O OLT adiciona S-VLAN ao quadro e envia o quadro para o nó de acesso. O nó de acesso verifica com o servidor RADIUS para autorizar as VLANs.
O servidor RADIUS envia um acesso aceito ao nó de acesso. O nó de acesso cria um circuito de Camada 2 e sinaliza um pseudowire para o nó de serviço por meio de uma mensagem de mapeamento de rótulos LDP.
O nó de serviço aceita a mensagem de mapeamento de rótulos e envia uma solicitação de acesso com informações pseudowire ao servidor RADIUS para autorização e para seleção de uma interface física de serviço pseudowire ou uma interface lógica.
O servidor RADIUS envia um acesso aceito ao nó de serviço com uma string de serviço especificando a interface física ou interface lógica de serviço pseudowire selecionada. O nó de serviço cria uma configuração de circuito de Camada 2, as informações pseudowire e a interface física ou interface lógica do serviço pseudowire. O nó de serviço sinaliza o pseudowire em direção ao nó de acesso por meio de uma mensagem de mapeamento de rótulos LDP. O pseudowire surge bidirecionalmente.
Configuração de amostra
A configuração a seguir marca explicitamente o circuito de Camada 2 gerado pelo autosensimento. A interface física do serviço pseudowire e a configuração da interface lógica de serviço pseudowire são opcionais, dependendo se elas preexistem.
Roteador 0
[edit] protocols { Layer 2 circuit { neighbor 192.0.2.2 { interface ps0.0 { virtual-circuit-id 100; control-word; mtu 9100; auto-sensed; } } } }
Serviços de camada 2 na visão geral da interface de serviço pseudowire
A interface lógica de serviço pseudowire oferece suporte à interface lógica de transporte (psn.0) no lado de acesso MPLS e interfaces lógicas de serviço (psn.1 a psn.n) no lado central MPLS da rede de gerenciamento de assinantes.
O serviço pseudowire em interfaces lógicas de serviço psn.1 para psn.n são configurados como interfaces de Camada 2 no domínio da ponte ou em uma instância de serviço de LAN privada virtual (VPLS). Há um circuito de Camada 2 ou a VPN de Camada 2 em acesso MLPS entre um dispositivo de agregação Ethernet e um dispositivo de borda de serviço com o serviço pseudowire na interface lógica de transporte psn.0 como a interface de terminação do circuito de Camada 2 ou a VPN de Camada 2 no dispositivo de borda de serviço.
O Junos OS oferece suporte ao serviço pseudowire em interfaces lógicas de serviço psn.1 para psn.n no domínio de ponte ou instância VPLS, que recebe saída de tráfego do serviço pseudowire na interface lógica de transporte no dispositivo de borda de serviço. Ele também permite que recursos de entrada de Camada 2, como aprendizado MAC, manipulações de VLAN e MAC de destino visualizem o serviço pseudowire em interfaces lógicas de serviço.
Quando o tráfego está na direção inversa, o MAC de destino entra no domínio de Camada 2 no dispositivo de borda de serviço, que é aprendido como o MAC de origem no serviço pseudowire em interfaces lógicas de serviço. A partir do Junos OS Release 17.1R1, as interfaces de túnel lógico pseudowire oferecem suporte a VPLS Ethernet, ponte Ethernet, VPLS VLAN e encapsulamento de ponte VLAN próximo saltos para sair do tráfego de Camada 2. A partir do Junos OS Release 18.4R1, o suporte de serviço de Camada 2 com as interfaces lógicas de serviço pseudowire é estendido a interfaces de serviço pseudowire ancoradas em interfaces de túnel lógicas redundantes também. Esses serviços de Camada 2 são suportados apenas no serviço pseudowire em interfaces lógicas de serviço (psn.1 a psn.n) e não em interface lógica de transporte (psn.0). Os recursos de saída de Camada 2, como manipulações de VLAN e outros, são habilitados nas interfaces de serviço pseudowire. O tráfego enviado para fora das interfaces entra no serviço pseudowire em interfaces lógicas de transporte que é a interface de circuito de Camada 2 entre a agregação de Ethernet e dispositivos de borda de serviço em todo o domínio de acesso MPLS.
Para o Junos OS Release 16.2 e anterior, encapsulamentos ou recursos de Camada 2 não poderiam ser configurados no serviço pseudowire em interfaces lógicas de serviço.
- Tráfego de LAN do cliente para MPLS
- Tráfego da borda de serviços à LAN do cliente
- Interfaces de serviço pseudowire
- Configuração de amostra
Tráfego de LAN do cliente para MPLS
As instâncias VPLS-x e VPLS-y estão configuradas no lado central MPLS do dispositivo de borda de serviço (PE A). Um circuito de Camada 2 ou VPN de Camada 2 está configurado entre o dispositivo de agregação Ethernet (EAD 1) e o dispositivo de borda de serviço. ps0.0 (interface lógica de transporte) é a interface local no circuito de Camada 2 ou na VPN de Camada 2 no PE A. O Junos OS oferece suporte ao serviço pseudowire na interface lógica de serviço ps0.x (x>0) na instância VPLS VPLS-x (VLAN ID em VPLS-x = m) e serviço pseudowire na interface lógica de serviço ps0.y(y>0) na instância VPLS VPLS-y (VLAN ID em VPLS-y = n).
Na Figura 4, quando o tráfego vem de EAD 1 para PE A (no circuito de Camada 2 ou VPN de Camada 2) com qualquer ID VLAN, o tráfego sairá pelo ps0.0. Com base no VLAN ID no tráfego, o serviço pseudowire na interface lógica de serviço é selecionado. Por exemplo, se o VLAN ID for m, o tráfego entrará em ps0.x e se o VLAN ID for n, o tráfego entrará em ps0.y.

Quando o tráfego entra no serviço pseudowire na interface lógica de serviço ps0.n, onde n>0, as seguintes etapas são realizadas.
O aprendizado MAC de origem deve ocorrer no serviço pseudowire de Camada 2 na interface lógica de serviço. O mecanismo de encaminhamento de pacotes de origem para este MAC é o Mecanismo de encaminhamento de pacotes da interface lógica de túnel na qual o serviço pseudowire está ancorado em uma instância VPLS ou domínio de ponte no dispositivo PE A.
A pesquisa MAC de destino é feita no lado de entrada como uma lista de recursos da família de ponte de entrada de serviços pseudowire em interfaces lógicas de serviço.
Se a busca mac de destino for bem sucedida, o tráfego será enviado como unicast; caso contrário, o MAC de destino, MAC broadcast e MAC multicast estão inundados.
Se a busca mac de destino falhar para o tráfego vindo em um serviço pseudowire em uma interface lógica de serviço, o
mlp query
comando é enviado para o Mecanismo de Roteamento e o outro Mecanismo de encaminhamento de pacotes em domínio de ponte ou instância VPLS.
Se um novo MAC for aprendido em um serviço pseudowire em uma interface lógica de serviço, então o
mlp add
comando é enviado para o Mecanismo de Roteamento e o outro Mecanismo de encaminhamento de pacotes em domínio de ponte ou instância VPLS.
Tráfego da borda de serviços à LAN do cliente
Quando o tráfego entra na instância VPLS ou domínio de ponte no dispositivo de borda de serviço e se o MAC de destino no tráfego é aprendido em um serviço pseudowire em uma interface lógica de serviço, então o símbolo associado com essa interface lógica de serviço pseudowire é definido no lado de entrada. O tráfego é então enviado para o Mecanismo de encaminhamento de pacotes no qual a interface lógica de túnel da interface física do serviço pseudowire é ancorada através de uma malha. Quando este símbolo é lançado, ele oferece suporte a encapsulamentos de ponteS VLAN VPLS, VLAN, VPLS Ethernet e Ethernet. O próximo salto de encapsulamento aponta para a lista de recursos de interface lógica de saída do serviço pseudowire na interface lógica de serviço para executar todos os recursos de saída de Camada 2 e enviar o pacote para o lado de entrada do serviço pseudowire na interface lógica de transporte ps0.0.
Se a consulta MAC chegar ao mecanismo de encaminhamento de pacotes no qual o serviço pseudowire está ancorado, então o Mecanismo de encaminhamento de pacotes envia a resposta apenas quando o MAC aprendido sobre o serviço pseudowire na interface lógica de serviço está presente. O símbolo de Camada 2 associado ao serviço pseudowire na interface lógica de serviço visto após a busca mac de destino pelo MAC aprendido no serviço pseudowire na interface lógica de serviço deve apontar para o próximo salto associado com o lado de acesso do serviço pseudowire em serviço a interface lógica.
O serviço pseudowire na interface lógica de transporte é a interface local ps0.0 do circuito de Camada 2 ou VPN de Camada 2 entre a borda de serviço e os dispositivos de agregação Ethernet. O tráfego é enviado para o dispositivo de agregação Ethernet por meio do circuito de Camada 2 ou VPN de Camada 2 em todo o domínio de acesso MPLS.
Se o tráfego MAC de destino vindo do lado de entrada e saída do dispositivo de borda de serviço for desconhecido ou multicast ou broadcast, o tráfego precisa ser inundado. Isso requer que um dispositivo de borda do cliente inunde o próximo salto para incluir o serviço pseudowire na interface lógica de serviço, que funciona como uma interface lógica de acesso para a instância VPLS ou domínio de ponte.
Interfaces de serviço pseudowire
Os recursos a seguir são suportados em interfaces de serviço pseudowire:
Uma interface de serviço pseudowire é hospedada em uma interface lógica de túnel (lt-x/y/z). O tráfego de um serviço pseudowire de transporte em uma interface lógica para um serviço pseudowire assinante em uma interface lógica é baseado no ID VLAN disponível.
A transferência de tráfego de um serviço pseudowire assinante em uma interface lógica para um serviço pseudowire de transporte em uma interface lógica é baseada no channelID por meio de um endereço IP de loopback disponível.
O serviço Pseudowire em interfaces lógicas de serviço é suportado na instância de roteamento e encaminhamento virtual (VRF).
-
Serviço de assinante pseudowire (ps) em uma interface de tronco para encerrar a instância de circuito de Camada 2 em um switch virtual habilitado para VPLS. O mesmo circuito de Camada 2 também pode ser encerrado na instância de roteamento de instâncias VPLS com diferentes interfaces lógicas de serviço e instância de roteamento de instância VRF VPN de Camada 3 usando outra interface lógica de serviço também.
Configuração de amostra
As configurações de amostra a seguir mostram um serviço pseudowire em uma interface lógica de transporte em um circuito de Camada 2, um serviço pseudowire em interfaces lógicas de serviço em um domínio de ponte e uma instância VPLS em um dispositivo de borda de serviço, e um serviço pseudowire em uma interface de serviço de tronco em uma instância VPLS:
Serviço pseudowire em uma interface lógica de serviço em domínio de ponte no roteador 0
[edit] interfaces { ps0 { unit 0 { encapsulation ethernet-ccc; } unit 1 { encapsulation vlan-bridge; vlan-id 1; } unit 2 { encapsulation vlan-bridge; vlan-id 2; } } ge-0/0/0 { unit 1 { encapsulation vlan-bridge; vlan-id 1; } unit 2 { encapsulation vlan-bridge; vlan-id 2; } } ge-2/0/6 { unit 0 { family inet { address 10.11.2.1/24; } family mpls; } } } protocols { mpls { label-switched-path to_192.0.2.2 { to 192.0.2.2; } } bgp { group RR { type internal; local-address 192.0.3.3; } } l2-circuit { neighbor 192.0.2.2 { interface ps0.0 { virtual-circuit-id 100; } } } } bridge-domains { bd1 { domain-type bridge; vlan-id 1; interface ps0.1; interface ge-0/0/0.1; } bd2 { domain-type bridge; vlan-id 2; interface ps0.2; interface ge-0/0/0.2; } }
Serviço pseudowire em uma interface lógica de serviço em uma instância VPLS no roteador 0
[edit] interfaces { ps0 { unit 0 { encapsulation ethernet-ccc; } unit 1 { encapsulation vlan-vpls; vlan-id 1; family vpls; } unit 2 { encapsulation vlan-vpls; vlan-id 2; family vpls; } } ge-0/0/0 { unit 1 { encapsulation vlan-vpls; vlan-id 1; family vpls; } unit 2 { encapsulation vlan-vpls; vlan-id 2; family vpls; } } ge-2/0/6 { unit 0 { family inet { address 10.11.2.1/24; } family mpls; } } } protocols { mpls { label-switched-path to_192.0.2.2 { to 192.0.2.2; } } bgp { group RR { type internal; local-address 192.0.3.3; } } l2-circuit { neighbor 192.0.2.2 { interface ps0.0 { virtual-circuit-id 100; } } } } routing-instances { vpls-1 { instance-type vpls; vlan-id 1; interface ps0.1; interface ge-0/0/0.1; } vpls-2 { instance-type vpls; vlan-id 2; interface ps0.2; interface ge-0/0/0.2; } }
Serviço pseudowire em uma interface de serviço de tronco em uma instância VPLS no roteador 0
[edit] interfaces { ps0 { flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { encapsulation ethernet-ccc; } unit 1 { family bridge { interface-mode trunk; vlan-id 1; } } ge-0/0/0 { unit 1 { encapsulation vlan-bridge; vlan-id 1; family bridge; } } } routing-instances { vpls-1 { instance-type virtual-switch; protocols { vpls { site PE3 { interface ps0.1; site-identifier 1; } } } bridge-domains { bd1 { vlan-id 1; } } interface ps0.1; route-distinguisher 65001:1; vrf-target target:1:1; } }
Serviço pseudowire em uma interface lógica de serviço em um circuito de Camada 2 no roteador 0
[edit] interfaces { ps0 { unit 0 { encapsulation ethernet-ccc; } unit 1 { encapsulation vlan-ccc; vlan-id 1; } unit 2 { encapsulation vlan-ccc; vlan-id 2; } } ge-0/0/0 { unit 1 { encapsulation vlan-vpls; vlan-id 1; family vpls; } unit 2 { encapsulation vlan-vpls; vlan-id 2; family vpls; } } ge-2/0/6 { unit 0 { family inet { address 10.11.2.1/24; } family mpls; } } } protocols { mpls { label-switched-path to_192.0.2.2 { to 192.0.2.2; } } bgp { group RR { type internal; local-address 192.0.3.3; } } l2-circuit { neighbor 192.0.2.2 { interface ps0.0 { virtual-circuit-id 100; } } neighbor 10.10.10.10 { interface ps0.1 { virtual-circuit-id 1; } } neighbor 10.11.11.11 { interface ps0.2 { virtual-circuit-id 2; } } } }
Opções de entrega de serviços de acesso de banda larga
Existem hoje quatro opções de entrega primárias para o fornecimento de serviços de rede de banda larga. Essas opções incluem:
Linha de assinantes digitais
A linha de assinantes digitais (DSL) é a tecnologia de banda larga mais amplamente implantada em todo o mundo. Essa opção de entrega usa linhas telefônicas existentes para enviar informações de banda larga em uma frequência diferente da usada para o serviço de voz existente. Muitas gerações de DSL são usadas para serviços residenciais, incluindo a Linha 2 de Assinante Digital de Alta Velocidade (VDSL2) e versões da Linha Assimétrica de Assinantes Digitais (ADSL, ADSL2 e ADSL2+). Essas variações de DSL oferecem principalmente serviço assimétrico de banda larga residencial, onde diferentes velocidades upstream e downstream são implementadas. (O VDSL2 também oferece suporte à operação simétrica.) Outras variações de DSL, como a linha de assinantes digitais (HDSL) de alta taxa e a linha de assinantes digitais simétricos (SDSL), fornecem velocidades simétricas e são normalmente usadas em aplicativos de negócios.
A ponta de frente para um sistema DSL é o Multiplexer de acesso de linha para assinantes digitais (DSLAM). O dispositivo de demarcação na instalação do cliente é um modem DSL. Os modelos de serviço de DSL são definidos pelo Broadband Forum (anteriormente chamado de DSL Forum).
Ethernet ativa
A Active Ethernet usa a tecnologia Ethernet tradicional para fornecer serviço de banda larga em uma rede de fibra óptica. A Ethernet ativa não oferece um canal separado para o serviço de voz existente, de modo que o equipamento VoIP (ou TDM-to-VoIP) é necessário. Além disso, o envio de Ethernet de velocidade total (10 ou 100 Mbps) requer energia significativa, exigindo distribuição para switches Ethernet e repetidores ópticos localizados em gabinetes fora do escritório central. Devido a essas restrições, as primeiras implantações active ethernet normalmente aparecem em áreas densamente povoadas.
Redes ópticas passivas
A Rede Óptica Passiva (PON), como a Active Ethernet, usa cabos de fibra óptica para entregar serviços às instalações. Essa opção de entrega oferece velocidades mais altas que a DSL, mas velocidades mais baixas que a Active Ethernet. Embora a PON forneça uma velocidade mais alta a cada assinante, ela requer um investimento maior em cabo e conectividade.
Uma vantagem fundamental da PON é que ela não requer nenhum equipamento alimentado fora do escritório central. Cada fibra que sai do escritório central é dividida usando um divisor óptico não alimentado. A fibra dividida segue então uma conexão ponto a ponto com cada assinante.
As tecnologias PON se incorporam a três categorias gerais:
ATM PON (APON), PON de banda larga (BPON) e PON com capacidade para Gigabit (GPON) — padrões pon que usam as seguintes opções de entrega diferentes:
APON — O primeiro padrão de rede óptica passiva é usado principalmente para aplicativos de negócios.
BPON — Com base no APON, o BPON adiciona multiplexação de divisão de ondas (WDM), alocação dinâmica e superior de largura de banda upstream e uma interface de gerenciamento padrão para permitir redes de fornecedores mistos.
GPON — O GPON é baseado no BPON, mas oferece suporte a taxas mais altas, segurança aprimorada e uma escolha da qual o protocolo de Camada 2 deve usar (ATM, Modelo de equipamento genérico [GEM]ou Ethernet).
Ethernet PON (EPON)— oferece recursos semelhantes ao GPON, BPON e APON, mas usa padrões Ethernet. Esses padrões são definidos pelo IEEE. Gigabit Ethernet PON (GEPON) é a versão de mais alta velocidade.
PON de multiplexação de divisão de ondas (WDM-PON) — uma PON fora do padrão que, como o nome indica, fornece um comprimento de onda separado para cada assinante.
A ponta de frente para um sistema PON é um Terminator de Linha Óptica (OLT). O dispositivo de demarcação nas instalações do cliente é um Terminator de Rede Óptica (ONT). O ONT oferece portas laterais de assinantes para conectar Ethernet (RJ-45), cabos telefônicos (RJ-11) ou cabo coaxial (F-connector).
Coaxial de fibra híbrida
As operadoras multissistema (MSOs; também conhecidas como operadoras de TV a cabo) oferecem serviço de banda larga por meio de sua rede híbrida de fibra coaxial (HFC). A rede HFC combina fibra óptica e cabo coaxial para entregar serviço diretamente ao cliente. Os serviços saem do escritório central (CO) usando um cabo de fibra óptica. O serviço é então convertido fora do CO para uma árvore de cabo coaxial usando uma série de nós ópticos e, quando necessário, através de um amplificador de radiofrequência (RF) de tronco. Os cabos coaxiais então se conectam a vários assinantes. O dispositivo de demarcação é um modem de cabo ou set-top box, que conversa com um sistema de terminação de modem de cabo (CMTS) na instalação de ponta ou principal do MSO que recebe sinais de televisão para processamento e distribuição. O tráfego de banda larga é transportado usando o padrão Data Over Cable Service Interface Specification (DOCSIS) definido pelo CableLabs e muitas empresas contribuintes.
Entrega de banda larga e FTTx
Muitas implementações usam cabeamento de cobre existente para entregar sinal ao local, mas a conectividade de cabos de fibra óptica está se aproximando do assinante. A maioria das redes usa uma combinação de cabeamento de cobre e fibra óptica. O termo fibra para x (FTTx) descreve o quão longe o cabeamento de fibra óptica da rede é executado antes que um switch para cabeamento de cobre ocorra. Tanto a PON quanto a Active Ethernet podem usar porção de fibra óptica da rede, enquanto o xDSL é normalmente usado na porção de cobre. Isso significa que uma única vertente de fibra óptica pode suportar vários assinantes baseados em cobre.
Aumentar o uso de fibra na rede aumenta o custo, mas também aumenta a velocidade de acesso à rede para cada assinante.
Os termos a seguir são usados para descrever o ponto de terminação do cabo de fibra óptica em uma rede:
Fibra para as instalações (FTTP), Fibra para a Casa (FTTH), Fibra para o Negócio (FTTB) — a fibra se estende até o assinante. A PON é mais comum para acesso residencial, embora a Active Ethernet possa ser usada de forma eficiente em áreas densas, como complexos de apartamentos. A Ethernet ativa é mais comum na prestação de serviços às empresas.
Fibra até o meio-fio (FTTC) — A fibra estende a maior parte do caminho (normalmente, 500 pés/150 metros ou menos) para o assinante. O cobre existente é usado para a distância restante para o assinante.
Fibra para o nó/bairro (FTTN) — A fibra se estende a poucos milhares de metros do assinante e convertida em xDSL para a distância restante para o assinante.
Fiber to the Exchange (FTTE) — uma implementação xDSL típica baseada em escritório central na qual a fibra é usada para entregar tráfego ao escritório central e xDSL é usada no loop local existente.
Entendendo o suporte do BNG para implantações DSLAM em cascata por canais DSL ligados
O Junos OS oferece suporte à configuração e manutenção das linhas de acesso entre nós de acesso e seus assinantes ANCP usando o multiplexador de acesso DSL como a tecnologia de acesso de banda larga para Copper-to-the-Building (CuTTB) e Fiber-to-the-Building (FTTB). Quando vários assinantes compartilham a mesma linha de acesso, a linha de acesso pode ser um dos seguintes tipos:
PON, fibra para o edifício (FTTB)
DSL com ligação entre cobre e edifício (CTTB)
A partir do Junos OS Release 18.2R1, as tecnologias de acesso de rede óptica passiva (PON) são suportadas com quatro níveis de hierarquia de agendamento de qualidade de serviço (QoS) para assinantes residenciais em uma implantação BBE. Esse recurso estende a implementação do Protocolo de Controle de Nós de Acesso (ANCP) para lidar com a configuração da rede para clientes residenciais que usam a PON como tecnologia de acesso de banda larga para CuTTB e FTTB. A ANCP usa um perfil de controle de tráfego controlado estaticamente no conjunto de interface para ser moldado no nível de assinante no nó intermediário ao qual os assinantes estão conectados. Novos tipos de DSL são fornecidos para oferecer suporte ao ajuste da taxa de linha de acesso para as novas tecnologias de acesso.
Um novo RADIUS VSA, Inner-Tag-Protocol-Id
26-211 é introduzido para obter o valor interno do Identificador de Protocolo de Tag VLAN para assinantes L2BSA para permitir a manutenção de um perfil dinâmico em vez de dois perfis dinâmicos separados. Uma nova variável $junos-inner-vlan-tag-protocol-id de perfil dinâmico do Junos OS permite que um mapa de inner-tag-protocol-id
VLAN seja definido pelo RADIUS ou por um valor padrão predefinido fornecido na configuração.
- Benefícios das implantações DSLAM em cascata por canais DSL ligados
- Hierarquia de agendador de 4 níveis
- Casos de uso de implantações DSLAM em cascata por canais DSL ligados
- DSL ligado para cobre até o edifício (CuTTB)
- PON híbrido + G.fast
- Recursos suportados
Benefícios das implantações DSLAM em cascata por canais DSL ligados
Esse recurso é útil para oferecer suporte a implantações de rede de acesso onde vários assinantes compartilham a mesma linha de acesso engrandeceda por um nó intermediário entre o nó de acesso e os gateways de roteamento doméstico. Outro benefício é conservar nós CoS de Camada 2. Normalmente, um nó de Camada 2 fictício é criado para cada casa residencial, o que poderia esgotar os recursos de CoS de Camada 2. Portanto, modelos de rede que utilizam modelos de acesso DSL, G.Fast e PON podem conservar nós CoS de Camada 2.
Hierarquia de agendador de 4 níveis
O Junos OS oferece suporte mínimo à hierarquia do agendador QoS de 4 níveis que oferece suporte mínimo ao acesso residencial e L2BSA em implantações de rede de acesso residencial e L2BSA sobre Cobre até o edifício (CTTB) ou fibra para o edifício. Os seguintes níveis de hierarquia de agendador QoS são suportados:
Porta de nível 1 (interface física ou AE)
Linha de acesso nível 2 (conjunto de interface lógica, representa uma coleção de assinantes compartilhando uma determinada linha de acesso agregada por um nó intermediário)
Sessões de assinantes de nível 3
Filas de nível 4 (serviços)

Na Figura 5, o acesso residencial e L2BSA requer apenas hierarquia de agendamento de 4 níveis. O acesso a assinantes empresariais atualmente não é suportado e, portanto, a hierarquia de agendador de 4 níveis é suficiente para serviços CuTTB e PON direcionados a um edifício de apartamentos.
Casos de uso de implantações DSLAM em cascata por canais DSL ligados
O DSL ligado para cobre ao edifício (CuTTB) introduz um nó intermediário unidade-cobre de ponto de distribuição (DPU-C) entre o multiplexador de acesso DSL (DSLAM) e um cluster de assinantes no local do cliente. Os modelos de implantação de linha de acesso compartilhado podem ser do tipo Rede Óptica Passiva (PON) ou linhas de cobre DSL vinculadas. Os nós intermediários de exemplo estão listados abaixo:
DPU-C - DSL vinculada para Cobre-To-The-Building (CTTB)
ONU - PON (Fibra até o edifício (FTTB)
PON híbrida e G.Fast
DSL ligado para cobre até o edifício (CuTTB)

Na Figura 6, cada DPU-C tem uma sessão ANCP para relatar parâmetros de linha de acesso de assinantes individuais conectados ao nó. O MSAN também tem uma sessão da ANCP para relatar parâmetros de linha de acesso da linha de acesso DSL vinculada à DPU-C. Todos os assinantes conectados à DPU-C estão, portanto, sujeitos à taxa de downstream da linha de acesso DSL, os assinantes de DPU-C são agrupados em um conjunto de interface. Você pode ajustar as velocidades relatadas nesta Porta-Up e aplicar ao nó CoS para a interface correspondente ste manter a semântica do perfil de controle de ajuste cos que é usado para linhas de assinantes individuais. O modelo de acesso consiste em um híbrido de acesso DSL ligado e acesso convencional sembono. As sessões de DPU-C e de nó de acesso multisserviário (MSAN) da ANCP são completamente independentes e as tags PPPoE-IA refletem apenas os atributos relatados na sessão de DPU-C ANCP
PON híbrido + G.fast

Na Figura 7, o OLT tem uma sessão ancp com o BNG e os proxys para todos os nós PON nativos a jusante. Os assinantes de DSL rápidos são conectados a um nó intermediário, que tem uma conexão PON com a ONU intermediária em frente ao OLT.
Uma rede de acesso híbrido conecta linhas de assinantes baseadas em DSL usando acesso PON e nós G.fast com um nó intermediário entre o OLT e os gateways domésticos (HGs). Tanto empresas quanto residências estão conectadas ao nó intermediário, que é a folha pon. A modelagem é necessária tanto no nível de assinante quanto no nível leaf da PON. Os assinantes Ths G.fast estão associados à ONU intermediária, como um assinante nativo da PON. Novas TLVs do tipo DSL têm o suporte da AN e seus valores são relatados na porta-up da ANCP para a linha de acesso ao assinante correstpnding. No entanto, ainda não é possível distinguir entre um nó intermediário e uma conexão convencional para uma determinada sessão de PPPoE.
Recursos suportados
Suporte a modelagem de tráfego baseada em ANCP em iflsets dinâmicos.
Preservação da independência da PPP0E-IA e ANCP pela configuração da CLI para assinantes residenciais.
Novo Juniper VSA, ERX-Inner-Vlan-Tag-Protocol-Id (4874-26-211) é suportado para obter o valor interno do Identificador de Protocolo de Tag VLAN para assinantes L2BSA como uma otimização para manter dois, perfis dinâmicos separados, um para TPID — 0x88a8 e outro para 0x8100, e fornecendo o valor desejado retornando 4874-26-174 (Nome do cliente-perfil) no Access-Accept.
Os seguintes valores de tipo adicionais para o DSL tipo TLV são suportados. Todos os assinantes incluem essas TLVs do tipo DSL nas tags DE PPPoE PADR das mensagens PPPoE.
(8) G.fast
(9) Anexo Q do VDSL2
(10) SDSL ligado
(11) Ligação VDSL2
(12) G,ligação rápida
(13) Anexo Q VDSL2 ligado
Detecção de identificadores de linha de backhaul e autogeração de conjuntos de interface de nós intermediários
Antes de começar, você deve confirmar que seus nós de acesso ou IAs existentes ainda não estão inserindo strings que começam com o #
personagem. Como esta é uma configuração de nível de sistema, a análise se aplica a todos os nós de acesso ANCP e IAs de PPPoE globalmente. O personagem principal #
não é configurável. A análise é desabilitada por padrão no caso de alguns provedores usarem esse caractere para alguma outra finalidade.
A partir do Junos OS Release 18.4R1, você pode configurar o roteador para detectar um nó intermediário lógico em uma rede de acesso. O nó identifica assinantes conectados à mesma mídia compartilhada, como uma árvore PON ou uma linha de cobre conectada que se conecta a uma DPU-C para CuTTB. Ao configurar essa detecção, o roteador analisa o atributo ANCP Access-Aggregation-Circuit-ID-ASCII (TLV 0x03) que é recebido na mensagem de porta up da ANCP ou nas tags DE PADR do PPPoE. Se a corda TLV começar com o #
caractere, a corda será um identificador de linha de backhaul que é único em toda a rede para identificar a linha DSL ou a árvore PON vinculada. A mesma seqüência é relatada no TLV ou IA para todos os assinantes conectados a essa DPU-C ou PON.
A parte da corda após o #
caractere representa o nó intermediário lógico. Ele é usado como o nome do conjunto de interface dinâmica para o nó CoS Level 2 que agrupa os assinantes usando esse nó intermediário. Este conjunto de interface é conhecido como o conjunto de interface dos pais. Cada interface lógica de PPPoE ou VLAN (L2BSA) com o mesmo valor para o TLV 0x03 é um membro desse conjunto de interface.
O valor do TLV deve corresponder aos requisitos para a nomenclatura do conjunto de interfaces; pode incluir caracteres alfanuméricos e os seguintes caracteres especiais:
# % / = + - : ; @ . _
Essa parte da corda também define o valor da variável predefinida predefinida de $junos-agregação-interface-interface-set-name no perfil dinâmico. Esse valor é usado como o nome de um conjunto de interface CoS Level 2 que agrupa os assinantes compartilhando essa string. Ele substitui o padrão variável predefinido, que usa o valor de $junos-phy-ifd-interface-set-name como o nome do conjunto de interface.
Por exemplo, se o valor da string TLV for #TEST-DPU-C-100, o valor da variável predefinida e, consequentemente, o nome do conjunto de interface, se tornará TEST-DPU-C-100.
O Access-Loop-Remote-ID (TLV (0x02) é igualmente analisado para o #
personagem, mas a seqüência resultante não é usada na versão atual.
A detecção de nós intermediários é suportada apenas para hierarquias de agendador de 4 níveis, de modo que o acesso comercial é limitado aos MPCs de acesso DSL convencionais.
Para permitir a análise do Access-Aggregation-Circuit-ID-ASCII TLV e definir o nome do conjunto de interface:
A configuração de amostra a seguir mostra um perfil dinâmico para assinantes L2BSA. Três coisas a notar aqui são as seguintes:
Um valor padrão de $junos-phy-ifd-interface-set-name é definido para a variável predefinida $junos-agregação-interface-set-name.
O nome do conjunto de interface está configurado para ser o valor de $junos-agregação-interface-set-name.
A configuração do agendador CoS especifica uma interface nomeada com o valor de $junos-agregação-interface-set-name.
Quando hierarchical-access-network-detection
está configurado para as linhas de acesso, então o nome do conjunto de interface do agendador de Nível 2 é determinado da seguinte forma:
Quando o TLV 0x03 começa,
#
então $junos-agregação-interface-set-name é o restante da corda, excluindo o inicial#
.Quando a TLV 0x03 começa com qualquer outro personagem, então $junos-agregação-interface-set-name é o valor do $junos-phy-ifd-interface-set-name.
[edit dynamic-profiles L2BSA-subscriber] predefined-variable-defaults { aggregation-interface-set-name phy-ifd-interface-set-name; cos-shaping-rate 1g; cos-scheduler-map schedmap_L2BSA; inner-vlan-tag-protocol-id 0x88a8; } routing-instances { "$junos-routing-instance" { interface "$junos-interface-name"; } } interfaces { interface-set $junos-aggregation-interface-set-name { interface "$junos-interface-ifd-name" { unit "$junos-interface-unit"; } } "$junos-interface-ifd-name" { unit "$junos-interface-unit" { encapsulation vlan-vpls; no-traps; vlan-id "$junos-vlan-id"; input-vlan-map { swap-push; inner-tag-protocol-id "$junos-inner-vlan-tag-protocol-id" vlan-id "$junos-vlan-map-id"; inner-vlan-id "$junos-inner-vlan-map-id"; } output-vlan-map { pop-swap; inner-tag-protocol-id 0x8100; } family vpls; } } } class-of-service { traffic-control-profiles { L2BSAShaper { scheduler-map "$junos-cos-scheduler-map"; shaping-rate "$junos-cos-shaping-rate" burst-size 17k; overhead-accounting frame-mode cell-mode-bytes 6; } L2iflsetShaper { shaping-rate 1G burst-size 17k; } } interfaces { "$junos-interface-ifd-name" { unit "$junos-interface-unit" { output-traffic-control-profile L2BSAShaper; classifiers { ieee-802.1 L2BSA vlan-tag outer; } rewrite-rules { ieee-802.1 L2BSA vlan-tag outer; } } } interface-set "$junos-aggregation-interface-set-name" { output-traffic-control-profile L2iflsetShaper; } } }
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.