要約

  • RFC 3332は境界をMTP3の上に置いた。信号ゲートウェイがMTP2とMTP3を終端し、ルーティングキーに従ってISUPやSCCPをIP側のアプリケーションへ渡す。Routing Contextは、その選別規則を通信上で指す値だった。
  • キー登録の成功、ASPのACTIVE、SS7宛先の到達可能性は別の証拠である。RFC 3332は2006年にRFC 4666によって廃止されたため、現在仕様ではなく2002年の設計転換として読む必要がある。

物理リンクではなく「担当範囲」を渡す

RFC 3331のM2UAでは、物理SS7リンクとMTP2がゲートウェイに残り、遠隔MTP3がその境界を操作した。Interface Identifierは、線路やタイムスロットと遠隔利用者を結ぶ名前だった。RFC 3332のM3UAは切断面を一段上げた。ゲートウェイはMTP3まで終端し、遠隔側にはMTP3利用者が期待するサービスを提供した。

その結果、IP側のISUPやSCCP処理系は、特定の線路そのものではなく、自分が担当する信号集合を受け取る。ゲートウェイはSS7網に対して信号点として振る舞い、IP側に対しては配達責任者になる。どのメッセージをどのアプリケーションに渡すかという第二の経路選択が必要になった。

Routing Keyはその担当範囲を記述した。サービス情報オクテット、宛先点コード、発信点コード、回線識別範囲、SCCPサブシステム番号などを組み合わせ、あるApplication Serverが扱うトラフィックを定める。Routing Contextはキーをメッセージ内で短く示す識別値である。

ここで経路は物理的な道だけではなくなった。「この条件の信号はこのサービスに属する」という運用方針が、プロトコルで運べる対象になった。柔軟性は増したが、誤った方針も正確に実行されるようになった。

登録成功は所有権の証明ではない

キーは事前設定でき、Routing Key Managementで動的に登録することもできた。REG RSPが成功を返せば、SGPが提案を受け入れRouting Contextを割り当てたことは分かる。しかし、そのピアが対象点コードを代表する権限を持つか、別のキーと重複しないか、回線範囲が適切かは別問題である。

Network Appearanceは点コードの局所性を示す。同じ値が別のSS7網で再利用されるため、どの網の点コードかを区別する文脈が必要だった。だがNetwork Appearanceも共有されたローカル参照であり、世界的な身分証明ではない。

監査にはキーの全フィールド、Network Appearance、登録要求と応答、Routing Context、設定版、承認記録が必要である。パケット中のContext値だけでは、何を意味したかを再現できない。番号を保存して地図を捨てれば、証拠は参照先を失う。

最も発見しにくいのは、キーが広すぎる事故である。SCTPは正常に配送し、ASPも正常に処理を始める。形式上正しい信号が別の業務インスタンスへ届くだけなので、通信障害の警報は鳴らない。これは可用性の失敗ではなく、統治ルールの失敗である。

三つの状態は一つの青信号にならない

SCTP associationはIP転送の状態を表す。ASP-DOWN、ASP-INACTIVE、ASP-ACTIVEは、プロセスがApplication Serverの仕事を受けられるかを表す。Override、Loadshare、Broadcastは複数プロセスへの配分方法を決める。どれもSS7宛先そのものの到達性ではない。

宛先状態はSSNMで伝えられた。DUNAは到達不能、DAVAは到達可能、SCONは輻輳、DUPUは宛先ユーザ部の利用不能を示し、DAUDは状態を照会する。複数SGPがある場合、M3UAは各経路を保持し、それらから上位へ示す宛先状態を導く必要があった。

従ってassociationが確立し、ASPがACTIVEであり、同じキーに含まれる宛先がDUNAでも不整合ではない。転送路、処理資格、SS7経路という三つの問いに答えているからだ。統合された一個のヘルス値は、運用を簡単に見せる代わりに原因を消す。

DAVAにも限界がある。報告時点で宛先が利用可能と見えたことを示すが、ISUP呼が成立したことやSCCP取引が最終アプリケーションに完了したことは示さない。利用者プロトコルの応答、エラー、タイムアウトが第四の証拠になる。

フェイルオーバーは知識を自動複製しない

M3UAは複数ASPと複数SGPを想定し、処理停止時に交通を移せるようにした。Routing Contextが同じまま新ASPがACTIVEになっても、そのASPが最新のDUNAや輻輳情報を持つとは限らない。生き残ったassociationの先で、利用可能なSS7経路が変わっていることもある。

再開手順は「接続、ACTIVE、キュー解放」だけでは足りない。キーへの所属と承認、traffic mode、SGPごとの経路、輻輳、MTP3 restartを照合する必要がある。DAUDは現在像を取り戻す手段だが、応答後の変化まで保証しない。時刻と順序が不可欠である。

Loadshareは誤設定も拡散する。広すぎるキーを複数ASPが忠実に実行すれば、冗長性は誤配達の処理能力を上げる。ソフトウェアの復旧と経路知識の復旧は、別々に確認しなければならない。

RFCにも有効な時間範囲がある

RFC 3332は2002年9月に公開され、2006年9月のRFC 4666が明示的に置き換えた。初期文書は設計史を理解する一次資料だが、現行M3UAの要件を述べる際の最終権威ではない。文書状態も出典の一部である。

RFC 2719はSIGTRAN全体像、RFC 9260は現在のSCTP、RFC 3788は安全性、RFC 4165はM2PAとの境界比較を与える。IANA登録はメッセージクラスや識別子の割当を証明するだけで、実装、稼働、所有、適合性を証明しない。

保護されたassociationもRouting Keyの業務上の正しさを保証しない。認証済みピアが権限外の範囲を申請することも、承認済み設定が間違うこともある。本人確認、権限、選別、到達性は分けて検証する。

四枚の受領証を残す

選別の受領証はキー、Network Appearance、Context、設定由来。アプリの受領証はassociation、ASP/AS、traffic mode、活動メンバー。経路の受領証はSGP、宛先状態、SSNM、輻輳、restart。結果の受領証はISUP/SCCPの応答、エラー、期限切れである。

Routing Keyが答えるのは「誰に渡すか」であり、「届くか」でも「処理が完了したか」でもない。RFC 3332が残した重要な教訓は、経路を鍵にしたことより、鍵の成功と世界の状態を混同しないための境界を残したことにある。

出典