Resumen

  • Header-Last permitía esperar a conocer el tamaño comprimido antes de declarar si un paquete SDTP iniciaba, continuaba o terminaba una trama serie.
  • RFC 1963 segmentaba con B/F: E indicaba la extensión de cabecera CS y SDTP no tenía campo de secuencia. B/E más secuencia correspondían a PPP Multilink en RFC 1990.
  • Length delimitaba paquetes dentro de una trama PPP compuesta y Port seleccionaba un canal negociado; ninguno probaba que no faltaran fragmentos ni que el servicio final se hubiera recuperado.

El detalle más extraño de RFC 1963 no era un nuevo algoritmo, sino la posición de unos pocos bits. El paquete por defecto de Serial Data Transport Protocol colocaba los datos transportados delante y la cabecera terminal detrás. Además, invertía el orden de los octetos de esa cabecera. Para analizarlo, el receptor debía avanzar desde el principio y, a la vez, leer estructura desde el final.

La razón estaba en el instante en que el emisor podía conocer la respuesta. El memo, publicado como Informational en agosto de 1996, surgió de trabajo relacionado con la compresión síncrona en DSU/CSU. Una trama serie comprimida podía tener que dividirse entre varios paquetes SDTP. Antes de que el compresor produjera su salida, el transmisor no sabía necesariamente si el paquete actual contendría el final. Una cabecera inicial le exigiría decidir demasiado pronto. Una cabecera final le permitía observar el tamaño y codificar después el tipo de fragmento.

Por eso Header-Last era el valor predeterminado, no una anomalía accidental. Header-First podía negociarse cuando no había división entre paquetes, cuando la compresión no estaba acoplada a SDTP o cuando el recorrido del hardware favorecía el orden habitual. La negociación elegía cómo interpretar bytes. No demostraba que el compresor estuviera sincronizado ni que el receptor hubiera producido una trama válida.

SDTP tampoco aparecía sin contexto. PPP debía alcanzar la fase Network-Layer Protocol y SDCP debía llegar a Opened. El registro de IANA asigna 0x0049 a PPP-SDTP y 0x8049 al protocolo de control PPP-SDCP. Estos valores identificaban una gramática acordada. No convertían el estado Opened en un recibo de entrega.

En la forma básica, cada campo Information de PPP llevaba un único paquete SDTP. El campo Length era opcional y solo aparecía cuando se habían acordado tanto Length-Field-Present como Compound-Frames de RFC 1570. Entonces varios paquetes podían ocupar el mismo campo Information. Cada longitud incluía su propio campo, el Port opcional, la cabecera de adaptación, los datos y el posible relleno Odd-Pad. Un octeto representaba longitudes combinadas entre 2 y 255; dos octetos llegaban a 65535; cero significaba todo lo que quedaba del contenedor PPP.

Ese número permitía cortar correctamente el contenedor. No decía que una trama serie original estuviera completa. Un paquete siguiente podía pertenecer a otro fragmento, trama o puerto. La capacidad de localizar el final de una unidad de transporte no revelaba si una unidad anterior se había perdido.

Multi-Port creaba otra capa de nombres. Sin negociarlo, Port 0 era implícito y no había octeto Port. Una vez negociado, todos los paquetes incluían un número: 0 a 254 para datos y 255 para control. Algunos parámetros se definían por puerto, mientras que un mensaje de control de flujo en 255 podía tener alcance general.

Port era útil para demultiplexar, pero no era una credencial. Nada en RFC 1963 vinculaba criptográficamente Port 7 con un cable, una máquina, un cliente o un servicio. La relación dependía de una tabla local. Para demostrar que esa tabla seguía describiendo la realidad física hacía falta evidencia externa al paquete.

Los límites de la trama serie estaban en B y F. En transporte síncrono tipo HDLC, B señalaba el inicio y F la porción final; ambos a cero indicaban una parte intermedia y ambos a uno una trama completa. En modo asíncrono, ambos debían estar activos. E no era la marca de final: indicaba la presencia de una extensión de cabecera CS.

Este es el punto en el que una comparación debe ser explícita. RFC 1990 PPP Multilink sí utilizaba B/E y números de secuencia de 12 o 24 bits a través de un haz de enlaces. RFC 1963 no incluía ningún campo sequence. Por tanto, SDTP no podía usar el avance de una secuencia Multilink para deducir que faltaba un fragmento.

La tabla B/F del propio documento exige cautela. Imprime 1,0 para Begin Frame y vuelve a imprimir 1,0 para Final Frame, aunque la frase anterior define F como la señal de porción final. El significado coherente surge de la prosa y de las definiciones circundantes. Esa observación no autoriza a inventar el comportamiento de una implementación. Para ello harían falta código, pruebas o trazas que las fuentes consultadas no aportan.

El límite de integridad aparece con FCS-Type. SDTP llevaba los octetos situados entre las banderas de una trama HDLC, no las banderas. Por omisión también llevaba el FCS interior. Una opción podía retirarlo en el emisor y regenerarlo en el receptor. RFC 1963 advirtió que esa regeneración no debía usarse sin PPP Reliable Transmission u otra capa capaz de notificar de manera fiable la pérdida de paquetes. También prohibió entregar al usuario una trama incompleta o defectuosa con un FCS nuevo y correcto.

La advertencia expone la diferencia entre forma e integridad. B/F describe dónde parecen comenzar y terminar los datos. Length describe dónde termina el paquete. Port describe a qué flujo acordado se asignan. Ninguno informa de una pérdida. Si desaparecía una porción central y ninguna capa lo notificaba, el receptor podía construir algo que pareciera bien delimitado. Recalcular su checksum convertiría un hueco en una falsa señal de validez.

RFC 1663 trataba la fiabilidad mediante Numbered-Mode, ventanas, confirmaciones y retransmisiones negociadas por separado. RFC 1962 trataba la negociación de compresión y los intercambios Reset. Sus garantías no deben atribuirse retroactivamente a los campos de SDTP. Header-Last coordinaba el momento de una decisión con el compresor; no era el mecanismo de compresión ni el de recuperación.

La separación que plantea Lu Heng entre especificación declarada y evidencia ejecutable encaja aquí. RFC 1963 definía una estructura común mínima: posiciones, extensiones, límites, tamaños y etiquetas de puerto. Cada sistema debía demostrar por separado el orden recibido, la pérdida, la política de búfer, el mapeo local, el tratamiento de FCS y la entrega final. La especificación hacía verificables esas responsabilidades sin fingir que ya estaban cumplidas.

Fuentes