要約

  • RFC 3331はSS7リンクをIP端点へ移したのではない。MTP1とMTP2はSignalling Gatewayに残り、M2UAがMTP2利用側との境界を運ぶことで、遠隔のMTP3がリンクを扱えるようにした。
  • SCTPアソシエーション、ASPの稼働状態、物理SS7リンクは別々の事実である。識別子の対応関係と明示的な監査がそれらを結びつけるのであり、緑色の接続表示だけでは足りない。

「ユーザー」はプロトコル層だった

MTP2 User Adaptationという名称は、加入者向けの適応機能のように聞こえる。しかしこの「ユーザー」は層構造上の呼び名である。MTP3はMTP2の唯一の利用層だ。バックホール構成では、実際のSS7回線、MTP1、MTP2をSignalling Gateway Process（SGP）が終端し、Media Gateway Controller上のApplication Server Process（ASP）がMTP3を実行する。M2UAは、本来同じ装置内で交わるMTP2とMTP3のプリミティブを、IPネットワーク上のSCTPでやり取りする。

この配置をつかむと、RFC 3331の意味が変わる。実際の回線に信号ユニットが到着し、MTP2はゲートウェイでリンク機能を担う。遠隔MTP3に別の「仮想回線」が生えるわけではない。MTP3が受け取るのはデータと状態通知であり、返すのは境界を越える要求である。確立、解放、輻輳、ローカルまたは遠隔プロセッサ停止、データ転送といった操作が分散した境界を通る。

RFC 2719のSIGTRAN枠組みでは、回線交換網の信号を受けるゲートウェイと、上位の制御ロジックを集約するコントローラを分けられる。RFC 3331はその構想のうち、MTP2とMTP3の間に具体的な切断面を置いた。これは単なる「SS7 over IP」トンネルではなく、層の境界を遠隔化する設計だった。

一つの識別子が物理回線と変化する通信路を結んだ

ゲートウェイはInterface Identifierを物理インターフェースに対応付ける。例としてV.35、T1またはE1の回線とタイムスロットがある。同じ識別子はSCTPアソシエーションとストリームにも関連付けられるが、この二つの対応は同じ程度に固定されていない。物理側は設定で定められ、アソシエーション側はASPの起動、停止、切替に伴って変わり得る。

Interface IdentifierはSGとASPの間で調整されるローカルな名前であり、回線の全世界共通番号ではない。パケットに識別子17が含まれていても、それはその通信文脈で相手が17を送った証拠にすぎない。運用者がどの銅線、光回線、タイムスロットを意図したかは、対応表の記録なしには分からない。

SCTPストリームは、あるリンクの待ち時間が他のリンクまで必ず塞ぐ事態を減らす。しかしストリーム番号はInterface Identifierの代わりにはならない。ストリームは単方向なので、受信側は到着ストリームだけから戻り方向のストリームを推定できない。RFC 3331はそのためM2UAヘッダーに識別子を持たせた。管理メッセージは共通ストリームを使い、MAUPのトラフィックは対応するデータ用ストリームを使う構成である。

運用上追跡すべき鎖は、物理リンクから識別子、識別子からApplication Server、さらに選ばれたASPからSCTPアソシエーションとストリームへ続く。どこか一つが古い、欠落している、または曖昧なら、遠隔MTP3が見るリンク状態はゲートウェイの実態からずれる。

接続、プロセス、リンクには三つの状態がある

SCTPはアソシエーションの確立を報告できる。M2UAはApplication Serverに対するASPの状態をDOWN、INACTIVE、ACTIVEとして扱う。MTP2は物理リンクの供用中、停止、輻輳、遠隔プロセッサ停止を別に示す。各表示が答える問いは異なる。

アソシエーションがUPという事実は、二つのSCTP端点が通信できることを示す。それだけで当該識別子についてASPが有効化されたとは言えない。ASP ACTIVEはトラフィックモードのもとでそのプロセスが選ばれたことを示し、物理リンクの健全性は証明しない。反対に、ゲートウェイ側のSS7リンクが健全でも、遠隔ASPが信号を処理できる保証にはならない。

