Resumen

  • MARS registraba y difundía la asociación entre un grupo de capa 3 y los extremos ATM del clúster, pero no reenviaba los datos multicast.
  • Un emisor que ni siquiera tenía que ser miembro reunía la respuesta MARS_MULTI y después creaba su VC punto a multipunto, o recibía la dirección de un MCS que ocultaba el abanico posterior.
  • Registro, respuesta completa, hoja añadida, CSN continuo y llamada de envío eran pruebas limitadas de etapas distintas, no de vida, entrega, identidad, autorización, QoS o seguridad.

RFC 2022 diseñó un servicio de resolución, no un centro por donde pasara todo el tráfico. La frase que fija el reparto es inequívoca: MARS no interviene en el multicast real de capa 3. Conservaba un mapa y anunciaba sus cambios; los extremos construían las conexiones.

La división conciliaba dos formas distintas de describir una red. IP multicast entregaba al emisor una dirección de grupo sin conexión. ATM UNI necesitaba direcciones de extremos y señalización. El emisor preguntaba a MARS por el conjunto vigente y, una vez completo, pedía a su gestor ATM abrir un VC punto a multipunto y agregar cada dirección como hoja.

Ni siquiera era obligatorio que el emisor figurara entre los receptores. RFC 1112 permitía enviar a un grupo sin unirse a él. Por eso, consultar o transmitir no demostraba pertenencia.

El final de la lista era parte de la prueba

MARS podía dividir una respuesta extensa en varios MARS_MULTI. El indicador x marcaba el último y el número y permitía detectar huecos. Sin el final y sin una secuencia coherente, el solicitante no poseía un mapa utilizable. Debía desechar lo parcial al faltar un fragmento o vencer el plazo.

Una lista completa seguía siendo una instantánea. La señalización posterior podía fallar por hoja, y RFC 2022 admitía reintentos. También permitía que empezaran a circular datos mientras quedaban hojas pendientes. El estado del VC raíz, por tanto, no resumía el estado de todos los destinatarios; aceptar un paquete para envío tampoco demostraba su llegada.

Un MCS hacía transparente otra ruta

MARS podía devolver una sola dirección perteneciente a un Multicast Server. Para el emisor, aquella hoja se trataba como cualquier otra; no necesitaba saber si correspondía a un miembro o al servidor. El MCS recibía los datos y los volvía a distribuir.

La transparencia tenía un precio probatorio. La dirección del MCS identificaba el punto de entrega intermedio, no a quienes estaban detrás. RFC 2149 estudió después arquitecturas con servidores multicast y la coordinación de varios MCS; no era una garantía ya contenida en RFC 2022.

Los avisos reparaban circuitos que podían estar desfasados

MARS_JOIN y MARS_LEAVE llegaban de forma asíncrona por ClusterControlVC. Cada extremo actualizaba las hojas de sus propios VC. Si una baja eliminaba la última hoja, cerraba el circuito; el siguiente paquete obligaba a consultar y construir de nuevo.

El Cluster Sequence Number servía para advertir que podía haberse perdido un aviso. MARS lo incrementaba con cada transmisión por el canal, incluso sin modificar la base de miembros. Un salto no identificaba el alta o la baja ausente. Activaba la revalidación de todos los VC abiertos contra nuevos mapas, mientras los datos podían seguir fluyendo.

Así, la continuidad del CSN acreditaba una secuencia de control observada, no el éxito de las operaciones ATM ni la entrega final.

La ausencia de garantía también estaba especificada

El documento se limitaba a un MARS Cluster. Dejaba fuera el enrutamiento entre clústeres y la traducción de QoS de capa 3 a atributos ATM. No cerraba la coordinación de MARS de respaldo, la eliminación de miembros muertos ni el funcionamiento de múltiples MCS. Tampoco trataba la seguridad.

Cada señal debe conservar esa modestia. Un miembro en la base, una respuesta terminada, una hoja, un servidor elegido, una secuencia continua o una llamada aceptada no prueban por separado que el receptor siga activo, que la aplicación haya recibido datos, que la pertenencia sea coherente fuera del clúster o que exista identidad y autorización verificadas.

La aportación histórica de RFC 2022 fue mantener separados el directorio y el camino. Podían sincronizarse, pero no convertirse en un único hecho duradero.

Fuentes