主题
组播路由
在主题维度下,组播路由主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径,涵盖相关报道、证据来源、市场参与者和基础设施影响,并给出足够背景,帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题,而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道,以及该主题对运营商、客户、投资者和关注政策的读者为何重要。

互联网历史
一条 IGMP 报告能证明有人加入,却数不出成员人数
1989 年的标准用一种节省报文的方式把组播成员关系告诉邻接路由器:一条主机报告可以代表整个本地组,而成员离开后的沉默只能等待计时器失效。

互联网历史
Mac 用户可以加入,反射器却要承载所有人:CU-SeeMe,1993—1995
CU-SeeMe 让普通 Macintosh 也能把实时画面送上互联网。两个人可以直接连接;多出一位参与者,架构便需要一台 Unix 机器接收、复制并转发每个人的数据流。桌面上的轻便体验,背后有一项由其他人运营的共享服务。

领导者
Ellen Zegura 与可迁移的组播核心
当组播接收者在网络中的分布发生变化,原先选定的共享路由核心就可能不再合适。1996 年,Ellen Zegura 与 Michael J. Donahoo 把“核心是否应随群组迁移”作为动态组播路由问题提出;他们也讨论了怎样借助单播信息估算组播树带宽,以及如何限制测量请求的回复数量,避免消息拥塞。

NANOG
数据包到达 CERN,许多提问却没能听见:1994 年 NANOG 1 与 MBONE
1994 年 6 月,NANOG 1 的组织者计划通过 MBONE 转播在安娜堡举行的会议。六月邮件档案留下了几种不同的现场反馈:有人找不到会话,有人请摄像机稳定地对准投影屏幕;而一位 CERN 收听者说,那里没有丢包,却听不清许多提问。数据流能到达,并不意味着会议的所有声音都随之传到了远端。

互联网历史
组播地址写出了汇合点,却没有证明它真的存在:RFC 3956
RFC 3956 把一部分控制面配置写进 IPv6 组播地址,让路由器都能算出同一个 RP 候选。确定性解决了“选谁”,却没有回答“它是否存在、可达、可信并且真的送达数据”。

互联网历史
过滤器可以逐条改,也可以一次整体替换
RFC 3678 没有要求组播应用重新学习怎样加入一个组。它保留了既有调用,又给源过滤器提供两种改法:一次调整一个发送源,或在一次操作中替换完整状态。

互联网历史
接收端不向发送端回报,却仍能调节组播速率:RFC 3738
2004 年,WEBRC 提出一种组播拥塞控制回路:接收端无需逐一向发送端报告状况。每个接收端自行测量路径并决定接收速率,再通过加入或离开组播信道表达决定。控制只是换了位置,并非消失。

IETF
两个私网源公布了同一个公网 `(S,G)`:RFC 5135 留下的身份断点
两个发送者在私网内可以使用同一个 SSM 组而互不混淆,因为各自的源地址不同。可是一旦 NAT 把它们都改写成同一个公网源地址,外部接收者看到的源与组便可能完全相同。RFC 5135 由此揭示了一条重要边界:转发成功、映射存在、IGMP 代理正确,都不能单独证明源身份随报文一起抵达。

IETF
数据已经进了解码器,认证却还没结束
在一个构造场景里,浏览器为了降低直播延迟,把刚解密的组播分片提前交给媒体解析器。随后到达的延迟认证材料证明其中一片不该被接受。密码学最终给出了结论,但高风险代码已经先处理了输入。

互联网历史
标签分支存在之前,第一个数据包必须先到:RFC 3353
节省标签状态的办法看起来很自然:没有流量,就不要建立组播 LSP。可一条新分支若要靠收到流量来触发,它首先得收到一个包;而那个包在二层到不了,恰恰是因为这条标签分支还不存在。RFC 3353 没有用“自动建立”遮住这个循环,而是把谁先看见、谁先行动写成了工程条件。

互联网历史
可复用模块组合后仍可能失效:RFC 3269
可靠组播不能只靠把可复用部件拼在一起。RFC 3269 要求每个 RMT 构建模块说明适用边界和依赖关系,并要求完整协议实例解释这些部件如何组合。

IETF
接收端发现中断,不等于组播入口收到了告警
BIER 树的末端最先看见连续性丢失,入口却可能仍不知道哪一条分支出了问题。BIER BFD 草案第 12 版把这段告警回程写得更具体:探测、送达与恢复,不能算作同一份证据。

互联网历史
RFC 3091 给出了一个 IPv4 无法表示的 π 组播地址
RFC 3091 设想用连续数据流、按序号查询的 UDP 应答,或组播来拼出π。问题是,它指定的组播地址不是有效的 IPv4 地址;同一文件里标出的 TCP 和 UDP 端口,也超出了传输层字段能够承载的范围。

互联网历史
Directory Agent 消失后,旧通知仍在继续;新服务却可能漏报:RFC 3082
RFC 3082 试图用事件通知取代反复轮询。它的故障恢复条款揭示了一种不对称:已经获知订阅的服务代理可以继续发送通知,新出现的服务代理却可能不知道有人正在监听。

IETF
加密能证明报文完好,却不能证明地址归谁
GAAP-25 把一项重要的安全边界写得更清楚:加密 Claim 必须同时具备保密性与完整性。但网络最容易犯的错误,是把“这条消息没有被篡改”理解成“发送者有权占用这个组播地址”。前者是密码学结论,后者是运营权威问题。

IETF
GAAP 第25版划清线路协议与 Python 示例接口的边界
技术草案里的示例代码很容易被误读为必须照搬的软件接口。9 月 25 日发布的 GAAP 第 25 版把这个边界写得更直白:需要共同遵守的是组地址 Claim 的线路交换,不是某一套 Python 函数。

互联网历史
表里写着“有成员”,这行也可能是管理员创建的:RFC 3019
RFC 3019 把 IPv6 组播监听状态装进两张 SNMP 表,也把创建、删除、启停和调参能力交给管理面。表项可以准确反映代理当前的表示,却不能独自证明远端听众仍在,更不能证明数据已经送达。

互联网历史
副本已经一致,客户端仍得回来:RFC 2443
上世纪九十年代末,ATM 网络可以承载 IP 组播,但客户端仍需要一个服务来回答:哪些组存在、哪些端点属于它们?RFC 2443 让多个 MARS 服务器共享这份状态。它最值得注意的规则出现在故障时:原始服务器一旦无法继续证明自己在线,其他服务器就必须清除从它那里学来的成员关系,再由客户端重新建立。

IETF
源还在表里,属性却在兼容边界消失了
审计员比对两端记录:组地址相同、源地址相同、holdtime 也相同,于是宣布 PFM 通告完整到达。但在中间的混合能力接口上,GSI 已被转换为旧式 GSH;共同字段被保留,所有流专属 Sub-TLV 都按规则丢弃。字段相等,只证明了缩小后的事实相等。

IETF
“零配置”并不等于没有否决者
一份正在 IETF 最后征求意见的草案,让应用自行挑选 IPv6 组播地址,却把最后的否决权交给能看见链路层冲突的网络设备。没有中央分配器,不代表没有权力层级。
