Summary
- A RFC 9599 orienta a passagem de uma indicação explícita de congestionamento da moldura ou do cabeçalho externo para IP quando termina uma sub-rede ou um túnel.
- Observar
CEna saída comprova o estado daquele cabeçalho naquele ponto. Não identifica por si só a fila que marcou, nem prova feedback do receptor ou redução de carga pelo emissor.
Um pacote sai do túnel marcado como CE. O dado é real. A conclusão “o túnel congestionou” ainda precisa de uma cadeia que o pacote não carrega.
A marca pode ter chegado na camada interna antes do encapsulamento. Pode ter sido aplicada por uma fila de camada 2. O decapsulador pode ter combinado estados e mantido o mais severo. O reenquadramento pode ter associado o evento a um pacote IP posterior. E uma mudança de DSCP pode ter deixado os bits intactos enquanto retirava o contexto que lhes dava significado.
Publicada em agosto de 2024 como parte da BCP 89, a RFC 9599 resolve o problema de continuidade do sinal. Quando uma moldura é descartada, o pacote interno some junto. Quando a moldura apenas recebe uma marca, essa informação desaparece se o cabeçalho for retirado sem uma transferência explícita para IP.
Por isso, o decapsulador faz parte do circuito de controle. Não basta que as pontas de transporte entendam ECN. Toda função necessária para devolver o aviso ao regulador de carga deve preservá-lo. A definição de ECN-PDU pertence ao circuito completo; a capacidade pode vir de bits, rótulos, estado de fluxo, configuração ou contexto de controle.
A norma separa quatro modos. Feed-forward-and-up leva o aviso à saída da camada inferior, sobe-o para IP e permite o retorno pelo transporte. Feed-up-and-forward deixa o equipamento inferior marcar diretamente o cabeçalho IP. Feed-backward envia controle à entrada da sub-rede. Null pressupõe que o tecido inferior não tenha um ponto interno de congestionamento.
Feed-backward pode regular uma ilha, mas não fala diretamente com a origem IP. A entrada desacelera enquanto a fonte continua enviando; a fila migra para a borda. O controle recebido pela entrada não é recibo de que a aplicação de origem reagiu.
Feed-up-and-forward depende da visibilidade. Criptografia, shims desconhecidos e encapsulamento profundo podem ocultar IP. A RFC manda limitar a busca e recorrer a descarte ou outro sinal seguro quando o cabeçalho não for encontrado. Ausência de marca pode significar ausência de inspeção, não ausência de congestionamento.
No feed-forward-and-up, a entrada precisa saber que a saída não apagará o sinal. Em MPLS, isso pode ser uma obrigação de configuração de todo o domínio. Em TRILL, a indicação crítica cria falha segura: uma saída antiga descarta a moldura em vez de remover a marca silenciosamente.
O decapsulador também não copia o exterior de forma cega. Ele calcula o resultado com os dois estados. Se a camada interna for Not-ECT e a externa trouxer a indicação mais severa, o pacote deve ser descartado, pois o transporte não prometeu ler CE. Se ambas expressarem severidade válida, a mais forte prevalece. Combinações impossíveis pedem log e política, não necessariamente um descarte permanente que impeça uso futuro.
Na entrada, zerar o histórico exterior destruiria a linha de base. Preservar o nível recebido permite estimar, em agregado, o congestionamento acrescentado no trecho pela diferença entre marcações externas e internas.
Essa estimativa não autentica um pacote individual. Exige populações alinhadas e regras conhecidas. No reenquadramento, preservar o momento das marcas e preservar sua proporção são objetivos distintos. Um pipeline pode transferir o aviso para um pacote ligeiramente posterior.
Os dois bits também dependem de contexto. ECN tradicional, PCN e L4S podem atribuir sentidos diferentes a ECT(0), ECT(1) e CE; algumas leituras dependem de DSCP. Copiar bits depois de alterar esse contexto não preserva necessariamente o significado.
Há ainda a integridade. Um campo modificado legitimamente no caminho precisa ser declarado mutável; caso contrário, a marca quebra a autenticação de um cabeçalho tratado como imutável. E o feedback recebido não prova a resposta do emissor. Recebimento e ação são fatos separados.
Uma aceitação defensável registra ECN e DSCP internos na entrada, regra de encapsulamento, identidade do túnel, capacidade da saída, configuração AQM, estados interno e externo na decapsulação, encaminhamento ou descarte, feedback do receptor, recebimento no emissor e mudança observada em taxa ou fila.
A RFC 9599 torna a indicação portátil. Portabilidade não é procedência. A marca é evidência; origem, custódia, semântica e efeito continuam sujeitos a prova.
Sources
- RFC 9599
- Registro no Datatracker
- Erratas da RFC 9599
- RFC 3168: ECN em IP
- RFC 6040: ECN em túneis
- RFC 5129: marcação em MPLS
- RFC 7141: notificação por bytes e pacotes
- RFC 7713: conceitos ConEx
- RFC 8087: benefícios do ECN
- RFC 3819: orientação para sub-redes
- RFC 8311: experimentação ECN
- RFC 7567: recomendações AQM
- RFC 4774: semânticas ECN alternativas
- RFC 9331: arquitetura L4S
- RFC 9600: ECN em TRILL
- RFC 9601: ECN em túneis IP com shim
- Heng Lu: camadas da realidade
- Heng Lu: primazia do código em execução
- Heng Lu: realidade, não defesa
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

