Resumo

  • A RFC 9894 é um documento IETF Standards Track que define a extensão DLEP Diffserv Aware Credit Window para controle de fluxo compartilhado e específico por destino.
  • A extensão combina a classificação de tráfego da RFC 9892 com o mecanismo de janelas de crédito da RFC 9893. Portanto, anunciar a extensão implica a dependência normativa relevante das duas RFCs, e não apenas a ativação de uma opção isolada.
  • O tipo de extensão é 6. Seu uso deve ser declarado no Extensions Supported Data Item; um participante não deve enviar os Data Items da extensão antes de verificar, na mensagem de inicialização recebida, que o par a suporta.

A RFC 9894 relaciona destinos DLEP e valores DSCP a janelas lógicas compartilhadas ou dedicadas. Uma janela compartilhada pode servir a mais de um destino ou classe; uma janela específica de destino restringe o crédito a um destino. A RFC não estabelece um mapa universal DSCP-para-janela. O escopo curinga merece cautela: ele pode incluir fluxos já existentes e fluxos que só aparecerão depois. Por isso, a recomendação é evitar curingas quando não forem necessários.

A precedência de classificação também é operacionalmente decisiva. Se a classificação Diffserv e a classificação de tráfego Ethernet coincidirem, a RFC 9892 dá precedência à classificação Ethernet. Logo, observar uma coincidência de DSCP não prova que a janela DSCP será a escolhida. Quando as janelas de crédito estão em uso, tráfego sem crédito disponível não pode ser enviado do roteador para o modem. Não há uma permissão implícita para enviar primeiro e ajustar a conta depois.

O caminho de admissão começa pela mensagem de inicialização: confirme que o Tipo de Extensão 6 foi declarado e que a outra ponta declarou suporte. Depois, compare a forma anunciada pelo modem com as filas e combinações de janelas que o roteador realmente consegue implementar. Se o roteador suportar menos combinações, deve usar um subconjunto suportado e identificável. Se não houver um subconjunto válido, pode reiniciar a sessão e relatar a incompatibilidade pelos mecanismos normais de gerenciamento. Cortar silenciosamente a capacidade anunciada deixa o plano de controle dizendo uma coisa e o plano de dados fazendo outra.

Uma mensagem DLEP injetada que redimensione uma janela pode reduzi-la ou torná-la indisponível e causar negação de serviço. Os mecanismos de segurança da RFC 8175 se aplicam à extensão. O gerenciamento deve conseguir informar a declaração do par, o subconjunto adotado, os mapeamentos rejeitados, o motivo do reinício, bloqueios por falta de crédito, resultados de classificação e falhas de segurança. A RFC não define uma CLI, um módulo YANG, um limite de telemetria ou um temporizador de rollback obrigatório.

Fixtures de verificação e caminho de decisão do operador

  1. Prepare mensagens de inicialização para suporte mútuo ao Tipo 6, suporte unilateral e ausência de suporte. Verifique que os Data Items da extensão não são emitidos sem o suporte declarado pelo par.
  2. Use um modem que anuncie quatro janelas DSCP e um roteador que implemente apenas duas. Confirme que as duas combinações suportadas são escolhidas e registradas, em vez de as quatro serem aceitas implicitamente.
  3. Teste uma janela compartilhada, uma janela específica de destino e um curinga; acrescente um fluxo novo e verifique se o curinga não o inclui sem revisão explícita.
  4. Faça um fluxo coincidir com Diffserv e Ethernet ao mesmo tempo. Confirme a precedência Ethernet e, depois de esgotar o crédito, confirme que o roteador não envia o fluxo ao modem.
  5. Teste mensagens protegidas e falsificadas de redimensionamento. Autenticação rejeitada, alteração anômala e reinício devem aparecer nos relatórios de gerenciamento.

Caminho de decisão do operador: valide primeiro o anúncio do par e o fechamento das dependências das RFCs 9892 e 9893. Em seguida, monte a tabela real de DSCP, destinos e janelas compartilhadas. Compare essa tabela com a capacidade implementável: habilite quando houver correspondência completa; se não houver, adote apenas um subconjunto documentado e observável; se nem isso for seguro e verificável, reinicie. Por fim, confirme no plano de dados a regra de não enviar sem crédito.

Fontes

As fontes não estabelecem prevalência de implantação, melhoria de desempenho medida ou um mapeamento universal entre DSCP e janelas. Elas também não definem uma quantidade obrigatória de filas, uma CLI proprietária, um módulo YANG, um limite de telemetria ou um temporizador de rollback. A confiabilidade das marcações DSCP entre domínios administrativos continua sendo uma preocupação do operador, não um resultado demonstrado pela RFC 9894.