トピック
マルチキャストルーティング
「トピックの観点から見たマルチキャストルーティングトピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
インターネット史
IGMP の報告は参加を示しても、人数までは数えなかった
1989 年の標準は、少ない制御通信でマルチキャスト参加を隣接ルーターへ知らせた。一台の報告がローカルグループを代表し、離脱後の沈黙はタイマーが切れるまで残った。
インターネット史
Macから参加できた。全員を支えたのはリフレクターだった――CU-SeeMe、1993～1995年
CU-SeeMe は、身近な Mac からインターネットへ動画を送る道を開いた。二人なら直接つながれる。三人目が加わると、全員の映像を受け取り、複製し、配り直す Unix マシンが必要になった。デスクトップの手軽さは、別の誰かが運用する共有サービスに支えられていた。
リーダー
Ellen Zeguraと移動できるマルチキャストの中核
グループの受信者がネットワーク内を移れば、共有ルーティングツリーの中核として選ばれたルーターは、次第に都合の悪い場所になることがある。1996年、Ellen Zegura と Michael J. Donahoo は、中核の移動を動的マルチキャストルーティングの課題として提案した。同時に、単一のユニキャスト情報からマルチキャストツリーの帯域をどう見積もるか、測定要求への応答をどう制限してメッセージの集中を避けるかも論じた。
NANOG
CERNではパケット損失ゼロ。それでも質問は聞こえない――1994年、NANOG 1のMBONE中継
1994年6月、NANOG 1の主催者は、アナーバーで開く会合を MBONE で配信する計画を告知した。後日のメーリングリストには、セッションが見つからないという声、スクリーンを映すよう求める声、そして CERN ではパケット損失がなかった一方で質問の多くが聞こえないという報告が並ぶ。パケットが届くことと、会議がそのまま届くことは同じではなかった。
インターネット史
グループアドレスはRPを指した。その存在までは証明しなかった：RFC 3956
RFC 3956 は、IPv6 マルチキャストの宛先から PIM-SM の RP を計算できるようにした。同じ式は同じ候補を返す。しかし計算結果の一致は、そこに稼働中のサービスがあるという証明ではなかった。
インターネット史
フィルターは一件ずつ変えることも、一括で置き換えることもできた
RFC 3678は、マルチキャストアプリケーションにグループ参加の呼び出し方を覚え直させなかった。従来の呼び出しを残したまま、送信元フィルターを変える二つの方法を加えた。送信元を一つだけ調整する方法と、状態全体を一回で置き換える方法である。
インターネット史
送信者への報告なしに受信速度を変える仕組み：RFC 3738
2004年、WEBRC は受信者ごとの状態報告を送信者に求めないマルチキャスト輻輳制御ループを提案した。各受信者が経路を測定して受信速度を決め、その判断をマルチキャスト・チャネルへの参加・離脱で表す。制御がなくなったのではなく、場所が移った。
IETF
「グループを変えられる」は解決ではない：RFC 5135 がアプリ側に残した仕事
RFC 5135 は、NAT 配下の二つの SSM 送信元が同じグループを選ぶと、外側で同じ公開 `(S,G)` に見える場合があると明記する。そして暫定策として、利用者が SSM グループを変更できるようアプリケーションに求める。ここで重要なのはボタンの有無ではない。衝突の検知から新しい組の周知、受信者の移行、旧経路の停止までを誰が証明するかである。
IETF
鍵が開示されるまで、映像は再生できなかった
構成例では、マルチキャストの映像パケットは時刻どおり届いていた。だが受信者が送信元を検証するための鍵は後から開示される。遅延を嫌って先に再生すれば認証を捨て、認証を守ればアプリケーションは待たなければならない。速度と証拠は同じ時計を共有していた。
インターネット史
ラベル付きの枝ができる前に、最初のパケットが届かなければならなかった：RFC 3353
使われていないマルチキャスト木にラベルを配らない。資源節約としては正しい。しかし「パケットを見てから枝を作る」と決めた瞬間、下流のルーターは、まだ存在しない枝を通るはずの最初のパケットを待つことになる。RFC 3353 が残したのは、まさにこの起動時の空白を埋めるための選択表だった。
インターネット史
再利用できる部品も、組み合わせれば破綻しうる：RFC 3269
信頼性マルチキャストは、再利用可能な部品を並べるだけでは成立しない。RFC 3269 は各 RMT ビルディングブロックに適用範囲と依存関係を示させ、完成したプロトコルの構成も説明するよう求めた。
IETF
末端の障害検知は、送信側への通知ではない
マルチキャストの受信点が途絶を見つけても、送信側にはまだその事実が届いていないかもしれない。BIER BFD の新しい作業草案が具体化したのは、監視そのものよりも、障害を知らせる帰路と応答の意味である。
インターネット史
RFC 3091のπマルチキャスト先は、IPv4アドレスではなかった
RFC 3091は、ストリーム、番号指定の UDP 応答、マルチキャストを使ってπを組み立てる構想を描いた。しかし、指定されたマルチキャストグループは有効な IPv4 アドレスとして表せず、文書中の TCP・UDP ポートも、運ぶ側のフィールドに収まらなかった。
インターネット史
Directory Agentが消えても通知は続く。新サービスは見落とされうる――RFC 3082
RFC 3082は、サービス変化を確かめるための定期的な問い合わせをイベント通知に置き換えようとした。その復旧手順が示すのは、より細かな非対称性だ。すでに購読を知らされたサービスエージェントは通知を続けられるが、新しく参加したエージェントには、誰かが待っていることが伝わらない場合がある。
IETF
鍵を持つ者が、アドレスを持つ者とは限らない
GAAP-25 は暗号化された Claim の改ざん耐性を明確に強めた。しかし、鍵を共有しているという事実は、マルチキャストアドレスを使う正当な権限まで証明しない。実装で守るべきなのは、この二つを混同しないことである。
IETF
GAAP第25版、通信規約とPython APIの例示を明確に分離
技術文書にある関数名は、実装者の手に渡ると標準の一部のように扱われかねない。GAAP の新しい草案が明示したのは、共有すべきものはマルチキャストアドレスの Claim 交換であり、アプリケーション側の Python API ではないという点だ。
インターネット史
「メンバーあり」の行は、管理側が作った行かもしれない：RFC 3019
RFC 3019は IPv6 multicast の listener 状態を SNMP から読める形にした。同時に、cache 行の作成と削除、local membership の設定、MLD の有効化や timer 調整も可能にした。表は agent の現在地を示すが、remote listener や受信結果の独立証明ではなかった。
インターネット史
レプリカは一致していた。それでもクライアントは戻らなければならない――RFC 2443
1990年代末、ATM 網では IP マルチキャストを運べたが、クライアントには「どのグループがあり、誰が参加しているのか」を把握する仕組みが要った。RFC 2443は複数の MARS サーバーでその状態を共有した。ただし、障害時の規則は単純な冗長化とは違う。元のサーバーが生存を示さなくなれば、仲間のサーバーはその由来の会員情報を消し、クライアント自身が戻って登録し直す。
IETF
知らない属性を捨てても、メッセージは正常として通る
受信ルーターは GSI を受理し、`(S,G)`を学習し、エラーを一つも返さなかった。しかし、その運用判断に必要だった Sub-TLV の型は未実装で、規定どおり無視されていた。正常処理とは、すべての意味を理解したという宣言ではない。
IETF
ゼロ設定にも拒否権者はいる
IPv6 マルチキャストのアドレスを管理者なしで選ぶ IETF 草案は、アプリに先手を認める一方、リンク層の衝突を見つけたネットワーク機器には必ず勝つ拒否権を与える。分散型であることと、権限が存在しないことは同じではない。