Resumo

  • A RFC 9892 é uma especificação IETF Standards Track que define um DLEP Traffic Classification Data Item extensível e os Sub-Data Items iniciais de Diffserv e Ethernet.
  • O TID, Traffic Classification Identifier, é local ao modem e nomeia um conjunto de classificação. FIDs identificam fluxos dentro de um Sub-Data Item; não são nomes globais ou automaticamente estáveis entre dispositivos.
  • A associação com o destino é fornecida pela extensão que consome os dados, e o significado operacional do TID também é específico dessa extensão. Ao receber um TID, o roteador inicializa ou substitui a classificação associada e atualiza o estado do plano de dados conforme necessário.

Correspondência, substituição e validação

O Sub-Data Item Diffserv agrupa valores de DSCP. Valores duplicados do DS Field dentro de um mesmo Traffic Classification Data Item são erro. Uma contagem zero de DSCP funciona como curinga para DSCPs que não foram mapeados por outros itens. O Sub-Data Item Ethernet agrupa valores VLAN/PCP. VLANs explícitas têm a primeira correspondência, enquanto uma contagem zero de PCP oferece a correspondência padrão; prioridades duplicadas no mesmo Data Item também são erro. Se os dois classificadores corresponderem, VID/PCP Ethernet tem precedência sobre DSCP Diffserv, e o TID Ethernet deve ser usado.

Os formatos não produzem efeito sozinhos. Outra extensão DLEP negociada precisa exigir e interpretar esses dados. O controle de fluxo por janela de créditos da RFC 9893 é um exemplo, não uma obrigação da RFC 9892. A RFC 9892 não define escalonador, pesos de fila, política de admissão nem algoritmo de janela de créditos. Classificação futura por cinco tuplas é um exemplo de extensibilidade, não uma definição desta especificação.

Fixtures concretos de verificação

Um teste reproduzível deve conter quatro casos. Primeiro, uma única associação de DSCP, confirmando o FID esperado. Segundo, uma contagem zero e um DSCP não mapeado, confirmando o TID padrão. Terceiro, a repetição de DS Field ou PCP no mesmo Data Item, confirmando a rejeição como erro. Quarto, um pacote que corresponda simultaneamente a VID/PCP Ethernet e DSCP, confirmando que o TID registrado é o Ethernet. Depois, envie uma nova classificação para o mesmo TID e verifique que o estado antigo é substituído, não silenciosamente mesclado.

A trilha deve conservar direção da mensagem, resumo do Data Item, TID/FID, resultado da validação, extensão negociada e estado aplicado.

Caminho de decisão do operador

Confirme primeiro a sessão DLEP e a extensão consumidora negociada. Depois confirme a origem, o escopo local de TID/FID e a associação de destino. Em seguida, execute as verificações de duplicidade, curinga e precedência Ethernet. Se houver falha, isole a atualização e não a trate como política de fila. Se passar, registre o estado antes e depois da substituição e consulte a extensão consumidora para saber qual tratamento de fila ela aplicou. Por fim, confirme a segurança aplicável do transporte DLEP ou da camada de enlace. Essa proteção é limitada ao transporte ou enlace correspondente; ela não cria uma garantia de confiança ponta a ponta.

Um par malicioso que altere o mapeamento entre classificação e fila pode induzir atraso, congestionamento ou perda em classes de serviço. A RFC 9892 aponta para segurança de transporte DLEP e de camada de enlace, em conjunto com a RFC 8175, mas não cria um modelo de confiança novo. O conjunto de fontes também não prova que marcações DSCP sejam confiáveis ponta a ponta entre domínios administrativos.

Fontes