Resumo

  • A RFC 3317 fazia o equipamento DiffServ anunciar funções, direção, filas, limites de escalonamento, profundidade máxima e ligações permitidas antes de o servidor montar o caminho de tratamento.
  • O anúncio reduzia as combinações inviáveis, mas não provava o grafo completo: o PEP ainda precisava rejeitar uma política impossível, e a instalação não demonstrava o resultado nos pacotes.

Uma política de qualidade de serviço pode falhar sem que falte qualquer peça no inventário. O classificador existe, o medidor existe, as filas e o escalonador também. O defeito aparece na composição: aquela plataforma não consegue ligar um elemento ao outro, ou não comporta mais um estágio. A RFC 3317 tratou essa composição como capacidade que o dispositivo deveria revelar.

Publicada em 2003 com status Informational, ela definiu uma Policy Information Base para Differentiated Services. No modelo, um pacote podia ser classificado, medido, marcado, submetido a um algoritmo de descarte, colocado em fila e entregue a um escalonador. Essas funções viravam classes de provisionamento; instâncias concretas podiam ser enviadas por um Policy Decision Point a um Policy Enforcement Point, por exemplo com COPS-PR.

Os elementos formavam um caminho ordenado. A sequência básica era classifier, meter, action, algorithmic dropper, queue e scheduler. Quando a política precisava repetir um tipo anterior, outro Traffic Conditioning Block era encadeado. A referência Next de cada linha apontava para o passo seguinte. O conjunto de tabelas, portanto, descrevia um grafo dirigido capaz de ramificar conforme classificação ou resultado de medição.

A arquitetura separava encadeamento e parâmetros. Um medidor fazia referência a uma linha de token bucket com taxa e rajada; filas e escalonadores podiam apontar para parâmetros de taxa mínima ou máxima. A mesma parametrização podia ser compartilhada, e outros PIBs podiam acrescentar tipos novos. Mas a validação de cada referência não respondia à pergunta principal: o grafo inteiro cabia no equipamento?

Antes de receber a política, o PEP notificava o PDP sobre as PRCs entendidas, os tipos de interface, as combinações de papéis e os conjuntos de capacidades. A direção importava: uma função podia valer para entrada, saída ou ambas. O relatório podia descrever campos de classificação, tratamento de tráfego fora do perfil, algoritmos de descarte, número e memória de filas, método e quantidade de entradas do escalonador e níveis de taxa máxima.

Dois limites mostravam que o relatório era mais que catálogo. dsIfElmDepthCaps indicava quantos elementos funcionais podiam ser ligados consecutivamente. dsIfElmLinkCaps dizia quais tipos podiam seguir determinado tipo. Uma plataforma poderia suportar oito filas e ainda rejeitar um caminho que exigisse certo medidor antes delas. Outra poderia aceitar todos os tipos, mas não uma cadeia longa. O grafo possível dependia de nós, arestas e profundidade.

Com esse conhecimento, o PDP enviava política para um domínio administrativo, tipo de interface, papel e direção. Uma instância de data path escolhia o primeiro elemento. A ausência da instância ou um início zeroDotZero significava processamento IP normal. A descrição operava sobre tipos de interface, não sobre cada porta física, preservando reaproveitamento e deixando algumas diferenças locais para a etapa final.

O texto recusou a ideia de que a notificação fosse uma garantia. As classes de capacidade ofereciam orientações gerais; não enumeravam necessariamente toda configuração possível ou impossível. Recursos compartilhados e dependências internas podiam invalidar uma combinação que parecia adequada. Se o PEP recebesse uma política irrealizável, deveria enviar um relatório de falha ao PDP. O erro final completava o modelo em vez de contradizê-lo.

Daí surge uma cadeia de recibos. A capacidade é o que o dispositivo declara em termos gerais. O grafo é o que o controlador pretende. A resposta de COPS-PR relata a transação. A leitura de estado mostra linhas presentes. Só uma observação de pacotes diz se o tratamento ocorreu; e o tratamento observado ainda não demonstra que um cliente recebeu a qualidade prometida. Confundir essas etapas transforma automação em presunção.

O conteúdo também tinha valor comercial e operacional. Linhas instaláveis podiam representar contratos de serviço ou filtros de clientes; alterá-las mudava o comportamento DiffServ. Linhas de notificação revelavam características do equipamento. A RFC apontava para IPsec entre PDP e PEP, pois falsificar a capacidade induziria uma construção errada, enquanto falsificar a política redistribuiria recursos.

Em 2016, o IESG transferiu a RFC 3317, a Framework PIB, COPS-PR e SPPI para Historic. A justificativa registrou implantação limitada e o deslocamento da gestão de configuração para NETCONF e YANG. Esse encerramento impede tratar o documento como base atual ou prova de adoção ampla. Ao mesmo tempo, torna visível uma preocupação que reaparece em controladores modernos: intenção só se torna configuração depois de encontrar os limites do alvo.

O legado não é um formato de tabela. É a obrigação de deixar o dispositivo contestar o plano em duas etapas. Primeiro, ele fornece uma aproximação estruturada do que consegue ligar. Depois, conserva o direito e o dever de rejeitar a combinação completa. Sem a primeira etapa, o controlador desperdiça tentativas; sem a segunda, começa a tratar um modelo parcial como autoridade sobre o hardware.

Fontes: RFC 3317, RFC 3318, RFC 3290, RFC 3084, RFC 3159, RFC 2475 e a mudança de status do IESG em 2016.