Resumen

  • El modo normal de PPP seguía enviando datagramas UI sin promesa de recuperación. RFC 1663 hizo de Numbered Mode una opción voluntaria de LCP para un solo enlace, con una ventana limitada, acuses, temporizadores y una salida común cuando los estados dejaban de coincidir.
  • Cada receptor podía declarar una ventana distinta, pero ambos extremos debían compartir módulo 8 o módulo 128. El Magic-Number decidía quién iniciaba SABM o SABME; no identificaba ni autorizaba al equipo.
  • UA confirmaba el establecimiento del procedimiento numerado entre vecinos. La autenticación, la calidad del enlace, los NCP, el enrutamiento y el resultado de la aplicación seguían fuera de ese acuse.

La fiabilidad apareció donde había estado compartido

PPP sobre tramas similares a HDLC empleaba normalmente la dirección All-Stations y el control Unnumbered Information. Cada paquete era un datagrama. Si una trama llegaba dañada, podía desecharse sin que el propio enlace tuviera que recuperar su posición en una secuencia.

Ese diseño era suficiente mientras los datagramas fueran independientes. RFC 1663 destacó la compresión como excepción. Cuando emisor y receptor mantienen el mismo diccionario, perder un datagrama comprimido puede dejar al receptor fuera de sincronía. Los datagramas posteriores ya no se entienden aunque sus bits lleguen intactos. Algunos métodos pueden reiniciar el diccionario con poco coste; otros se benefician de un flujo ordenado y fiable en el enlace inmediato.

El IETF no convirtió esta necesidad particular en una obligación universal. En julio de 1994, el grupo PPP publicó RFC 1663 con la opción 11 de LCP, Numbered-Mode. Un extremo tenía que solicitarla durante el establecimiento y el otro aceptarla. Sin ese acuerdo, se conservaba el modo UI.

La decisión preservaba dos libertades. Los implementadores que no necesitaban recuperación no pagaban su complejidad. Quienes compartían un estado frágil podían activar un mecanismo interoperable sin imponer su conveniencia a todos los demás enlaces.

Address y Control dejaron de ser constantes

Numbered Mode no sustituyó el formato entero de PPP. Protocol, Information, Padding, FCS y banderas conservaron sus funciones. La diferencia residía en Address y Control, que pasaban a expresar el procedimiento numerado LAPB de ISO 7776. Una vez establecido el modo, todas las tramas del enlace debían usarlo; no era válido alternar de forma oportunista con UI.

Por eso Address-and-Control-Field Compression quedaba prohibida. En PPP ordinario, el par ff 03 podía omitirse porque era previsible. En el modo numerado, esos campos transportaban dirección y control de secuencia. RFC 1662 contenía la regla general: cualquier valor diferente de Address o Control debía haberse definido o acordado y no podía desaparecer como si fuera el valor habitual.

El FCS cubría los campos modificados. Un FCS correcto confirmaba la integridad de esa representación local; no confirmaba que los dos extremos siguieran en la misma época de negociación. Un marco íntegro puede pertenecer a un estado que el receptor ya abandonó.

La ventana elegía también el idioma de la secuencia

Window aceptaba valores del 1 al 127. Indicaba cuántas tramas podía guardar el receptor y cuántas podía mantener el emisor sin acuse. Era tanto una declaración de capacidad como un límite a la cantidad de trabajo pendiente.

Una ventana menor que 8 implicaba módulo 8; una de 8 o más, módulo 128. Los extremos podían anunciar ventanas distintas, pues no tenían por qué disponer de la misma memoria. No podían usar módulos distintos. Interpretar en un círculo de tres bits lo que el otro enumera en siete no es una diferencia de rendimiento, sino una sintaxis incompatible.

Configure-Nak podía proponer una ventana menor, nunca aumentarla. Así el receptor más limitado podía reducir la obligación sin prometer recursos ajenos, y una respuesta no empujaba al solicitante hacia un formato de secuencia más ancho que el que había ofrecido.

La opción también incluía una dirección HDLC. El cero debía rechazarse con una alternativa adecuada. Las reglas comparaban primero ventanas y direcciones; sólo un empate residual recurría a una elección aleatoria. Era coordinación suficiente para establecer el enlace, no una prueba de quién operaba cada dispositivo.

El Magic-Number elegía al iniciador

