Linhas de acesso e velocidades de conexão para assinantes L2TP

Encaminhamento de informações da linha de acesso

Na topologia de rede mostrada na Figura 1, quando um assinante inicia uma conexão através do CPE, o DSLAM transmite a sessão PPPoE do assinante para o roteador configurado como um LAC. Quando o roteador estabeleceu a sessão de PPPoE, o LAC inicia um túnel L2TP para encaminhar os pacotes PPP encapsulados do assinante para a rede do provedor.

Em paralelo à sessão de PPPoE, uma conexão ANCP entre o DSLAM e o agente ANCP no roteador transmite informações sobre o loop local do assinante, bem como as velocidades de link das sessões de PPPoE no loop local. O DSLAM envia as cordas de Id de Circuito de Agente de Roteador (ACI) e ID Remota de Agente (ARI) que identificam de forma exclusiva a interface de recebimento do DSLAM; essas informações estão codificadas nas mensagens de porta para cima e para baixo da ANCP como linha de acesso identificando TLVs. As mensagens ANCP também podem incluir atributos de linha, como taxas de dados de upstream e downstream líquidas mínimas, máximas e reais no TLV dos atributos de linha DSL. O DSLAM também pode enviar os atributos da linha de acesso em tags específicas do fornecedor que ele insere nas mensagens PADI e PADR.

Figura 1: Topologia de rede L2TP de amostra

AVPs com informações da linha de acesso

O L2TP oferece suporte aos AVPs listados na Tabela 1 para levar essas informações. As informações da linha de acesso não são necessárias para que a sessão L2TP seja iniciada, e o estabelecimento dessa sessão não está atrasado à espera de que os valores sejam enviados do nó de acesso. O conteúdo da mensagem ICRQ geralmente varia entre as linhas de acesso DSL e as linhas de acesso PON. AVPs, 1, 2, 3 e 6 são usados para identificação de linha de acesso para DSL e PON. Se as informações da PON forem relatadas usando AVPs DSL, o conteúdo será o mesmo para acesso DSL.

As informações da linha de acesso fornecidas pelos AVPs em mensagens ICRQ são repassadas ao RADIUS no DSL Forum VSAs. Ele não é usado para moldar a taxa de tráfego nas linhas de acesso dos assinantes.

Atualizações de velocidade de conexão no LAC

Você pode configurar o LAC para notificar a LNS quando a velocidade da conexão do assinante mudar dos valores inicialmente comunicados à LNS pelo AVP 24 (velocidade de transmissão) e AVP 38 (velocidade de recebimento) em mensagens De entrada conectadas (ICCN). Quando configurado para isso, o LAC informa à LNS que pode enviar essas atualizações incluindo a atualização de velocidade de conexão Habilite a AVP (98) na mensagem ICRQ quando a sessão L2TP começar. A ausência da atualização do Connect Speed Enable AVP (98) na mensagem ICRQ indica que o LAC não envia atualizações para a vida da sessão.

Quando a velocidade da conexão muda, o DSLAM notifica o agente ANCP. O agente ancp então notifica o LAC, e o LAC, por sua vez, transmite essas informações para a LNS enviando uma mensagem de notificações de atualização de velocidade de conexão (CSUN) que inclui as velocidades atualizadas em uma AVP de atualização de velocidade de conexão (97) para cada sessão. O LAC coleta atualizações de velocidade de conexão e as envia em um lote para minimizar tanto a sobrecarga de desempenho no LAC quanto a quantidade de tráfego gerado como resultado dessas notificações.

As velocidades iniciais das mensagens ICCN e as velocidades atualizadas nas mensagens CSUN são usadas pela CoS para moldar a taxa de tráfego para linhas de acesso de assinantes.

A presença do Connect Speed Update Enable AVP (98) na mensagem ICRQ também informa à LNS que o LAC responde se receber uma mensagem de solicitação de atualização de velocidade de conexão (CSURQ) de uma LNS.

