Linhas de acesso do assinante L2TP e velocidades de conexão

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 retransmite a sessão PPPoE do assinante para o roteador configurado como um LAC. Quando o roteador estabelece a sessão 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 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 PPPoE no loop local. O DSLAM envia ao roteador cadeias de caracteres Agent Circuit Id (ACI) e Agent Remote Id (ARI) que identificam exclusivamente a interface de recebimento do DSLAM; essas informações são codificadas nas mensagens ANCP Port Up e Port Down como TLVs de identificação de linha de acesso. As mensagens ANCP também podem incluir atributos de linha, como taxas de dados upstream e downstream líquidas mínimas, máximas e reais, nos atributos de linha DSL TLV. O DSLAM também pode enviar os atributos de linha de acesso em tags específicas do fornecedor que insere nas mensagens PADI e PADR.

Figura 1: Topologia de rede L2TP de exemplo

Informações da linha de acesso AVPs

O L2TP oferece suporte aos AVPs listados na Tabela 1 para transportar 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 é atrasado aguardando 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. Os AVPs 1, 2, 3 e 6 são usados para identificação de linha de acesso para DSL e PON. Se as informações de PON forem relatadas usando AVPs DSL, o conteúdo será o mesmo que seria para acesso DSL.

As informações de linha de acesso fornecidas pelos AVPs em mensagens ICRQ são passadas para o RADIUS em VSAs do Fórum DSL. Ele não é usado para moldar a taxa de tráfego nas linhas de acesso do assinante.

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

Você pode configurar o LAC para notificar o LNS quando a velocidade da conexão do assinante mudar dos valores inicialmente comunicados ao LNS pelo AVP 24 (velocidade de transmissão) e AVP 38 (velocidade de recepção) em mensagens de chamada de entrada conectadas (ICCN). Quando configurado para fazer isso, o LAC informa ao LNS que pode enviar essas atualizações incluindo o Connect Speed Update Enable AVP (98) na mensagem ICRQ quando a sessão L2TP é iniciada. A ausência do Connect Speed Update Enable AVP (98) na mensagem ICRQ indica que o LAC não envia atualizações durante a vida útil 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, retransmite essas informações para o LNS enviando uma mensagem Connect-Speed-Update-Notification (CSUN) que inclui as velocidades atualizadas em um 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 lote para minimizar a sobrecarga de desempenho no LAC e a quantidade de tráfego gerado como resultado dessas notificações.

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

A presença do Connect Speed Update Enable AVP (98) na mensagem ICRQ também informa ao LNS que o LAC responde se receber uma mensagem Connect-Speed-Update-Request (CSURQ) de um LNS.

Um LNS de terceiros pode enviar uma mensagem CSURQ a qualquer momento durante a vida útil de um túnel para solicitar a velocidade de conexão atual de transmissão e recepção para uma ou mais sessões L2TP. O LNS inclui os IDs de sessão remotos (relativos ao LNS) na mensagem CSURQ. Se o LAC tiver enviado anteriormente o Connect Speed Update Enable AVP (98) para as sessões solicitadas, ele responderá ao CSURQ com uma mensagem 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é esse momento, o LAC simplesmente incluirá os valores iniciais de velocidade de conexão relatados no AVP 24 e no AVP 38.

Quando você habilita as atualizações de velocidade de conexão globalmente ou para um LNS específico, o LAC não envia mensagens CSUN, a menos que você também tenha configurado a tx-connect-speed declaração como ou ancp 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 um LNS pode processar informações de 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 nas mensagens ICCN e as velocidades atualizadas nas mensagens CSUN são usadas pelo CoS para moldar a taxa de tráfego para linhas de acesso do assinante.

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 ele envia ao LNS e pode configurar o 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 limitar a transmissão a um LNS individual ou a um conjunto de LNSs ou a recepção de um LAC individual ou de um conjunto de LACs. Isso é útil quando você sabe que alguns gateways remotos não oferecem suporte a esse recurso ou têm uma implementação incorreta.

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

• [edit services l2tp]— Configura o encaminhamento globalmente 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 o LNS para receber e processar as atualizações, inclua a connection-speed-update opção 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 da linha de acesso — quando o encaminhamento pelo LAC ou o processamento pelo LNS é habilitado 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 pelo LNS é habilitado globalmente, você pode desabilitar a configuração global para um destino específico (LNS ou LAC) especificando access-line-information para o destino e omitindo connection-speed-update.

