Resumen

  • SLIP reservaba END para terminar la trama y ESC para representar, dentro de los datos, los dos valores que podían confundirse con la gramática del enlace.
  • RFC 1055 sugiere un END al inicio para expulsar del receptor los bytes que el ruido pudo dejar allí; el precio normal es una trama vacía que se descarta.
  • La frontera recuperada no acredita la integridad del datagrama ni el estado compartido de un compresor. Esas obligaciones tienen pruebas y capas distintas.

El valor de decir «solo hago esto»

La primera virtud de RFC 1055 es no esconder el tamaño de SLIP. En 1988 lo presenta como una convención de facto, no como estándar de Internet, para TCP/IP punto a punto sobre líneas serie. Dice que procede de la implementación UNET de 3COM y que define una secuencia de caracteres para encuadrar paquetes IP. Nada más.

Ese límite importa. El RFC no atribuye a SLIP direccionamiento, identificación de tipos de paquete, detección o corrección de errores ni compresión. Los dos extremos deben resolver por fuera qué direcciones IP usarán. La línea no puede transportar TCP/IP y otro protocolo distinguiéndolos con un campo SLIP. Y un paquete dañado no adquiere una garantía de integridad porque haya aparecido un final de trama.

No conviene transformar esos huecos en una acusación retrospectiva. En un enlace de pocos kilobits, un mecanismo con dos caracteres especiales podía ser exactamente la mínima superficie común que dos implementaciones necesitaban. La pregunta histórica no es por qué SLIP no gobernaba la conexión entera; es qué podía decidir de forma verificable en el momento en que un flujo de bytes debía convertirse otra vez en un datagrama.

La respuesta usa dos valores concretos. END es octal 0300, decimal 192. ESC es octal 0333, decimal 219. Si el dato contiene END, el emisor transmite ESC más octal 0334; si contiene ESC, transmite ESC más octal 0335. Tras el último byte de datos transmite END. El receptor deshace los dos casos de byte stuffing y entiende END como el cierre.

La autoridad de esos caracteres es estrecha. END no es una orden universal escondida en cualquier archivo: es una señal estructural para un receptor SLIP que está leyendo una trama. ESC no es una inspección general de caracteres, sino la introducción de dos sustituciones pactadas. Los datos conservan los valores reservados precisamente porque el emisor deja una huella local que el receptor sabe invertir. El formato evita una colisión; no certifica el contenido que ha conseguido transportar.

Un final antes del comienzo

Phil Karn propuso la pequeña modificación que vuelve memorable al documento: enviar END al comienzo además de al final. RFC 1055 explica que así se eliminan los bytes erróneos acumulados por el receptor a causa del ruido de línea.

En una situación normal, el resultado parece desperdicio. El END que cerró la trama anterior y el END que abre la nueva aparecen consecutivamente. Eso genera un paquete vacío o malo. No es una excepción maquillada: el RFC dice que la capa IP lo descartaría y el código de recepción suministrado ni siquiera entrega una trama cuando END llega sin datos acumulados.

En una situación alterada, la economía cambia. Puede haber una secuencia de bytes en el búfer que no forma una trama confiable, pero que de otro modo sería tomada como el prefijo de la siguiente. El END inicial declara terminado ese residuo. Lo que hubiera llegado por ruido se descarta antes de que entren los datos del nuevo datagrama. El receptor vuelve a un estado sencillo: espera contenido después de una frontera conocida.

Por eso es impreciso decir que END «recupera el paquete». Recupera una posición desde la que el lector puede dejar de atribuir el pasado incierto al futuro inmediato. No corrige los bytes expulsados. No prueba que el próximo paquete no tenga un bit alterado. No sabe si un proceso por encima del framing conserva el mismo contexto que su par. Su función es más modesta: impedir que la ambigüedad previa herede autoridad sobre el comienzo de la siguiente interpretación.

La propia rutina receptora ayuda a no exagerarla. Acumula datos hasta END, ignora los END que llegan con longitud cero y sólo reconstruye END o ESC cuando ESC lleva uno de los dos seguidores previstos. Ante otro seguidor, el código habla de infracción del protocolo y deja el byte como está. El lector no es un juez de validez del datagrama; es un mecanismo de frontera y transparencia para dos caracteres especiales.

De dónde sale la necesidad de otra prueba

RFC 1144 muestra con precisión por qué una frontera no puede cargar trabajos ajenos. Su compresión de cabeceras TCP/IP para enlaces serie lentos trata el paquete en un compresor y luego lo entrega a un framer. El compresor conserva por enlace una copia de cabeceras anteriores; los paquetes comprimidos pueden describir cambios respecto de esa memoria.

Ahí aparecen tres verdades que pueden divergir. La primera: se recibió un END y se pudo separar una secuencia de bytes. La segunda: esa secuencia superó una comprobación que indica que no llegó dañada. La tercera: el descompresor conserva el estado previo que permite interpretar las diferencias. RFC 1144 coloca la detección de errores en el nivel de framing y pide que el descompresor conozca el error para descartar el paquete y no propagar una mala reconstrucción. El END inicial de SLIP no proporciona esa señal.

Esta separación evita una atribución falsa de poder. Un delimitador puede hacer que la próxima unidad sea legible sin que sea íntegra. Una unidad íntegra puede llegar a un decodificador desalineado. Un decodificador alineado puede producir un paquete que una aplicación decide no usar. Cada nivel necesita la evidencia que puede observar, no una ceremonia heredada del carácter que cerró la trama.

La comparación con RFC 1662 debe mantenerse igual de acotada. El framing PPP tipo HDLC posterior especifica una secuencia de bandera para inicio o final, transparencia de octetos, FCS y reglas para tramas inválidas. También advierte que reutilizar la bandera de cierre como comienzo ahorra un octeto pero reduce la fiabilidad si ha habido inactividad: el ruido puede incorporarse a la siguiente trama si no se transmite una bandera de apertura. No convierte a PPP en el destino moral de SLIP. Hace visible que una frontera puede convivir con una política explícita de integridad y descarte.

La jurisdicción del marcador

Las Notas 64 y 65 de Heng Lu sugieren una prueba útil para mecanismos antiguos: quedarse con la función mínima, determinista y local que el código realmente ejecuta; no extraer de ella una autoridad que no contiene. El END inicial de SLIP tiene una jurisdicción perfectamente delimitada. Abandona el residuo anterior y permite empezar la próxima lectura desde una frontera. Nada en ese gesto demuestra que el datagrama sea correcto o que un estado dependiente del pasado haya sido restaurado.

Quien revise una recuperación de flujo debería conservar el búfer anterior, el delimitador observado, los bytes de la trama resultante, el resultado de la verificación de integridad y el estado de todo consumidor que dependa de paquetes anteriores. Si un informe sólo escribe «paquete recuperado», ha escondido cuatro decisiones independientes bajo una sola frase.

Fuentes y límites de la evidencia

El expediente cerrado consta de RFC 1055, RFC 1144 y RFC 1662. Sustenta la gramática de END/ESC, la razón del END inicial, las carencias declaradas de SLIP, el contraste compresor/framer y la comparación posterior con PPP. No sustenta una adopción universal, el comportamiento de dispositivos actuales, una tasa medida de ruido, un resultado de seguridad ni el uso de RFC 1144 en todas las líneas SLIP.