Resumen
- RFC 3408 permitió sustituir R-0 por un paquete sin encabezado únicamente cuando la capa asistente podía aportar la identificación y la secuencia que ya no viajaban en el paquete.
- Cuando esa inferencia dejaba de ser segura,
SN_breakcerraba el camino de cero bytes hasta que una actualización posterior quedara reconocida más allá de la ruptura.
Los enlaces de radio que motivaron el diseño no cobraban cada octeto de forma lineal. Tenían tamaños físicos discretos. Un encabezado ROHC de un byte podía obligar a usar el siguiente tamaño completo para una muestra de voz. RFC 3243 presentó la respuesta con cautela: la técnica estaba pensada para aplicaciones ajustadas a esas propiedades, no como una receta de eficiencia para cualquier red.
En los modos U y O, RFC 3242 ya había mostrado el intercambio real. El paquete transmitido perdía el encabezado, pero la pila ganaba una capa asistente con nuevas responsabilidades. Alguien debía marcar si lo recibido era NHP o un paquete ROHC con encabezado; mantener el supuesto de entrega ordenada; e informar cada pérdida que afectara al cálculo. La información no se evaporaba: cambiaba de productor.
RFC 3408 llevó esa operación al modo fiable R. Su permiso era estrecho: solo R-0 podía convertirse en NHP. El receptor calculaba el número RTP sumando a la última referencia segura un desplazamiento. Sin embargo, el RFC no fijó un método universal para obtenerlo. Cada especificación de enlace debía describir su mecanismo verificable.
Contar paquetes no actualizadores y señales de pérdida era una opción. Conservar una correspondencia entre el reloj del enlace y el número RTP era otra. Ambas revelaban lo mismo: el encabezado podía omitirse solo si el entorno aportaba una fuente alternativa de orden. Un flujo sin esa fuente no era “casi compatible”; carecía de la prueba que hacía interpretable cada carga útil.
La capa asistente también tenía autoridad para decir que la situación ya no era segura, incluso cuando el compresor aún autorizaba NHP. En ese punto anotaba SN_break y volvía a enviar paquetes con encabezado. Para reabrir el camino debía recuperar sus condiciones normales y observar que SN_ACKed hubiera avanzado por encima de la ruptura. El ACK era una barrera de referencia, no una constancia de que el usuario había oído la voz.
Esperar una actualización espontánea podía resultar lento. Por eso el documento recomendó una interfaz opcional de update_request. La capa asistente podía pedir al compresor un paquete que renovara contexto. Si el mensaje se perdía porque ambos componentes estaban separados y su canal era imperfecto, el efecto previsto era esperar más. Repetir la petición era una decisión de implementación; adivinar una referencia no lo era.
R-mode simplificaba un aspecto importante. R-0 no contenía CRC, de modo que NHP no necesitaba reemplazar esa función como ocurría en U/O-mode. Los NHP y las indicaciones de pérdida tampoco actualizaban el contexto. R-0-CRC, enviado con el retorno del número de secuencia de seis bits, ofrecía la comprobación periódica. La referencia segura sobrevivía a la optimización.
Un ACK colocado como retroalimentación intercalada podía romper temporalmente la continuidad RTP y deshabilitar NHP. Y un atacante capaz de inyectar falsos paquetes CCP con CRC aleatorios podía provocar invalidaciones, más mensajes de retorno y más refrescos. La disponibilidad del ahorro dependía, por tanto, de decisiones en caminos que no parecían transportar voz.
Los marcos posteriores de ROHC y los perfiles ROHCv2 ampliaron el contexto histórico. El registro de IANA conserva los identificadores. Nada de ello demuestra una implantación concreta ni un resultado de calidad. RFC 3408 importa porque hizo auditable el precio de un paquete “sin encabezado”: cada bit omitido exigía una obligación identificable en otra capa.
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/
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
