Resumen

  • Un agente intermedio de ST-II podía responder a CONNECT, aprobar un identificador de salto y reservar recursos antes de que la aplicación de destino viera la propuesta.
  • El ACCEPT del destino era otra decisión y devolvía la FlowSpec que aquella rama había conseguido realmente, no la petición original sin cambios.
  • El origen debía reunir un resultado por destino y resolver sus diferencias. Ninguno de esos estados demostraba que los datos posteriores llegaran o fueran útiles.

El árbol se construía antes de enviar

RFC 1190 publicó en octubre de 1990 la segunda versión experimental de Internet Stream Protocol, ST-II. Era un protocolo experimental de uso limitado, no un Internet Standard. Las fichas del RFC Editor y del IETF Datatracker registran que RFC 1819 lo reemplazó, pero no certifican ninguna reserva de producción.

ST-II vivía en la capa de Internet junto a IP. Su unidad no era un datagrama independiente, sino un árbol simplex: un origen, varios destinos posibles, rutas, estado en cada agente y recursos asignados. El protocolo pagaba el coste de construir ese árbol para que los paquetes de datos posteriores fueran baratos de reenviar.

La función de routing repartía la TargetList por próximos saltos. El nombre global del stream identificaba el objeto de control; los identificadores de enlace guiaban mensajes; el HID servía como atajo local para datos. Ninguno identificaba a una persona, demostraba autoridad ni sustituía al selector de la aplicación final.

La capacidad solicitada no era la capacidad obtenida

La FlowSpec transportaba lo deseado y los límites mínimos que el origen no permitía reducir. Un agente podía descubrir que su red no daba todo el ancho de banda pedido, añadía más retraso o imponía un PDU menor. Si seguía dentro de Limits, modificaba Desired y enviaba la nueva realidad a la rama siguiente.

La reserva incluía tablas de reenvío, procesamiento, buffers, ancho de banda e identificadores multicast. RFC 1190 no fijó un único mecanismo para materializar todo aquello. De hecho, admitió que pocas redes ofrecían reservas y que ninguna conocida por los autores cubría el conjunto completo.

Por eso una anotación «recursos reservados» no basta. Debe indicar qué gestor local decidió, sobre qué enlace y rama, con qué valores, durante qué intervalo y bajo qué posibilidad de preemption. Lo que una red pudo prometer no se convierte por contagio en propiedad de todas las demás.

El primer ACK no llegaba hasta el principal

Al recibir CONNECT, el agente intermedio contestaba deprisa con ACK, HID-REJECT o HID-APPROVE. El mensaje positivo cerraba una pregunta concreta: ¿pueden estos vecinos usar el HID propuesto para ese estado de reenvío? Después aún quedaban routing, reserva y propagación.

La aplicación remota podía estar a varios saltos. No había evaluado la FlowSpec acumulada, ni siquiera confirmado que escuchaba en el SAP indicado. Interpretar HID-APPROVE como aceptación del stream habría trasladado al router un poder que el diseño reservaba al destino.

La diferencia importa fuera de ST-II. Un componente puede reconocer un trabajo, abrir espacio y enviarlo adelante sin representar al principal que decidirá al final. Un acuse local es evidencia de custodia o procesamiento local, no de voluntad remota.

El destino recibía una propuesta ya transformada

El agente host del destino terminaba la negociación de HID y entregaba a la aplicación el Name, la FlowSpec, Options, Group y su selector local. La aplicación podía aceptar, negarse o reducir los parámetros deseados. Su respuesta generaba ACCEPT o REFUSE.

ACCEPT enlazaba su referencia con el CONNECT anterior y volvía por el mismo árbol en dirección contraria. Cada agente intermedio comprobaba la asociación, acusaba la recepción inmediata y propagaba un mensaje nuevo hacia el origen. La FlowSpec retornada narraba lo conseguido por esa rama.

Así se preservaban cinco controles: la ruta escogía camino; el gestor de recursos asignaba; los vecinos acordaban un identificador; la aplicación destino consentía; el origen decidía adoptar las condiciones finales. Una respuesta positiva en una capa no anulaba las decisiones posteriores.

Tres destinos podían producir tres contratos

El origen esperaba una respuesta de cada hoja. Conforme recibía ACCEPT, conocía los recursos de aquella trayectoria; un REFUSE o error cerraba la hoja de otra forma. Solo al terminar todas las respuestas y negociaciones podía declarar completo el setup.

Las FlowSpec podían no admitir un denominador común. Una rama ofrecía paquetes grandes a baja frecuencia; otra, paquetes pequeños a alta frecuencia. El origen tenía opciones explícitas: eliminar destinos, desmontar el stream o crear otro. Después enviaba CHANGE para liberar las reservas superiores al acuerdo finalmente usado.

No existía, por tanto, «la aceptación» como una sola fila global. Había decisiones por destino y una resolución del origen. El estado agregado debía decir quién quedó dentro y bajo qué parámetros.

El estado podía degradarse después del sí

Un ACCEPT necesitaba llegar y ser reconocido. Tras reintentos sin ACK, un agente enviaba REFUSE hacia el origen y DISCONNECT hacia el destino. Otro stream de mayor precedencia podía quitar recursos. NOTIFY anunciaba la garantía revisada, y un CHANGE fallido podía dejar una modificación parcial que exigía recuperación.

ST tampoco aportaba seguridad por sí solo. Ni el ACK ni ACCEPT autenticaban a una persona, otorgaban permiso comercial o demostraban facturación correcta. Para hablar de resultado hacían falta otros registros: paquetes enviados y recibidos, decodificación, temporización observada y efecto en la aplicación.

ST2+ quitó el HID que antes parecía central

RFC 1819 revisó el protocolo en 1995 como ST2+. Sus registros del RFC Editor y Datatracker conservan la identidad. La nota del IESG dejó claro que ni la versión nueva ni la anterior eran o estaban consideradas para convertirse en Internet Standard.

La revisión mantuvo CONNECT, la consulta a gestores locales, la decisión de la aplicación y el retorno de ACCEPT. Eliminó los HID porque su complejidad había dificultado la interoperabilidad. También eliminó las implementaciones por subconjuntos: permitir una parte del protocolo no había demostrado capacidad común.

El campo desapareció; la frontera de autoridad sobrevivió. Esa historia impide convertir una señal del wire format de 1990 en una verdad universal sobre aceptación.

La RFC 1077 había planteado que una red rápida necesitaba algo más que medio físico. Las RFC 1633 y RFC 2212 definieron después otras superficies de reserva y servicio garantizado. Son contexto, no prueba de genealogía directa ni de que ST-II se desplegara de forma general.

Fuentes