Resumo

  • O TOS do IPv4 nasceu como preferência consultiva. O DiffServ reutilizou seis bits para selecionar um comportamento por salto e colocou classificação, medição, policiamento, modelagem e remarcação nas fronteiras.
  • AF e EF não são garantias de ponta a ponta. O serviço só aparece quando recursos locais, perfis de tráfego e acordos se alinham; o domínio receptor pode aceitar, traduzir, zerar ou rejeitar uma marca externa.

Uma etiqueta chega sozinha à alfândega

Um pacote de voz sai da rede de uma empresa marcado para Expedited Forwarding. Ali dentro, a marca pode corresponder a uma fila curta, com taxa de atendimento configurada e um cadastro que liga o fluxo a um cliente. Ao entrar na operadora, os seis bits continuam intactos. O cadastro, o pagamento e a reserva de capacidade não viajaram com eles.

O roteador de ingresso precisa classificar e medir novamente. Pode reconhecer o acordo, conservar o DSCP e policiar o excesso. Pode também remarcar para o comportamento padrão ou descartar o que viola o perfil. O fato de a primeira rede ter concedido prioridade não cria obrigação para a segunda.

Essa não é uma lacuna do DiffServ. É o limite que impede um remetente de gastar recursos alheios escrevendo um número no cabeçalho.

O primeiro Type of Service era uma orientação

RFC 791, de setembro de 1981, reservou um octeto do IPv4 ao Type of Service. Três bits indicavam precedência; outros expressavam preferência por atraso baixo, vazão alta ou confiabilidade. A aplicação podia declarar o que valorizava e deixar cada rede mapear a ideia para a tecnologia disponível.

O próprio RFC deixou o controle da precedência Network Control a cargo de cada rede. Se uma designação privilegiada importava, cabia ao operador limitar seu uso. Preencher o campo nunca bastou para comprovar autorização.

Em 1992, RFC 1349 tornou explícito que TOS era estritamente consultivo e inadequado para solicitar garantias. Algumas redes não teriam rota melhor a oferecer. E a aplicação não conseguia dizer no campo quantos megabits por segundo realmente precisava. A preferência descrevia intenção, não criava banda.

O núcleo ficou simples porque a borda ficou responsável

Guardar estado de cada fluxo ou cliente em todos os roteadores centrais seria caro demais. RFC 2474 e RFC 2475, publicados em dezembro de 1998, propuseram tratar agregados.

Os seis bits superiores do antigo TOS e do Traffic Class do IPv6 passaram a formar o campo de Serviços Diferenciados. Seu valor, o DSCP, seleciona um Per-Hop Behavior em cada nó. Os dois bits restantes foram usados depois por ECN; não completam uma ordem DiffServ de oito bits.

Código e comportamento não são a mesma coisa. Vários DSCPs podem escolher o mesmo PHB, e alguns valores têm significado apenas local. Um PHB descreve como um nó atende um agregado de forma observável — agendamento, uso de buffers e descarte. É peça para montar um serviço, não o serviço inteiro.

Na borda ficam as decisões complexas: classificar por vários campos, medir contra um perfil, marcar, remarcar, suavizar rajadas e descartar excesso. No interior, poucos comportamentos tratam agregados já condicionados, sem carregar a ficha de cada cliente.

O domínio define onde uma política vale

Um DS domain reúne nós contíguos sob a mesma política de provisionamento e um conjunto coerente de PHBs. A palavra domínio delimita uma administração. Dentro dela, os códigos aceitos devem receber tratamento consistente. Na entrada, a rede decide que afirmações externas passam a ter validade local.

Por isso seis bits são suficientes: identidade, franquia de tráfego, cobrança, capacidade e sanções continuam fora do pacote. Classificadores, configuração e acordos fornecem o contexto que a marca não contém.

Um enlace físico entre duas empresas não funde suas filas nem seus compromissos.

AF padronizou relações, não quantidades de recurso

RFC 2597 definiu Assured Forwarding em 1999 com quatro classes e três precedências de descarte por classe. Sob congestionamento, maior precedência de descarte significa maior chance de perda dentro da mesma classe, sem reordenar pacotes do mesmo microfluxo por causa disso.

