Resumen

  • La RFC 877 estableció una interfaz limitada entre IP y X.25: un identificador de protocolo, secuencias completas de paquetes para cada datagrama y parámetros negociables.
  • El circuito se abría cuando había tráfico y su cierre por inactividad dependía del coste local; no se asignaba uno a cada conexión TCP.

Análisis

El circuito también tenía un reloj económico

En septiembre de 1983, J. T. Korb publicó la RFC 877 para llevar datagramas del Protocolo de Internet por redes públicas de datos basadas en X.25. El documento dice que CSNET, la VAN Gateway y otras organizaciones ya habían adoptado el estándar. Es una afirmación sobre esos adoptantes, no un recuento de todas las redes.

La dificultad consistía en unir dos modelos operativos. IP enviaba datagramas; X.25 ofrecía circuitos virtuales sobre una red pública. La RFC no intentó que el circuito imitará una conversación de aplicación. Definió una interfaz común pequeña y mantuvo varias decisiones de operación en manos de los sitios conectados.

Una llamada, un identificador, una secuencia

El primer octeto del campo Call User Data de la petición de llamada X.25 identificaba el protocolo de red. El valor 0xCC indicaba IP. Después, cada datagrama se enviaba como una secuencia completa de paquetes X.25: empezaba en un límite de paquete y el bit More señalaba la continuación si hacía falta más de un paquete. La especificación no añadía otra cabecera a los paquetes de datos.

El tamaño estaba limitado, aunque podía negociarse. Sin un tamaño mayor acordado, el máximo para un datagrama IP era de 576 octetos. La RFC da 1.024 octetos como ejemplo de un tamaño superior negociado. Las ventanas y otros parámetros podían acordarse entre sitios; no se convirtieron en una configuración mundial única.

La sesión TCP no era la vida del circuito

El circuito seguía su propio calendario. La RFC 877 dice que un circuito virtual se abría bajo demanda cuando llegaba un datagrama a la interfaz. Podía cerrarse tras un período de inactividad cuya duración dependía del coste de mantenerlo abierto. La interfaz también podía cerrar un circuito si agotaba su disponibilidad, y cualquiera de los dos sitios podía cerrarlo.

La separación con TCP es expresa: los protocolos situados por encima de IP no afectan a este estándar. La interfaz no intenta abrir un circuito X.25 por cada conexión TCP. Por tanto, una sesión TCP prolongada no implicaba que hubiera un circuito de la red pública reservado para ella. El adaptador gestionaba un recurso de red; el estado de la conexión TCP quedaba en otro nivel.

La consecuencia documentada es concreta: si el circuito se cerraba o reiniciaba mientras se transmitía un datagrama, ese datagrama se perdía. La RFC no indica con qué frecuencia ocurría ni qué resultado veía después una aplicación. La respuesta de un protocolo superior queda fuera de las pruebas de este documento.

Una recomendación no equivale a una implantación universal

En 1984, el informe oficial de protocolos ARPA-Internet, la RFC 924, calificó «Internet Protocol on X.25 Networks» como Recommended y señaló la RFC 877 como especificación. En ese informe, Recommended alentaba a los hosts a implementar un protocolo; no afirmaba que todos lo hicieran. En 1992, la RFC 1356 describió el método como de uso amplio y sustituyó la especificación anterior para corregir ambigüedades y responder a nuevas necesidades sobre tamaños, gestión de circuitos e interconexión multiprotocolo.

Los documentos muestran un comienzo con adoptantes nombrados, una recomendación y una revisión posterior que recoge experiencia. No ofrecen una lista de despliegues, tarifas ni un temporizador de inactividad numérico.

Una lectura posterior desde la Nota 64

La Nota 64 de Heng Lu plantea que la especificación inicial debe limitarse a las reglas comunes indispensables y que las decisiones futuras permanezcan con quienes operan el sistema. Como lente editorial, ayuda a leer la forma de la RFC 877: 0xCC y los límites de los paquetes son reglas comunes; el tiempo de cierre y las facilidades negociables no tienen un valor global impuesto.

Esta comparación es retrospectiva. La RFC 877 no menciona la Nota 64, que tampoco prueba la intención de Korb. El registro técnico basta para mostrar la idea: IP podía identificarse sobre un servicio público X.25 sin uniformar la política de coste y duración de cada circuito.

Fuentes