Resumen

  • RFC 2171 describió una red de acceso múltiple construida por conmutadores sobre enlaces SONET/SDH punto a punto. El nodo heredaba el identificador del puerto; en un conjunto de conmutadores, la dirección repartía bits entre conmutador y puerto.
  • El destino indicaba por dónde reenviar una trama HDLC. No autenticaba la máquina, su dueño ni una organización, y un destino inválido podía descartarse en silencio.
  • El memorando de junio de 1997 era Informational, no provenía de un grupo de trabajo del IETF ni estaba en la vía de estándares. Las topologías eran propuestas de diseño, no pruebas de despliegue o interoperabilidad.

El número nacía al enchufar

RFC 2171 definió una equivalencia concreta: cada puerto tenía un identificador único dentro del conmutador y el nodo conectado debía heredar su dirección. En ese ámbito, dirección del nodo e identificador del puerto eran el mismo valor.

La elección respondía a la arquitectura. SONET/SDH ofrecía enlaces ópticos punto a punto. MAPOS transportaba datagramas dentro de tramas HDLC y añadía un conmutador que elegía la salida. De ese modo, varias líneas separadas se presentaban como una LAN con acceso múltiple, difusión y multidifusión.

El RFC mostraba tres configuraciones posibles: conexión directa, estrella con un conmutador de tramas y conjunto de varios conmutadores. En este último caso, los bits altos señalaban el conmutador y los bajos el nodo o puerto local. RFC 2173 lo expresaba sin metáfora: la dirección HDLC era equivalente al número del puerto al que estaba conectado el nodo.

Por eso “dirección del nodo” no significaba identidad perdurable. El valor resumía un lugar en una topología. Mover el cable podía cambiar la verdad de reenvío aunque no cambiara el equipo, la empresa que lo operaba ni su propietario.

Unicidad dentro de una frontera

El campo de dirección tenía ocho bits. El bit menos significativo cerraba el campo; en unicast, el más significativo era cero, por lo que quedaban seis bits para el destino. 0xFF era difusión y 0x01 identificaba al procesador de control del conmutador. La trama no llevaba otro campo para una dirección de origen.

En un único conmutador, la dirección seleccionaba un puerto. En un conjunto, una parte seleccionaba primero el conmutador y la otra el puerto. RFC 2174 detalló cómo se extraía el número del conmutador: si era local, se utilizaba el puerto codificado; si era remoto, la tabla determinaba el siguiente salto.

La unicidad era local al sistema configurado. El caso punto a punto de RFC 2173 lo demuestra con especial claridad: ambos extremos podían recibir 0x03, y el texto afirmaba que no había problema porque cualquier dirección servía en aquel entorno. Un valor que puede repetirse sin conflicto al cambiar el contexto no es una identidad intrínseca del host.

Tampoco la asignación automática era autenticación. Al recibir correctamente la señal SONET, el nodo pedía una dirección al procesador de control local. Reintentaba después de cinco segundos, verificaba la dirección cada 30 segundos y el conmutador podía suponerlo caído tras 90 segundos de silencio o un fallo de señal. Esos tiempos mantenían estado de conexión; no probaban quién poseía el dispositivo ni qué organización estaba detrás.

Reenviar no es certificar la entrega

RFC 2171 definía un envío sin conexión. El nodo escribía un destino y transmitía la trama; uno o varios conmutadores la encaminaban según esa dirección. Si el destino no era válido, la trama se descartaba silenciosamente.

El campo prueba qué salida solicitó el emisor. Una coincidencia en la tabla prueba que el conmutador encontró un siguiente salto o un puerto. Ninguno de esos hechos demuestra por sí solo que el host recibió la trama, que una capa superior la aceptó o que la aplicación cumplió su objetivo. El descarte silencioso no produce acuse positivo.

La capa IP conservaba otro espacio de nombres. RFC 2176 exigía una caché ARP que asociara direcciones IPv4 con direcciones HDLC de ocho bits. La necesidad de esa relación deja claro que ambos valores no eran intercambiables. La caché aportaba información de reenvío, no convertía el puerto en identidad permanente.

El formato adoptaba mecanismos de RFC 1662, pero la genealogía de la trama no prueba adopción. RFC 2171 advertía que era Informational, que no era obra de un grupo del IETF y que no había recibido necesariamente la revisión de un estándar. Tampoco trataba la seguridad y registraba diferencias entre SONET, SDH y sus implementaciones capaces de causar problemas de interoperabilidad.

La enseñanza histórica es precisa: una dirección puede bastar para que un conmutador actúe y, aun así, ser evidencia limitada. MAPOS ubicaba una conexión dentro de una estructura concreta; no nombraba de forma duradera todo lo que había al otro lado del cable.

Fuentes y límites

  • RFC 2171, topología, formato y regla de dirección.
  • RFC 2173, asignación automática derivada del puerto.
  • RFC 2174, direccionamiento y reenvío entre conmutadores.
  • RFC 2176, relación entre IPv4 y HDLC.
  • RFC 1662, base citada del entramado tipo HDLC.

Estos documentos no demuestran despliegue general, interoperabilidad medida, identidad autenticada, propiedad, entrega de extremo a extremo ni uso actual.