Resumen

  • RFC 869 dio a los centros de monitorización una manera común de consultar hosts, asociar respuestas, pedir estados y estadísticas y recibir avisos espontáneos. No hizo que todos los equipos describieran su funcionamiento con los mismos datos.
  • RFC 823 muestra lo que esa diferencia implicaba en una pasarela: interfaces, vecinos, redes alcanzables, una matriz de tráfico y contadores de pérdida, con informes definidos para cada tipo de máquina.

Análisis

La pasarela tenía que contar qué ocurría dentro

El Host Monitoring Protocol (HMP) no era solo una prueba para saber si una máquina respondía. La especificación de 1982 DARPA Internet Gateway describe cómo HMP recogía medidas y estados de las pasarelas. El estado incluía sus interfaces, las pasarelas vecinas y las redes a las que podía llegar. Su Host Traffic Matrix contaba datagramas según las direcciones IP de origen y destino y el número de protocolo. Otro mensaje de rendimiento exponía contadores de tráfico recibido, reenviado o enviado y de paquetes descartados, separados por interfaz y vecino.

Esos datos permitían observar desde otros puntos parte del trabajo interno de una pasarela. La matriz podía mostrar qué combinaciones de origen, destino y protocolo la atravesaban; un contador de descartes podía ubicar una clase de fallo en el equipo. Ninguno demostraba por sí solo que una aplicación llegara a su destino. RFC 823 describe un diseño de ingeniería, no un inventario independiente de los dispositivos que llegaron a desplegarse.

La consulta era común; el significado no

Robert Hinden publicó RFC 869 en diciembre de 1983 para sustituir la especificación anterior, IEN 197. Definía HMP como un protocolo de transporte sin conexión y orientado a transacciones. Su cabecera incluía el tipo de sistema, el tipo de mensaje, un número de secuencia, un campo que servía como contraseña o como número de secuencia devuelto y una suma de comprobación. La combinación de tipo de sistema y tipo de mensaje indicaba cómo interpretar los datos. Entre los sistemas enumerados figuraban IMP, terminal access controllers (TAC), pasarelas y otras máquinas; HMP usaba el número de protocolo IP 20.

Esa estructura común permitía reconocer consultas y relacionar una respuesta con su solicitud. No convertía los contadores de una pasarela en una descripción universal de cualquier otro host. RFC 869 dice que cada tipo de sistema definía sus tipos de mensaje según sus necesidades. Sus apéndices muestran ejemplos para IMP, TAC y pasarelas, pero la introducción aclara que esos ejemplos no formaban parte del protocolo HMP. El protocolo fijaba cómo preguntar y asociar una respuesta; el formato propio de cada equipo seguía determinando qué decía esa respuesta.

Una alerta no era lo mismo que un estado

RFC 869 situaba buena parte del trabajo de monitorización en un centro. El host recogía datos y los enviaba cuando se los pedían o cuando surgía un evento; el centro debía asegurarse de recibir correctamente lo que había solicitado. Para estados y estadísticas, podía repetir una consulta si vencía el plazo. Los números de secuencia ayudaban a asociar la respuesta con la pregunta y a detectar estadísticas duplicadas. Los datos estadísticos se conservaban durante un intervalo para volver a pedir una respuesta perdida.

Las alertas seguían otra regla. El host enviaba un datagrama cuando ocurría un evento, pero HMP no exigía acuse ni retransmisión. La alerta podía llegar pronto, aunque no constituía un registro garantizado de todos los sucesos. El estado también tenía un alcance acotado: el centro podía decidir si el host estaba activo según contestara o no a sus consultas. El silencio no permitía distinguir si había fallado el equipo, la ruta, la pregunta o la respuesta; una contestación tampoco demostraba que funcionara un servicio de nivel superior.

El centro podía modificar el equipo

La consulta podía solicitar parámetros o transportar datos de control. RFC 869 menciona interruptores y temporizadores para ajustar las mediciones y también un interruptor de reinicio para controlar el host. El equipo procesaba esos datos y devolvía un acuse de control, o un error si no podía tratarlos. El formato y el significado dependían del host. El acuse confirmaba el intercambio descrito por el protocolo; el RFC no lo presenta como prueba de que un servicio para usuarios funcionara después de la acción.

El RFC 1157 sobre SNMP, publicado en 1990, sirve para comparar diseños, pero no demuestra una línea directa desde HMP. RFC 1157 identifica Simple Gateway Monitoring Protocol (SGMP) como antecesor de SNMP y describe un modelo basado en consultar o modificar variables, con un conjunto limitado de avisos espontáneos. HMP merece leerse por separado: una envoltura común de mensajes permitía que equipos distintos informaran y recibieran datos de control propios de cada tipo.

En abril de 1983, la lista de protocolos oficiales, RFC 840, clasificó HMP como “Elective” e indicó que se utilizaba para monitorizar pasarelas de Internet y TAC, además de depurar implementaciones en ordenadores remotos pequeños. RFC 869 también describía ese uso en pasarelas y TAC mientras se diseñaban implementaciones para otros hosts. Es evidencia de un uso contemporáneo acotado, no de una adopción generalizada. Su interés histórico está en el límite que deja a la vista: el intercambio común hacía posible observar a distancia, pero el sentido del informe seguía dependiendo del equipo que lo enviaba.

Fuentes