Uma LNS de terceiros pode enviar uma mensagem CSURQ a qualquer momento durante a vida de um túnel para solicitar a transmissão atual e receber velocidade de conexão para uma ou mais sessões L2TP. A LNS inclui os IDs de sessão remotos (relativos à LNS) na mensagem CSURQ. Se o LAC tiver enviado anteriormente a atualização do Connect Speed Enable AVP (98) para as sessões solicitadas, ele responderá ao CSURQ com uma mensagem de CSUN que inclui o Connect Speed Update AVP (97) para cada sessão. Se nenhuma alteração nas velocidades de conexão tiver ocorrido até este momento, o LAC simplesmente inclui os valores iniciais de velocidade de conexão que foram relatados em AVP 24 e AVP 38.

Quando você permite conectar atualizações de velocidade globalmente ou para uma LNS específica, o LAC não envia mensagens CSUN a menos que você também tenha configurado a tx-connect-speed declaração para ser ancp ou service-profile.

Atualizações de velocidade de conexão no LNS

A partir do Junos OS Release 17.4R1, um roteador da Série MX configurado como LNS pode processar informações da linha de acesso do assinante e atualizações de velocidade de conexão que recebe do LAC. O roteador da Série MX não pode enviar mensagens CSURQ para solicitar atualizações do LAC.

As velocidades iniciais das mensagens ICCN e as velocidades atualizadas nas mensagens CSUN são usadas pela CoS para moldar a taxa de tráfego para linhas de acesso de assinantes.

Interação entre configurações globais e por destino

Você pode configurar o LAC para encaminhar as informações da linha de acesso na mensagem ICRQ que ela envia para a LNS e você pode configurar a LNS para receber e processar essas informações. Você pode configurar isso globalmente para todos os destinos (endpoints) ou para um destino específico. A configuração por destino permite que você limite a transmissão a uma LNS individual ou a um conjunto de LNSs ou recepção de um LAC individual ou de um conjunto de LACs. Isso é útil quando você sabe que alguns gateways remotos não suportam esse recurso ou têm uma implementação incorreta.

Inclua a access-line-information declaração em um ou ambos os seguintes níveis de hierarquia no LAC ou LNS, respectivamente, para configurar o LAC para encaminhar as informações da linha de acesso na mensagem ICRQ que ele envia para o LNS, ou para configurar o LNS para receber e processar essas informações:

• [edit services l2tp]— Configura o encaminhamento global para todos os destinos.

• [edit services l2tp destination ip-address]— Configura o encaminhamento para um destino específico.

Para configurar o LAC para enviar atualizações de velocidade de conexão ou LNS para receber e processar as atualizações, inclua a opção connection-speed-update com a access-line-information declaração no nível de hierarquia apropriado no LAC ou LNS, respectivamente.

As configurações globais e por destino interagem da seguinte maneira:

• Informações de linha de acesso — Quando o encaminhamento pelo LAC ou o processamento pela LNS são habilitados globalmente, você não pode desabilitar a configuração global para um destino específico.

• Atualizações de velocidade de conexão — Quando o encaminhamento pelo LAC ou o processamento pela LNS é habilitado globalmente, você pode desabilitar a configuração global para um destino específico (LNS ou LAC) especificando para o destino e omitindo access-line-information connection-speed-update.

Métodos para determinar os valores de velocidade relatados à LNS

Os valores relatados ao LNS podem ser derivados das seguintes maneiras:

