Resumo
- A RFC 3408 autorizou que somente o pacote R-0 do modo confiável fosse trocado por NHP, desde que a camada auxiliar fornecesse a identificação e a posição que o cabeçalho não carregaria.
- Quando essa camada perdia a garantia de reconstrução,
SN_breaksuspendia a economia até uma atualização reconhecida avançar além da quebra.
O motivo econômico era um degrau, não uma linha. Em certas interfaces de rádio antigas, acrescentar o menor cabeçalho ROHC, de um octeto, podia empurrar uma amostra de voz para o próximo tamanho físico fixo. A RFC 3243 deixou claro que o objetivo era atender aplicações compatíveis com essa característica, e não proclamar uma vantagem geral para qualquer tráfego.
A RFC 3242 havia descrito a solução sem cabeçalho para os modos U e O. Ela também registrou a dívida criada pela remoção. A camada auxiliar precisava dizer ao descompressor se o pacote era NHP, preservar a ordem exigida e emitir uma indicação para cada perda relevante no enlace. O campo saía do pacote; sua função aparecia em interfaces e sinais novos.
A RFC 3408 estendeu esse arranjo ao modo R. O mapeamento foi restrito: R-0 era o único formato substituível por NHP. Para reconstruir o número RTP, o receptor combinava a última referência segura com um deslocamento. Como o deslocamento dependia da tecnologia, a especificação concreta do enlace tinha de explicar sua origem.
Uma implementação poderia contar pacotes que não atualizam contexto e indicações de perda desde a última atualização aceita. Outra poderia manter uma relação linear entre o tempo do enlace e a sequência RTP. O ponto não era escolher uma fórmula elegante, mas identificar uma prova operacional que continuasse existindo quando os bits do cabeçalho deixassem de existir.
A camada auxiliar podia concluir que NHP havia ficado inseguro mesmo se o compressor ainda o permitisse. Nesse caso, guardava o número como SN_break e parava de emitir pacotes sem cabeçalho. A retomada exigia recuperar a condição de segurança e observar SN_ACKed maior que a quebra. Um ACK anterior não era uma licença permanente; ele delimitava a referência que realmente havia sido confirmada.
Esperar passivamente por uma futura atualização de contexto podia levar muito tempo. Por isso, a RFC recomendou uma interface opcional de update_request. A camada auxiliar solicitava ao compressor que o próximo pacote atualizasse o contexto. Se o pedido se perdesse entre componentes separados, a consequência era prolongar a fase menos eficiente. A frequência de repetição ficava para a implementação, mas a condição de retomada permanecia intacta.
O modo R também evitava misturar estados. NHP e indicações de perda não atualizavam os contextos. R-0 não possuía CRC, portanto não havia uma função de CRC removida a substituir, como nos modos U/O. O envio de R-0-CRC na volta do número de seis bits já criava uma verificação periódica. A referência segura continuava sendo propriedade de uma atualização reconhecida.
Até a posição do feedback podia alterar o resultado. Pacotes de feedback intercalados quebravam a sequência RTP e desabilitavam NHP temporariamente, razão pela qual seu uso para ACK era desaconselhado. Um invasor capaz de injetar CCPs falsos com CRCs aleatórios também podia causar invalidações, feedback e refrescos desnecessários. O ataque reduzia a eficiência sem precisar produzir mídia válida.
Os frameworks ROHC posteriores, o ROHCv2 e o tratamento de enlaces com reordenação ampliaram a família técnica. O registro da IANA conserva os identificadores, mas não oferece um relatório de operação. O valor histórico da RFC 3408 está em tornar explícito que “zero byte” era uma propriedade do formato transmitido, não ausência de custo, estado ou responsabilidade.
Sources
- https://www.rfc-editor.org/rfc/rfc3408.html
- https://www.rfc-editor.org/rfc/rfc3408.txt
- https://www.rfc-editor.org/info/rfc3408/
- https://datatracker.ietf.org/doc/rfc3408/
- https://datatracker.ietf.org/doc/rfc3408/history/
- https://datatracker.ietf.org/doc/rfc3408/references/
- https://www.rfc-editor.org/errata_search.php?rfc=3408
- https://www.rfc-editor.org/rfc/rfc3242.html
- https://www.rfc-editor.org/rfc/rfc3243.html
- https://www.rfc-editor.org/rfc/rfc3095.html
- https://www.rfc-editor.org/rfc/rfc4995.html
- https://www.rfc-editor.org/rfc/rfc5795.html
- https://www.rfc-editor.org/rfc/rfc5225.html
- https://www.rfc-editor.org/rfc/rfc4224.html
- https://www.rfc-editor.org/rfc/rfc3759.html
- https://www.rfc-editor.org/rfc/rfc2508.html
- https://www.rfc-editor.org/rfc/rfc1144.html
- https://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
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
