Resumo

  • RFC 3387 colocou uma fronteira entre o mecanismo que diferencia pacotes e o serviço que precisa ser definido, autorizado, provisionado, medido e cobrado.
  • Sua arquitetura de responsabilidades atravessava borda, núcleo e relações entre domínios, sem transformar uma marca, uma política ou um registro contábil em prova do resultado final.

Considere uma fatura contestada. O provedor mostra contadores da classe preferencial. O roteador mostra que o agendador transmitiu aqueles pacotes antes de outros. O cliente mostra uma aplicação que perdeu seu prazo. Todos podem estar exibindo fatos corretos, porque cada fato pertence a uma etapa diferente.

RFC 3387 nasceu dessa separação. Publicado em setembro de 2002 como Informational, por integrantes do Service Management Research Group da IRTF, o texto não criou protocolo nem certificou implantação. Examinou o que faltava ao redor de IntServ, DiffServ, política e engenharia de tráfego para que diferenciação técnica se tornasse serviço administrável.

O melhor esforço havia combinado simplicidade com controle distribuído. Quando a rede passou a considerar níveis variáveis de tratamento, surgiu uma pergunta econômica e operacional: quem decide que determinado fluxo merece recursos escassos, e que prova deve sobreviver quando o caminho cruza empresas independentes?

O RFC dividiu o serviço em definição e materialização. A definição precisava declarar parâmetros e limites de forma inequívoca. A materialização precisava mapear isso para capacidades reais. Um modelo de informação ou uma regra de política podia expressar intenção, mas não demonstrava que os equipamentos aceitaram a mudança, que o caminho inteiro tinha recursos ou que a aplicação recebeu o efeito desejado.

Na borda de acesso apareciam autenticação, autorização e controle de admissão. A autenticação identificava uma parte; a autorização permitia uma ação sob regras; a admissão decidia se havia recursos para honrá-la. A mesma borda precisava verificar parâmetros de tráfego, informar cobrança, sinalizar falha, reinstanciar e terminar o serviço. Juntar esses recibos ocultaria estados importantes, como pedido autorizado mas não admitido.

No núcleo, a responsabilidade era relatar recursos, configurar dispositivos, fazer engenharia de tráfego, detectar falhas e recuperar. RFC 3387 discutiu cálculo mais centralizado porque certas decisões dependiam de uma visão mais ampla do que um salto. Ao mesmo tempo, perguntou se o benefício justificava complexidade e risco de desestabilização. Uma necessidade de informação global não conferia automaticamente soberania a um controlador.

Entre domínios, provedores concorrentes teriam de trocar sinalização de serviço, contabilidade, verificação, medição de fronteira e dados de faturamento. Eles também tinham motivo para esconder capacidade e fragilidade internas. Um SLA bilateral limitava uma relação; muitos SLAs bilaterais não formavam, por simples concatenação, uma garantia quantitativa única.

O bandwidth broker e terceiros confiáveis apareciam como possibilidades para coordenar admissão, preço, pagamento e validação. Não eram obrigação do RFC. O desenho precisava impedir que quem transportasse ou agregasse evidência se tornasse a fonte exclusiva da validade entre redes pares.

Cobrança e segurança deveriam nascer com o serviço. RFC 2975 separa contabilidade, tarifação e faturamento: a primeira registra consumo; a segunda aplica preço; a terceira apresenta a cobrança. Liquidação é outro evento. Um volume medido pode estar certo e a tarifa errada; uma cobrança pode estar certa e não paga; pagamento não prova que o tráfego recebeu o resultado prometido.

O limite do DiffServ era semelhante. Um PHB descreve tratamento por salto, sob condições locais. RFC 3387 afirmou que uma garantia de classe por salto não é garantia de ponta a ponta. Quem paga por QoS espera limites de banda, atraso ou erro ao longo do caminho, e nenhum roteador pode testemunhar sozinho pelos demais.

Havia ainda um custo imposto a quem não comprou a classe. Capacidade reservada pode ficar ociosa e indisponível ao melhor esforço. Prioridade pode reduzir o que sobra. O RFC não apresentou medição de dano; registrou a pressão econômica para favorecer o serviço de maior receita e pediu que a arquitetura não escondesse esse efeito.

A primazia do código em execução de Lu Heng limita a camada comum ao necessário para interoperabilidade e verificação. Domínios podem trocar identidade, autorização, parâmetros, medições e recibos de fronteira sem ceder suas decisões internas de capacidade e preço. A especificação inicial mínima coordena o que precisa ser comum e deixa adoção futura e escolhas locais onde pertencem.

RFC 3387 ficou incompleto de propósito: era um levantamento do trabalho que a fila não podia fazer. Sua contribuição foi impedir uma promoção indevida de evidência. Marcação não era autorização; política não era capacidade; tratamento não era serviço; contabilidade não era pagamento; e nenhum sucesso local era, sozinho, a experiência do cliente.

Fontes