• Você pode configurar um método globalmente para o LAC com a tx-connect-speed-method declaração no nível de [edit services l2tp] hierarquia. Você pode especificar qualquer um dos seguintes métodos para determinar a fonte para velocidades de conexão:

  Nota:

  A partir do Junos OS Release 13.3R1, a disponibilidade e o suporte para métodos variam de acordo com a versão do Junos OS, conforme descrito na Tabela 2. A lista a seguir inclui todos os métodos históricos; alguns dos métodos podem não ser suportados na versão de software que você está usando.

  • actual— A velocidade é a taxa real do tráfego downstream aplicado no nó do agendador de sessão com base na política local de controle de tráfego. Apenas a velocidade de conexão de transmissão está disponível com este método, de modo que a velocidade de transmissão de recebimento é determinada pelo esquema de fallback. Use o actual método quando precisar do valor relatado para ser a velocidade de downstream aplicada pela política local de CoS. Outros métodos podem variar desse valor aplicado.

    O actual método só é suportado quando a effective shaping-rate declaração é incluída no nível de [edit chassis] hierarquia. A verificação de confirmação da CLI falha se actual estiver configurada, mas a taxa de modelagem eficaz não está configurada.

    Nenhuma verificação de confirmação é realizada quando o Tunnel-Tx-Speed-Method VSA (26-94) é definido, de modo que uma mensagem de log do sistema é gerada nesta situação para lembrar o usuário a configurar a taxa de modelagem eficaz.

  • ancp— A velocidade é o valor upstream e downstream ajustado de origem ANCP que resulta de uma correção percentual configurada para os valores reais do ANCP. O ajuste é aplicado por DSL para explicar as diferenças de encapsulamento de ATM entre o BNG e o loop de acesso e para a sobrecarga de transporte de Camada 1. A taxa inicial enviada à LNS é o valor ancp relatado no momento em que o ICCN é enviado. Quaisquer alterações subseqüentes são enviadas como atualizações para a LNS na mensagem do CSUN.

  • none— Essa opção impede que o LAC envie AVP 24 ou AVP 38 na mensagem da ICCN; consequentemente, também não são enviadas mensagens de CSUN. A LNS precisa estabelecer sua própria política de upstream e downstream na ausência desses valores. Essa opção substitui os JUNiper Networks RADIUS VSAs, Tx-Connect-Speed (26-162) e Rx-Connect-Speed (26-163), bem como qualquer outro método configurado para a velocidade de conexão.

  • pppoe-ia-tags— A velocidade é derivada do valor enviado do DSLAM para o LAC nas tags de agente intermediário (IA) do protocolo de ponto a ponto (PPPoE). Para interfaces Ethernet, a velocidade é um valor não ajustado; para interfaces atm, o valor pode ser um valor ajustado se a tag incluir o atributo Encapsulation Overhead (0x90).

    Esse valor de velocidade é transmitido quando a sessão L2TP é estabelecida. Embora o valor da tag IA do PPPoe não mude durante uma sessão, a velocidade relatada ao LAC pode mudar. Por exemplo, suponha que o método configurado seja service-profile. O perfil não é ativado antes que o ICCN seja enviado e recai sobre a tag IA do PPPoE, que é enviada na mensagem ICCN. Quando o perfil de serviço é ativado mais tarde, as taxas de perfil do serviço são enviadas em uma mensagem de atualização (se as atualizações forem configuradas).

  • service-profile— Dependendo da versão do Junos OS, existem duas maneiras de usar perfis de serviço para fornecer velocidades de conexão. Um método usa as velocidades do perfil de serviço apenas em mensagens CSUN, o outro método em mensagens ICCN.

    • Em mensagens CSUN — A velocidade downstream (Tx) é derivada do CoS real que é aplicado no nó L3 com base na política local. A velocidade de upstream (Rx) é retirada do valor configurado no perfil de serviço; nenhum ajuste é feito a esse valor.

      Por padrão, os perfis de serviço não são ativados antes da sessão do assinante ser estabelecida, de modo que este método recai sobre outro método para os valores enviados no ICCN. Quando o perfil é ativado mais tarde, essas taxas são enviadas para a LNS em uma mensagem CSUN, se as atualizações forem ativadas.

    • Nas mensagens da ICCN — A partir do Junos OS Release 18.1R1, você pode usar um perfil de serviço dinâmico para fornecer as velocidades de conexão incluídas no AVP 38 e AVP 24 na mensagem do ICCN quando a sessão L2TP é negociada. No login do assinante, authd determina se o nome do perfil de serviço transmitido no Juniper Networks Activate-Service VSA (26-65) na mensagem RADIUS Access-Accept corresponde ao nome do perfil do serviço configurado com a service-rate-limiter declaração no [edit access] nível de hierarquia. Se os nomes corresponderem, as velocidades serão derivadas de valores padrão no perfil de serviço ou de parâmetros passados pelo VSA. Veja especificando um perfil de serviço com limitação de taxa para velocidades de conexão L2TP para obter mais informações sobre esse método.

    O service-profile método só é suportado quando a effective shaping-rate declaração é incluída no nível de [edit chassis] hierarquia. A verificação de confirmação da CLI falha quando service-profile está configurada, mas a taxa de modelagem eficaz não está configurada.

    Nenhuma verificação de confirmação é realizada quando o Tunnel-Tx-Speed-Method VSA (26-94) é definido, de modo que uma mensagem de log do sistema é gerada nesta situação para lembrar o usuário a configurar a taxa de modelagem eficaz.

    Melhores práticas:

    Recomendamos que você use apenas um perfil de serviço por sessão de assinante para afetar a taxa de modelagem downstream ou relatar uma taxa de upstream. Se mais de um perfil dinâmico de serviço for aplicado à sessão de assinantes de modo que cada um afete a taxa de modelagem downstream ou reporte a taxa de upstream, os valores do perfil aplicado mais recentemente são relatados pelo L2TP. A desativação do serviço mais recentemente aplicado não resulta em L2TP relatando a velocidade de upstream para um perfil de serviço (ativo) existente.

  • static— Esse método faz com que o LAC desfaça a velocidade da velocidade estática configurada de Camada 2. Para VLANs Ethernet, esta é a taxa de modelagem (consultiva) recomendada configurada na interface lógica de PPPoE subjacente à interface do assinante. Se a taxa de modelagem de consultoria não estiver configurada na interface subjacente, então a velocidade real da porta física subjacente é usada.