Métodos para determinar os valores de velocidade relatados ao 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 origem das velocidades de conexão:

  Observação:

  A partir do Junos OS Release 13.3R1, a disponibilidade e o suporte para métodos variam de acordo com o Junos OS Release, 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 aplicada no nó do agendador de sessão com base na política de controle de tráfego local. Somente a velocidade de conexão de transmissão está disponível com esse método, portanto, a velocidade de transmissão de recepção é determinada pelo esquema de fallback. Use o actual método quando precisar que o valor relatado seja a velocidade downstream imposta pela política de CoS local. Outros métodos podem variar desse valor imposto.

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

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

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

  • none— Esta opção impede que o LAC envie AVP 24 ou AVP 38 na mensagem ICCN; consequentemente, nenhuma mensagem CSUN também é enviada. O LNS precisa estabelecer sua própria política upstream e downstream na ausência desses valores. Essa opção substitui os VSAs RADIUS da Juniper Networks, 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 do agente intermediário (IA) do Protocolo Ponto a Ponto sobre Ethernet (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 PPPoe IA 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 retorna para a tag PPPoE IA, que é enviada na mensagem ICCN. Quando o perfil de serviço é ativado posteriormente, as taxas do perfil de serviço são enviadas em uma mensagem de atualização (se as atualizações estiverem configuradas).

  • service-profile— Dependendo da versão do seu Junos OS, há 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 somente 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 upstream (Rx) é obtida do valor configurado no perfil de serviço; nenhum ajuste é feito para este valor.

      Por padrão, os perfis de serviço não são ativados antes que a sessão do assinante seja estabelecida, portanto, esse método retorna a outro método para os valores enviados no ICCN. Quando o perfil for ativado posteriormente, essas taxas serão enviadas ao LNS em uma mensagem CSUN, se as atualizações estiverem habilitadas.

    • Em mensagens 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 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 de serviço configurado com a service-rate-limiter declaração no nível de [edit access] 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. Consulte Especificando um perfil de serviço de 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ó tem suporte quando a effective shaping-rate instrução é incluída no nível da [edit chassis] hierarquia. A verificação de confirmação da CLI falha quando service-profile configurada, mas a taxa de modelagem efetiva não está configurada.

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

    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 upstream. Se mais de um perfil de serviço dinâmico for aplicado à sessão do assinante, de modo que cada um afete a taxa de modelagem downstream ou relate a taxa upstream, os valores do perfil aplicado mais recentemente serão relatados pelo L2TP. A desativação do serviço aplicado mais recentemente não resulta em L2TP relatando a velocidade upstream para um perfil de serviço existente (ativo).

  • static— Esse método faz com que o LAC derive a velocidade da velocidade estática de Camada 2 configurada. Para VLANs Ethernet, essa é a taxa de modelagem recomendada (consultiva) configurada na interface lógica PPPoE subjacente à interface do assinante. Se a taxa de modelagem de consultoria não estiver configurada na interface subjacente, a velocidade real da porta física subjacente será 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 retornados na mensagem RADIUS Access-Accept. Se apenas um dos VSAs estiver presente, o LAC usará um método de velocidade de conexão para determinar o valor da 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 VSA da Juniper Networks, Tunnel-Tx-Speed-Method (26-94). Se configurado, esse VSA é retornado na mensagem RADIUS Access-Accept para assinantes individuais. O valor VSA se aplica globalmente e não a um túnel específico. O método configurado neste VSA especifica o recurso que o LAC usa para definir a velocidade. Para usar este VSA, você deve configurar o RADIUS de acordo com a documentação do servidor RADIUS.

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

A Tabela 2 lista os métodos disponíveis por versão.

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

Determinando as velocidades iniciais de conexão

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

1. Selecione o método usado para derivar as velocidades.

2. Determine as velocidades.

O LAC seleciona o método da seguinte forma:

1. Se o VSA Tunnel-Tx-Speed-Method (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 instruçã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 recepção 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) forem diferentes de zero, o LAC enviará esses valores no ICCN.

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

Considere os seguintes exemplos:

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

  VSA 26-162 e VSA 26-163 são recebidos com valores diferentes de zero. O LAC envia esses valores VSA no ICCN.

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

  VSA 26-162 e VSA 26-163 são recebidos com valores zero. O LAC usa o ancp método para derivar os valores a serem enviados no ICCN.

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

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

Mecanismo de fallback para valores de velocidade de conexão

Quando o LAC seleciona um método para derivar as velocidades de conexão, ele retorna 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 diferente de zero, mas o outro não, apenas o valor não definido retorna a um método diferente. Não há fallback quando o método selecionado é none, porque esse método impede que o LAC relate 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 ANCP para a velocidade de recepção é zero. O LAC envia o valor ANCP para a velocidade de transmissão, mas o valor de recepção retorna ao método de tag PPPoE IA. O LAC envia o valor da tag IA para a velocidade de recebimento.

• O método selecionado é ANCP. O valor ANCP para a velocidade de recepção é zero. O LAC envia o valor ANCP para a velocidade de transmissão, mas o valor de recepção retorna ao método de tag PPPoE IA. O valor da tag IA para a velocidade de recebimento também é zero, portanto, ele retorna ao método estático de Camada 2. Isso está disponível, então 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 do ICCN ser enviado, portanto, o LAC retorna ao método ANCP. Os valores ANCP de transmissão e recepção estão disponíveis e diferentes de zero, portanto, o LAC envia esses valores no ICCN.

  O perfil de serviço é ativado por uma Alteração de Autorização (CoA) em algum momento posterior para a sessão. Se as atualizações estiverem habilitadas, o LAC enviará os valores do perfil de serviço para o LNS em uma mensagem CSUN. Se as atualizações não estiverem habilitadas, os valores do perfil de serviço não serão relatados ao 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 da CLI.

A partir do Junos OS Release 17.2R1, o procedimento de fallback do LAC é descrito na Tabela 3.

A partir do Junos OS Release 15.1R1, o procedimento de fallback do LAC é descrito na Tabela 4.

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