Tema
Enrutamiento multidifusión
Dentro de la faceta Tema, la inteligencia temática Enrutamiento multidifusión conecta artículos que comparten un tema específico, un enfoque en señales o una temática de seguimiento. La página ofrece a los lectores un recorrido más completo a través de informes relacionados, evidencia de fuentes, actores del mercado e implicaciones de infraestructura, con el contexto suficiente para entender por qué el tema es relevante en los movimientos corporativos, las decisiones de gobernanza, la exposición regional y el riesgo operativo. Los lectores pueden comparar señales recurrentes, organizaciones implicadas, evidencia pública, contexto de mercado, continuidad del servicio, contratación, competencia, cumplimiento y cuestiones de planificación estratégica que subyacen al tema, en lugar de quedarse en una lista escueta de artículos relacionados. Explica de qué trata el tema, qué actores o políticas de infraestructura están implicados, qué evidencia respalda la cobertura y por qué puede ser relevante para operadores, clientes, inversores y lectores interesados en las políticas.
Historia de Internet
Un informe IGMP probaba que había miembros, no cuántos
En 1989, un estándar hizo visible la pertenencia al multicast ante los routers vecinos mediante una señal económica: un informe podía representar a todo un grupo local, mientras que el silencio tras una salida debía caducar con el tiempo.
Historia de Internet
El Mac podía unirse; el reflector debía sostener a todos: CU-SeeMe, 1993-1995
CU-SeeMe permitió enviar imágenes en directo desde un Macintosh modesto. Dos personas podían conectarse de forma directa. Con una tercera, el problema cambiaba: hacía falta una máquina Unix que recibiera los flujos, los copiara y los redistribuyera. La sencillez visible en el…
Líderes
Ellen Zegura y el núcleo multicast que podía cambiar de lugar
Cuando los receptores de un grupo multicast se desplazan por la red, el router elegido como núcleo compartido puede dejar de estar bien situado. En un trabajo de 1996, Ellen Zegura y Michael J. Donahoo plantearon el traslado del núcleo como parte del problema de encaminamiento y…
NANOG
Los paquetes llegaron al CERN; muchas preguntas no se oyeron: NANOG 1 y el MBONE, 1994
La lista de NANOG conserva una escena poco espectacular pero reveladora: en 1994, un participante en el CERN dijo que no había perdido ningún paquete del MBONE, aunque muchas preguntas de la sala no se entendían. Otros mensajes del mismo mes registran a alguien que no encontraba…
Historia de Internet
La dirección de grupo nombraba su punto de encuentro. No demostraba que existiera: RFC 3956
RFC 3956 convirtió ciertos bits de una dirección multicast IPv6 en una elección de control: todos podían calcular el mismo RP. Que el cálculo coincidiera no significaba que hubiera un servicio esperando al final.
Historia de Internet
El filtro podía cambiar una fuente cada vez o reemplazar la lista completa.
RFC 3678 no obligó a las aplicaciones multicast a reaprender cómo unirse a un grupo. Conservó las llamadas anteriores y añadió dos formas de modificar un filtro de fuentes: ajustar un emisor concreto o sustituir todo el estado en una sola operación.
Historia de Internet
El receptor ajustaba su caudal sin informar al emisor: RFC 3738
En 2004, WEBRC propuso un bucle de control de congestión multicast que no pedía a cada receptor que enviara informes al emisor. Cada receptor medía su propio trayecto y elegía una tasa, expresando esa decisión al unirse a canales multicast o abandonarlos: el control cambiaba de…
IETF
El mapeo era estable. La identidad de la fuente no
Endpoint-Independent Mapping puede ofrecer una traducción predecible y, aun así, dejar a un receptor sin la distinción que necesita. RFC 5135 documenta un caso decisivo: dos fuentes SSM privadas que comparten grupo siguen siendo distintas dentro de la red, pero pueden convertirse…
IETF
Los paquetes eran auténticos. Respondían a otra solicitud.
En un escenario construido, el cliente confiaba en dos canales multicast del mismo proveedor. Un adversario intercambió unidades entre ellos. Las firmas seguían siendo válidas y la fuente seguía siendo conocida; lo que faltaba era la prueba de que esos bytes respondían a la…
Historia de Internet
El primer paquete tenía que llegar antes de que existiera su rama etiquetada: RFC 3353
Ahorrar estado parecía sencillo: no crear una rama MPLS multicast hasta que hubiera tráfico. El problema empezaba con el primer paquete. Si el router de destino necesitaba verlo para activar la rama, pero la rama era el medio por el que debía recibirlo, la automatización quedaba…
Historia de Internet
Los bloques reutilizables también podían fallar juntos: RFC 3269
El multicast fiable necesitaba algo más que piezas reutilizables. RFC 3269 exigió que cada bloque de RMT declarara sus límites y dependencias, y que el protocolo completo explicara cómo encajaban.
IETF
La cola detecta el fallo; la cabecera aún debe recibir la alarma
Un receptor puede perder la señal de control de un árbol BIER antes de que el emisor sepa qué rama falló. La revisión 12 del borrador BIER BFD fija con mayor detalle cómo viaja ese aviso de vuelta y qué demuestra, exactamente, la respuesta de la cabecera.
Historia de Internet
El grupo multicast de pi no era una dirección IPv4: RFC 3091
RFC 3091 imaginó clientes que reconstruían pi a partir de un flujo, respuestas UDP por posición o multicast. Pero su grupo multicast no podía expresarse como una dirección IPv4 válida, y los puertos TCP y UDP que aparecían en el mismo documento tampoco cabían en los campos de…
Historia de Internet
Los avisos continuaron sin el Directory Agent; nuevos servicios aún podían pasar inadvertidos: RFC 3082
RFC 3082 buscaba sustituir las consultas periódicas por avisos de cambios en los servicios. Su procedimiento de recuperación revela una asimetría: los agentes de servicio ya informados pueden seguir anunciando, mientras que un agente nuevo quizá nunca se entere de que alguien…
IETF
La clave abre el mensaje, no concede la dirección
GAAP-25 cierra una vulnerabilidad concreta: un Claim cifrado ya no puede confiar en confidencialidad sin integridad. Pero la corrección criptográfica no responde quién está legitimado para ocupar una dirección multicast. Mezclar ambas preguntas convertiría una mejora del…
IETF
GAAP-25 separa el protocolo de su ejemplo de API en Python
Una llamada de ejemplo puede terminar convertida, por costumbre, en una supuesta regla de compatibilidad. La revisión 25 de GAAP intenta impedir esa confusión: lo que debe ser común entre participantes es el intercambio Claim, no la interfaz interna de cada aplicación.
Historia de Internet
La fila decía que había miembros. El gestor podía haberla creado: RFC 3019
RFC 3019 convirtió la pertenencia multicast IPv6 en tablas legibles por SNMP. También permitió crear y borrar filas, declarar miembro al propio sistema y cambiar los temporizadores. La tabla era una superficie de control, no un testigo independiente de recepción.
Historia de Internet
Las réplicas coincidían. Los clientes aún tenían que volver: RFC 2443
A finales de los años noventa, ATM podía transportar multicast IP, pero cada cliente necesitaba un servicio que conociera los grupos y sus miembros. RFC 2443 compartió ese conocimiento entre varios servidores MARS. La regla más reveladora aparecía ante una falla: si el servidor…
IETF
Un solo vecino antiguo redujo el anuncio de toda la interfaz
Siete routers de un segmento entendían GSI; el octavo no. El primer salto hizo lo que exige la compatibilidad: anunció GSH para todos. La fuente, el grupo y el tiempo de retención llegaron, pero los atributos de flujo no cruzaron la interfaz. La minoría no bloqueó el protocolo…
IETF
La red sin configuración también tiene quien vete
Un borrador del IETF permite que cada aplicación elija su dirección multicast IPv6, pero reserva a la infraestructura una jugada que siempre gana. El detalle convierte una colisión de hardware en una decisión visible y, al mismo tiempo, abre una nueva superficie de confianza.