• A partir do Junos OS Release 15.1R1, você pode configurar valores de velocidade diretamente nos VSAs da Juniper Networks, Tx-Connect-Speed (26-162) e Rx-Connect-Speed (26-163). Esses VSAs podem ser devolvidos na mensagem RADIUS Access-Accept. Se apenas um dos VSAs estiver presente, o LAC usa um método de velocidade de conexão para determinar o valor para a outra velocidade. Para usar esses VSAs, você deve configurar o RADIUS de acordo com a documentação do servidor RADIUS.

• A partir do Junos OS Release 15.1R1, você pode configurar um método que é transmitido no Juniper Networks VSA, Tunnel-Tx-Speed-Method (26-94). Se configurado, este VSA é devolvido na mensagem RADIUS Access-Accept para assinantes individuais. O valor da VSA se aplica globalmente e não a um túnel específico. O método configurado nesta VSA especifica o recurso que o LAC usa para definir a velocidade. Para usar esse VSA, você deve configurar o RADIUS de acordo com a documentação do servidor RADIUS.

• Quando as velocidades não podem ser determinadas de outra maneira, a velocidade de porta da interface do assinante é usada.

A Tabela 2 lista os métodos disponíveis até o lançamento.

Nas versões Junos OS 15.1, 16.1, 16.2 e 17.1 (que suportam o actual método), os valores de velocidade no AVP 24 e no AVP 38 normalmente não são maiores do que o valor que é aplicado pela CoS no lado LAC da rede. Qualquer diferença entre a velocidade relatada nesses AVPs e a aplicada pelo CoS é atribuível às diferenças entre a configuração de CoS (da fonte usada para aplicar uma velocidade de downstream) e o método de velocidade de conexão Tx usado para estabelecer esses AVPs.

Determinar as velocidades iniciais de conexão

Antes que o LAC possa enviar velocidades iniciais de transmissão e de conexão na mensagem de ICCN para a LNS, ele precisa fazer o seguinte:

1. Selecione o método que usa para obter as velocidades.

2. Determine as velocidades.

O LAC seleciona o método da seguinte forma:

1. Se o Método de Túnel-Tx-Velocidade VSA (26-94) estiver presente, use o método especificado pelo valor VSA.

2. Caso contrário, use o método configurado na CLI com a tx-connect-speed-method declaração.

