Resumen

  • La variación de miembros, creadores de estado y objetivos de optimización llevó a RFC 2102 a dejar fuera del núcleo de Nimrod tanto la generación de rutas multicast como el mecanismo de reenvío.
  • La interoperabilidad se redujo a un contrato más estrecho: árboles compartidos o de origen podían coexistir si todos interpretaban de manera uniforme la estructura del estado instalado.
  • Una rama presente acreditaba una relación local de replicación, no miembros actuales, permiso, cobertura total, camino mínimo, reserva de recursos ni entrega.

Un receptor se incorpora tarde. En vez de pedir al emisor que vuelva a calcular todo, crea un camino hasta un router que ya pertenece al árbol y añade allí una rama. Para RFC 2102, este caso no era una anomalía: demostraba por qué el árbol debía definirse por el estado ejecutable en los routers y no por una única autoridad de cálculo.

Un problema con varias respuestas legítimas

Multicast tiene dos fases, generación de ruta y reenvío. Nimrod había fijado modos de reenvío unicast, pero no su algoritmo de cálculo. Para multicast dejó abiertas ambas fases. Los grupos cambian; una alta puede añadir una rama y una baja permitir una poda. El estado puede nacer en el emisor, en el receptor o en routers intermedios.

Además, las heurísticas no optimizan lo mismo. Un árbol barato puede aumentar el retardo. Un conjunto de rutas mínimas puede costar más al conjunto. Complejidad, estado, política y calidad conducen a elecciones distintas.

DVMRP formaba árboles de origen con reverse path forwarding. CBT compartía un árbol alrededor de un core y reducía estado, aunque alargaba trayectos. PIM admitía árbol compartido y árbol específico de origen. MOSPF calculaba con información de estado de enlace y membresía. IDPR dejaba al emisor escoger una ruta de política e instalar duplicación en entidades intermedias.

La forma común aparece al ejecutar

RFC 2102 no eliminó la necesidad de acuerdo. La trasladó a la información de reenvío. Si las implementaciones asignaban el mismo significado al estado, podían participar en un mismo árbol aun habiéndolo construido de manera diferente.

El ejemplo Nimpim usa un flow-id con parent, child list y target. Un Join agrega el nodo anterior como hijo de un flujo existente o instala una relación nueva y continúa hacia el padre. Un Prune retira un hijo y sólo elimina el flujo cuando ya no queda ninguno. Después, los paquetes con ese flow-id se copian conforme a la lista.

Este formato admite historias distintas: un árbol creado por el emisor recibe una rama iniciada por el receptor; un árbol compartido cambia a uno de origen; varias técnicas conviven mientras la distribución del grupo evoluciona. La condición no es compartir el razonamiento, sino compartir la gramática de ejecución.

Una rama no cierra la cadena probatoria

La fila no es un censo de receptores. RFC 1112 sitúa la membresía IGMP en la red directamente conectada y la somete a tiempos y agregación. El estado de reenvío es una proyección posterior.

Tampoco es autorización. RFC 2102 contempla restricciones por destino que obligan a construir varios árboles para partes disjuntas del mismo grupo. La rama visible no dice qué destinos faltan ni qué política los admitió.

No demuestra optimalidad. CBT puede desviarse por el core y el camino inverso de PIM sólo coincide con el mínimo bajo determinadas métricas. Reserva y calidad son pruebas diferentes: el RFC pide información sobre recursos compartibles y restricciones de servicio, pero la rama no confirma admisión, retardo o jitter.

Menos aún confirma que la fuente emitió, que todos los estados siguieron instalados, que el enlace transportó el paquete o que la aplicación lo consumió. El propio RFC no trata seguridad; una fila tampoco autentica al miembro.

La contribución fue escoger un límite

RFC 1992 ya aceptaba mapas y modos de reenvío múltiples. RFC 1753 separaba estados de usuario y servicio. RFC 2102 prolongó esa arquitectura: común sólo lo necesario para que dos implementaciones ejecuten juntas; local lo que todavía podía variar.

La Minimum Initial Specification de Lu Heng ofrece vocabulario posterior para leer esa decisión, y Running-Code Primacy evita confundir documento con adopción. Es una comparación editorial, no una relación causal. RFC 2102 es Informational y no acredita despliegues de Nimrod.

Su herencia es una disciplina: la diversidad termina donde empieza el significado compartido. Una rama prueba una rama. Todo lo demás requiere otro recibo.

Fuentes