要約

  • RFC 3077 は衛星フィードの物理的な一方向性を保ち、ノードの双方向インターフェース間のトンネルで、受信機が放送媒体では送れないリンク層通信を模した。
  • DTCP の告知はフィードの発見と古いトンネル終端の失効に役立つが、フィードの認証、全受信機共通の最適経路、アプリケーションへの配送は証明しない。

2001年3月発行の RFC 3077 は、同じブロードキャストリンクを使う二つの装置が、そこで双方向の会話を完結できない問題から始まる。フィードは一方向リンクへ送信できるが、受信機は聞くだけだ。送信専用フィードもそのインターフェースでは何も受信できない。一方、インターネットの多くのプロトコルは両方向の通信を前提にし、ルーターは次ホップにパケットを送り、応答や経路更新を待つ。

解決策は受信機を送信可能にすることではなかった。受信機とフィードには、IP ネットワークに接続する通常の双方向インターフェースも必要だった。受信機がフィードへリンク層フレームを送る場合、フレームをカプセル化し、トンネルでフィードのインターネット側アドレスへ運ぶ。フィードが復号して単方向リンク側に渡す。衛星放送は下り経路のままで、トンネルがノード間の帰路を担う。

なぜネットワーク層ではなくリンク層を模すのか。既存の上位プロトコルが衛星の物理特性を知らずに使えるからだ。RFC は双方向ブロードキャスト網で可能な六つの通信を挙げる。フィードから受信機への配信は物理経路で既に可能だった。残る五つ、受信機からフィード、受信機同士、ブロードキャストとマルチキャストなどをトンネルで補う。これにより ARP や隣接ルーター向けの経路制御を従来の層で動かせるが、物理リンクに逆方向送信機能が生まれたわけではない。

文書は内側パケットを IP で運ぶ方法として Generic Routing Encapsulation（GRE）を推奨する。外側 IP はフィードの双方向アドレスに届き、GRE ヘッダーが単方向リンクのリンク層プロトコルを示し、負荷部には元の MAC フレームが入る。別のトンネル種別も可能だが、両端で意味を合意する必要がある。RFC 3077 はトンネルをリンク層へ適合させるだけで、GRE を認可・セキュリティ方式に変えない。

フィードの発見には Dynamic Tunnel Configuration Protocol（DTCP）を使う。意外なのは、DTCP もインターネット帰路ではなく単方向リンクを通る点だ。HELLO はフィードから受信機へ送られる。JOIN は稼働を知らせ、LEAVE は停止を通知できる。メッセージには間隔、シーケンス値、トンネル種別、一つ以上のフィード双方向 IP アドレス（FBIP）が含まれる。受信機はマルチキャスト告知を監視し、アクティブなフィード、終端、タイマーを一覧にする。

LEAVE は該当項目を早く消す。HELLO が途絶えても、タイムアウトにより削除される。ただし原因までは分からない。フィードの停止でも単方向リンクの断でも同じく、双方向接続を保証できなくなる。タイマーは何を止めるべきか示すが、どの装置が故障したかも、アプリケーションまで届いたかも証明しない。

フィード選択は各受信機のローカル判断だ。RFC は往復時間の短さを一例に挙げるが、全網共通の選択規則を定めていない。管理者は到達しやすい別の終端を選んでもよい。動作に必要なフィード側 MAC アドレス（FUMAC）でさえ、統一的な発見方法は決められていない。共通メッセージは情報を交換するが、経路の有用性は設定と判断に残る。

「双方向」という抽象化は遅延差も隠す。RFC は静止衛星の一方向遅延を約250ミリ秒とする例を挙げ、インターネット帰路にも変動があると説明する。ARP のような応答待ち型のアドレス解決では、フィードが応答を待つ間にパケットが積み上がり、バッファー枯渇と破棄につながりうる。これは設計上の懸念であり、特定サービスの測定結果ではない。

単方向リンクが落ちた場合、受信機は対応するトンネルを無効にしなければならない。さもないと、トンネル上の受信パケットを見たルーターが、下位リンクも稼働中と誤解する可能性がある。RIP のように受信を隣接性の証拠にするプロトコルがある。フィード停止時も不要なトンネル通信を止める。フレームの復号は連鎖の一段であって、経路の安定やサービス完了の証明ではない。

信頼も別問題だ。RFC は ARP/IP のなりすましと未認可のトンネル利用を警告し、トンネル認証の必要性に触れるが、その方式は定義しない。模擬リンク上の経路制御プロトコルも、可能なら自身の認証を使い、未認可の受信機による偽経路を防がなければならない。DTCP の JOIN や端点欄は告知であり、資格情報ではない。

異なる機器が自動で相互運用できるとの約束もない。導入プロファイルでは MAC 形式とトンネル方式を定め、GRE を使わないならその種別の解釈を両端で合意する必要がある。マルチキャスト経路の構成と拡張性は範囲外だ。RFC 3077 は単方向媒体と帰路ネットワークを組み合わせて使えるようにするが、経路の差異、信頼、管理責任はそのまま残す。

主な一次資料