Os nomes AF parecem níveis universais, mas o documento não determina quanto buffer ou banda cada classe recebe. A garantia efetiva depende do recurso alocado, da carga atual e da precedência de descarte. Um nó compatível com DiffServ nem sequer precisa implementar AF.

No ingresso, a operadora pode modelar o fluxo, mudar a precedência, movê-lo de classe ou descartá-lo. O código ajuda a coordenar; a configuração decide o valor econômico do tratamento.

EF promete sobre um nó, não sobre o caminho

O nome Expedited Forwarding sugere uma via rápida. RFC 3246, de 2002, exige que um nó que implemente EF ofereça atendimento igual ou superior a uma taxa configurada e permite quantificar o comportamento em condições limitadas.

Mas o escopo termina no nó. Uma coleção de roteadores fica fora do documento, e EF não é obrigatório para conformidade com DiffServ. Atraso baixo ao longo do percurso requer recurso e controle de chegada em cada ponto. Uma fila bem dimensionada não dá ordens à próxima.

Ao limitar a promessa, o padrão tornou o comportamento testável. Não vendeu como certeza global aquilo que só podia medir localmente.

A relação comercial não cabe no DSCP

RFC 2475 falava em SLA e Traffic Conditioning Agreement. RFC 3260 observou que acordos também incluem preço, disponibilidade e obrigações de negócio que não pertencem ao protocolo. Para os parâmetros técnicos, adotou os termos SLS e TCS.

A distinção preserva papéis. O IETF pode definir campo, valores e requisitos de um PHB. Não pode decidir que cliente comprou o quê nem que capacidade duas operadoras devem instalar.

Uma fronteira pode alterar ou descartar DSCP inaceitável. Tráfego vindo de domínio sem acordo de serviço melhorado pode voltar a Default. Depois do condicionamento, um código sem mapeamento conhecido deve normalmente receber o comportamento padrão, não um privilégio inventado.

Um campo gravável não autentica ninguém

Qualquer endpoint pode tentar marcar o próprio pacote. Um invasor também pode alterar cabeçalho externo sem proteção. Os RFCs chamam atenção para o furto de serviço: quando tráfego não autorizado esgota a capacidade reservada, a fraude vira negação de serviço.

A defesa primária é o condicionamento de fronteira. O ingresso valida código, fluxo e política; os nós internos confiam no agregado saneado. Uma saída de túnel que expõe o cabeçalho interno a novo domínio assume responsabilidade de ingresso. Integridade criptográfica prova que a marca não mudou, mas não prova que a nova rede concordou em atendê-la.

O Wi-Fi trouxe outra língua de prioridade

RFC 7657 registrou em 2015 que um terminal não pode saber que PHB um Class Selector aciona numa rede específica, muito menos de ponta a ponta. CS1 pode significar Lower Effort, Default, outro tratamento, remarcação ou descarte.

Em 2018, RFC 8325 mostrou o encontro entre DSCP e User Priority do IEEE 802.11. São espaços de códigos diferentes; o ponto de acesso precisa traduzi-los e pode recorrer ao padrão quando não houver serviço correspondente. Manter o mesmo número não preserva automaticamente o mesmo compromisso.

A coordenação mínima não tomou posse da decisão local

O DiffServ escalou porque não tentou carregar identidade, contrato e capacidade em cada pacote. O padrão ofereceu vocabulário e comportamentos verificáveis. Operadores alocaram filas e controlaram admissão. Clientes e redes vizinhas estabeleceram perfis e acordos. A fronteira ligou essas camadas.

Os seis bits podiam pedir. Só o sistema em execução podia responder. A rede seguinte continuou livre porque a etiqueta jamais virou título de propriedade sobre a capacidade dos outros.

Fontes e limites

RFC 791 e RFC 1349 documentam TOS; RFC 2474 e RFC 2475 definem campo e arquitetura; RFC 2597 e RFC 3246 tratam de AF e EF; RFC 3260, RFC 7657 e RFC 8325 registram limites posteriores. Esses textos não revelam configuração atual, direito contratual, adoção ou desempenho medido de nenhuma operadora.