Resumen

  • RFC 892 identificaba cada conexión de transporte mediante referencias escogidas por ambos extremos, no mediante la conexión de red utilizada como portador.
  • El modelo permitía multiplexar varias conexiones de transporte sobre una conexión de red y, en la clase correspondiente, dividir una conexión de transporte entre varios portadores.
  • La continuidad dependía de la clase negociada, la calidad de red, las funciones compartidas por el portador y la evidencia de reasignación; el camino no era identidad, pero tampoco era irrelevante.

La RFC 892 reservó palabras distintas para estados distintos: Transport Connection (TC) y Network Connection (NC). La primera ofrecía comunicación entre usuarios de transporte. La segunda era el servicio inferior que movía sus unidades de protocolo.

Antes de crear o usar una TC, la entidad debía asignarla a una NC, o a varias cuando funcionaba el splitting. Podía aprovechar una conexión existente o abrir otra. La asignación decidía el soporte. No creaba por sí sola la identidad de la conversación.

El estatus histórico también exige precisión. RFC 892 difundió una especificación ISO con fines informativos y negó expresamente ser un estándar para ARPA Internet. La RFC 905 la sustituyó con una edición posterior de ISO DP 8073 bajo la misma reserva. El archivo RFC conservó el diseño; no lo convirtió automáticamente en arquitectura operativa de Internet.

Cada extremo entregaba al otro su referencia

El iniciador enviaba un Connection Request TPDU (CR) con su source reference. El receptor respondía con un Connection Confirm (CC) y la referencia que había elegido. Desde entonces, cada extremo usaba el valor del otro como destination reference.

Eran números locales de 16 bits. No podían ser cero, estar activos ni seguir congelados tras una conexión anterior. No nombraban una empresa, una máquina para siempre ni una autoridad. Señalaban una entrada viva en la tabla de transporte del receptor.

La selección bilateral evitaba declarar un amo y un subordinado. También permitía tratar llamadas simultáneas sin un asignador central. RFC 892 dijo que el mecanismo identificaba la TC con independencia de la NC.

Ese límite era estrecho. Un TPDU con el número correcto todavía debía llegar por una asignación reconocida, en el estado correcto y entre las mismas entidades de transporte. La referencia no autenticaba al par ni autorizaba la operación de la aplicación.

La petición podía adelantarse; la confirmación podía corregirla

Las cinco clases no eran cinco nombres para lo mismo. La clase 0 era simple; la 1 añadía recuperación de fallos señalados; la 2 multiplexaba; la 3 combinaba recuperación y multiplexación; la 4 detectaba y reparaba además pérdidas, duplicados, corrupción y desorden del servicio inferior.

El iniciador proponía una clase preferida y alternativas, salvo cuando prefería la clase 0. Al enviar el CR podía empezar como si la preferencia fuera a aceptarse. Esa optimización no convertía la suposición en acuerdo. El CC llevaba la selected class; si el receptor escogía otra opción permitida, el iniciador debía cambiar sus funciones.

El tamaño de TPDU seguía otra negociación. El receptor podía aceptar el máximo propuesto o reducirlo dentro del conjunto permitido. Las opciones propuestas también necesitaban una selección. Conectividad inferior, sintaxis válida, preferencia del iniciador y contrato confirmado eran evidencias diferentes.

La calidad disponible restringía la decisión. RFC 892 distinguía servicios de red por errores residuales y fallos señalados. También consideraba el nivel requerido y el coste. Una NC podía ser alcanzable y aun así no servir porque no ofrecía la calidad necesaria o porque una función pervasive ya aplicada resultaba incompatible.

Compartir un portador no fusionaba las conversaciones

La multiplexación colocaba varias TC en una NC. La destination reference de cada TPDU permitía separar el estado de destino. La infraestructura inferior era común; las secuencias, crédito, confirmación y liberación de cada TC seguían siendo propias.

Pero compartir introducía acoplamiento. Una función pervasive utilizada por la primera TC de una NC debía aplicarse a las demás durante la vida del portador. El camino no era la identidad de cada conversación, aunque sí podía imponer una configuración colectiva.

Splitting and recombining invertía la relación. Una sola TC podía usar varias NC para mejorar resiliencia o caudal. La tabla de funciones de RFC 892 lo limitaba a la clase 4. No es evidencia de que todo transporte ISO fuera multipath; sí demuestra que la especificación podía representar un estado de transporte encima de varios soportes.

La reasignación cubría otra transición. En las clases de recuperación que la invocaban, la pérdida de la NC podía llevar la TC a otro portador y luego a resynchronization. El par reconocía la nueva asignación por un TPDU válido, direcciones de red coherentes con las mismas entidades y las referencias existentes.

La clase 0 conservaba el caso contrario. No tenía una liberación de transporte independiente, y la vida de la TC estaba directamente correlacionada con la NC. Por eso ninguna frase general sobre separación de capas sustituye la prueba de la clase realmente seleccionada.

El servicio inferior terminó siendo TCP en otra rama de la historia

La RFC 983 propuso mostrar servicios ISO TSAP mientras usaba TCP/IP internamente. Las capas superiores ISO podían operar sin conocer el cambio. El memo, sin embargo, declaró fuera de alcance un plan completo de transición.

La RFC 1006 sustituyó aquella propuesta con la versión 3 y normalizó transport class 0 sobre TCP. Había una incompatibilidad de forma: TCP entrega una corriente de octetos, mientras TP0 espera objetos discretos. La solución fue el TPKT, un contenedor con longitud alrededor del TPDU. Delimitaba; no autenticaba ni firmaba.

TCP open pasó a representar el establecimiento inferior y TCP close la desconexión. El resultado correspondía a la clase 0, por lo que portador y TC compartían más estrechamente el ciclo de vida. Aun así, la interfaz ISO de transporte podía mantenerse sobre una tecnología inferior diferente.

La RFC 2126 refinó después la operación sobre TCP en IPv4 o IPv6 y añadió variantes de clase 0 y 2. Conservó la versión TPKT para proteger la base instalada de RFC 1006. Reservó el puerto TCP 102, pero aclaró que una conexión conforme podía usar otro.

El registro de nombres de servicio y puertos de IANA mantiene iso-tsap en 102. La inscripción prueba coordinación del número, no presencia de software, clase acordada, referencia viva ni éxito de la aplicación.

Fuentes y límites

El análisis usa RFC 892, RFC 905, RFC 983, RFC 1006, RFC 2126 y el registro IANA. Esas fuentes describen mecanismos, estatus y mapeo sobre TCP. No demuestran despliegue actual, adopción de OSI por Internet, descendencia directa hacia QUIC o SCTP, soporte universal de splitting, identidad autenticada ni conducta de un producto concreto.