Numbered Mode exigía negociar Magic-Number. Después del acuerdo LCP, el extremo con el número menor enviaba SABM para módulo 8 o SABME para módulo 128; el otro respondía UA. Los vecinos obtenían un orden de inicio a partir de datos que ya compartían.

Si se perdía el mensaje inicial o UA, se aplicaban el Restart Timer y los contadores de LCP. Pero UA no era un certificado de éxito general. Confirmaba que el vecino aceptaba el procedimiento numerado. La arquitectura PPP situaba después la autenticación, la determinación de calidad y la configuración de los protocolos de red. UA no demostraba credenciales válidas, calidad aceptable, IP configurado, ruta disponible ni ejecución de una petición remota.

Magic-Number tampoco era una credencial. Podía ayudar a distinguir los extremos y detectar un bucle de enlace, pero no firmaba ni autorizaba nada. RFC 1663 no trató cuestiones de seguridad. Confiar en el origen y recuperar la entrega eran problemas diferentes.

El desacuerdo tenía una ruta de vuelta

Una retransmisión fiable necesita un final común cuando los estados divergen. RFC 1663 evitó que un extremo siguiera numerando mientras el otro interpretaba UI.

La renegociación se efectuaba todavía en Numbered Mode. Si la opción no volvía a acordarse, el enlace regresaba a UI antes de autenticación, calidad y NCP. Una implementación capaz pero actualmente no numerada que recibiera una trama no-UI con FCS correcto respondía DM y reiniciaba LCP. Un extremo numerado que recibiera DM también volvía a UI y enviaba un nuevo Configure-Request.

Así, la corrección de los bits no reactivaba por sí sola un estado antiguo. DM y el reinicio de LCP hacían visible la discrepancia.

La espera y el reintento estaban acotados. T1 fijaba el máximo antes de retransmitir una trama de información sin respuesta. Debía adaptarse al tiempo de ida y vuelta LAPB observado; la fórmula alternativa usaba tamaño de trama, velocidad y tiempo de proceso. T3 representaba inactividad y tenía que ser mayor que T1. N2 limitaba los intentos por trama. Superarlo debía terminar el enlace; el valor predeterminado recomendado era 3.

Tres no era una verdad de todas las redes. Era el límite sugerido para este procedimiento entre vecinos. Agotar N2 no explicaba la causa del silencio y no decidía cuántas veces debía repetir una aplicación su propia operación.

Dos enlaces no se unían por compartir extremos

PPP establecía, configuraba y terminaba por separado los enlaces paralelos. Un contexto de compresión dependiente de secuencia también permanecía separado, salvo que otro procedimiento reuniera los enlaces.

RFC 1663 mencionó el mecanismo ISO Multi-Link, desaconsejó implementarlo y recomendó el trabajo PPP Multilink que terminó en RFC 1990. Numbered Mode daba orden y recuperación dentro de un enlace miembro. Multilink creaba una secuencia común para reensamblar fragmentos enviados por varios miembros. Eran contratos próximos, no intercambiables.

Por eso cada acuse numerado pertenece a un enlace, unas direcciones, un módulo y una negociación determinados. No puede atribuirse a otro enlace paralelo ni proyectarse más allá de un router.

El acuse era preciso porque no sabía demasiado

IANA registra Numbered-Mode como opción LCP 11. Esa asignación prueba un vocabulario común. Configure-Ack prueba que se aceptaron valores concretos durante una negociación. SABM o SABME con UA prueba que se estableció el procedimiento numerado. Las secuencias, acuses y retransmisiones sustentan afirmaciones sobre la entrega en ese enlace. DM, un reinicio LCP o el agotamiento de N2 señalan la pérdida de ese estado.

Ningún peldaño reemplaza al siguiente. La identidad necesita autenticación; la calidad necesita mediciones y una política local; la configuración de red necesita NCP; la alcanzabilidad necesita datos de rutas; la conclusión de una operación necesita identificadores y respuestas de la propia aplicación.

La aportación histórica de RFC 1663 fue un contrato pequeño y comprobable. Dos vecinos que voluntariamente querían fiabilidad compartían una gramática de secuencia, limitaban lo no confirmado, reconocían el progreso y sabían cómo reiniciar cuando dejaban de estar de acuerdo. El acuse terminaba en el enlace y, gracias a ese límite, decía exactamente lo que podía demostrar.

Fuentes