O LAC determina a velocidade inicial da seguinte forma:

1. Se o método selecionado for none, o LAC não inclui as velocidades de transmissão e recebimento no ICCN.

2. Para qualquer outro método selecionado, se os valores nos VSAs Tx-Connect-Speed (26-162) e Rx-Connect-Speed (26-163) não forem reais, o LAC envia esses valores no ICCN.

3. Se os valores VSA forem zero, use o método selecionado determinado para obter os valores a serem enviados.

Considere os seguintes exemplos:

• O VSA 26-94 é recebido com ancp configuração como o método. O método CLI está configurado como none. O LAC seleciona o valor VSA 26-94, o ancp método.

  O VSA 26-162 e o VSA 26-163 são recebidos com valores nãozeros. O LAC envia esses valores VSA no ICCN.

• O VSA 26-94 é recebido com ancp configuração como o método. O método CLI está configurado como none. O LAC seleciona o valor VSA 26-94, o ancp método.

  O VSA 26-162 e o VSA 26-163 são recebidos com valores zero. O LAC usa o ancp método para obter os valores para enviar o ICCN.

• O VSA 26-94 é recebido com none configuração como o método. O método CLI está configurado como ancp. O LAC seleciona o valor noneVSA 26-94 e não envia velocidades de conexão no ICCN.

• O VSA 26-94 não é recebido. O método CLI está configurado como none. O LAC não envia velocidades de conexão no ICCN.

Mecanismo de fallback para conectar valores de velocidade

Quando o LAC selecionou um método para obter as velocidades de conexão, ele volta a um método diferente em qualquer uma das seguintes circunstâncias:

• Um ou ambos os valores de velocidade de conexão não foram definidos pelo método selecionado (VSA 26-94 ou CLI).

• O valor da velocidade de conexão é zero.

Quando um valor está disponível e nãozero, mas o outro não, apenas o valor não definido cai de volta para um método diferente. Não há recuo quando o método selecionado é none, porque esse método impede que o LAC reporte as velocidades de conexão. O procedimento de fallback pode variar de acordo com a versão do Junos OS.

Considere os seguintes exemplos:

• O método selecionado é ANCP. O valor da ANCP para a velocidade de recebimento é considerado zero. O LAC envia o valor ancp para a velocidade de transmissão, mas o valor de recebimento cai de volta para o método de tag ia PPPoE. O LAC envia o valor da tag IA para a velocidade de recebimento.

• O método selecionado é ANCP. O valor da ANCP para a velocidade de recebimento é considerado zero. O LAC envia o valor ancp para a velocidade de transmissão, mas o valor de recebimento cai de volta para o método de tag ia PPPoE. O valor da tag IA para a velocidade de recebimento também é considerado zero, de modo que ele cai de volta ao método estático de Camada 2. Isso está disponível, de modo que o LAC envia o valor estático de Camada 2 para a velocidade de recebimento.

• O método selecionado é o perfil de serviço. O perfil de serviço não é ativado antes que o ICCN seja enviado, de modo que o LAC recai sobre o método ANCP. Ambos transmitem e recebem valores ancp estão disponíveis e não zero, de modo que o LAC envia esses valores no ICCN.

  O perfil de serviço é ativado por uma Mudança de Autorização (CoA) em algum momento posterior para a sessão. Se as atualizações forem habilitadas, o LAC envia os valores do perfil do serviço para a LNS em uma mensagem de CSUN. Se as atualizações não estiverem habilitadas, os valores do perfil do serviço não serão relatados à LNS.

  Observe que as atualizações exigem que o método seja configurado na CLI. Consequentemente, o VSA 26-94 não deve ser configurado ou recebido para que o método de perfil de serviço seja selecionado na configuração CLI.

A partir da versão 17.2R1 do Junos OS, o procedimento de recuo de LAC é descrito na Tabela 3.

A partir da versão 15.1R1 do Junos OS, o procedimento de recuo de LAC é descrito na Tabela 4.

A partir do Junos OS Release 13.3R1, o procedimento de recuo de LAC é descrito na Tabela 5.