RFC 3331はApplication Server状態と復旧中のPENDING期間もモデル化する。Override、Loadshare、Broadcastの各モードは、稼働中プロセスへのトラフィック配分を変える。フェイルオーバーでは動的な対応関係が一時的に無効になることがあるため、ゲートウェイはルーティングの都度ASとASPの状態を考慮する必要がある。また一つのSS7リンクの端末機能を提供するSGPは一つに限るよう勧告し、同じ物理資源を二者が同時に所有する事態を避けた。

これらを一つの「正常」表示にまとめると、復旧の判断を誤る。リンク状態を再同期していないASPへ切り替えたり、死んだ回線の前にメッセージを滞留させたり、遠隔処理系が不在なのにゲートウェイが信号を受け続けたりする可能性がある。

監査は現時点を照合するのであり、失われた履歴を復元しない

STATUS_AUDITではASPがゲートウェイにリンクの現在状態を照会できる。応答は停止、供用中、輻輳、遠隔プロセッサ停止などを知らせる。アソシエーション再起動や通知の欠落の後、遠隔MTP3は古い記憶を前提にする代わりに基準状態を得られる。

ただし監査結果は時刻付きの照合記録である。その直後に状態変化がなかったことを証明せず、取りこぼした全イベントを復元もしない。インシデント記録には要求と応答、時刻、Interface Identifier、アソシエーション、ASP状態、その後の通知を組み合わせたい。「監査では供用中だった」という説明が支えるのは、その時点、その観測点に限られる。

動的登録にも別の境界がある。Link Keyを認可し、Interface Identifierへ対応付けられる。登録成功はゲートウェイが制御上の対応を受け入れたという意味だ。物理リンクが健全、ASPがACTIVE、実トラフィックが流通中という証明ではない。

バックホールはMTP2のピア間置換ではない

RFC 4165はM2PAとの違いを明確にした。M2PAでは両端にMTP3があり、MTP2を置き換えるピア間プロトコルとして動く。M2UAではコントローラ側のMTP3が、境界プリミティブの転送を通じてゲートウェイにある実物のMTP2を使う。どちらもSCTPを使い得るが、リンクの所在と障害条件は異なる。

RFC 4666のM3UAやRFC 4233のIUAにも、共通のASP状態機械やメッセージ分類がある。しかし適応対象の境界は同じではない。共通ヘッダーから同じ運用上の意味を推定してはならない。

RFC 3331が引用したSCTP仕様の後にはRFC 9260がある。現在のSCTP仕様を参照できることは、個々のM2UA網が更新済みである証拠ではない。IANAがM2UAにSCTPペイロードプロトコル番号2を割り当て、MAUPやInterface Identifier Managementのメッセージクラスを維持していても、それはコードポイントの記録であり、実導入、通信量、適合性の証明ではない。

セキュリティにも境界がある。SCTPを使うだけで、ローカル識別子が物理回線を指す正当な主張に変わるわけではない。RFC 3788はSIGTRANのセキュリティ考慮事項と保護方法を扱ったが、運用者にはピア認証、許可ポリシー、適切な通信保護がなお必要である。接続できることとリンク操作の権限は別の証拠だ。

証拠は分けたまま結びつける

M2UAは物理アンカーを消さずに、かつてローカルだったインターフェースを遠隔化した。歴史的な要点はメッセージ一覧より、分散インフラの主張をどう読むかにある。

少なくとも五つの記録を残す。SCTPアソシエーションとストリーム、ASPとASの制御状態、Interface Identifierと物理資源の設定対応、物理MTP2リンク状態、そして観測や命令を運んだ境界メッセージである。誰が操作を許されたかを問うなら、認可とセキュリティの文脈も加える。これらを結んで初めて、稼働中のプロセスを特定のリンクへ正当に関連付けられる。

RFC 3331は何が残り、何が越境し、それらの間を何が名指すのかを明確にして遠隔制御を可能にした。その区別を崩すと、IP接続が電話サービスの誤った証明になる。保てば、ネットワークが物理回線を運んだふりをせず、切替と監査を説明できる。

出典