要約

  • RFC 3332のM3UAでは、Routing Keyが通信範囲を記述し、Routing Contextがそのキーを識別し、Network AppearanceがローカルなSS7網の文脈を区別した。三つは関連するが、同じ意味ではない。
  • 一つのASPは共有SCTPアソシエーションを通じて複数のApplication Serverを担当でき、ASP状態はASごとに管理された。したがって、トランスポートが接続中でも、対象通信が有効か、SS7宛先に到達できるか、MTP3ユーザーがメッセージを受け取ったかは分からない。

三つの名前が答える三つの問い

M3UAの用語は単なる語彙の違いに見えるかもしれない。しかしポイントコードが再利用されると、区別はルーティングそのものになる。あるSS7網で割り当てられた信号点コードが、別の網でも使われることがある。シグナリングゲートウェイが共通のアソシエーション上で両方を運ぶなら、数字だけではメッセージがどちらの網に属するのか決められない。M3UAは、網の文脈、通信を選ぶ規則、その規則を指す値を分離した。

この設計はプロトコル境界から理解できる。2002年9月に公開されたRFC 3332は、ISUPやSCCPなどのMTP3ユーザー信号をIP経由で運ぶ適応方式を定めた。遠隔のApplication Server ProcessにはMTP3ユーザーが想定するプリミティブを提供するが、M3UA自体がSS7のMTP3層になるわけではない。シグナリングゲートウェイはSS7を受信し、遠隔アプリケーションは適応層を介してユーザー部を扱う。制御面は、どのメッセージをどこへ送るかに加え、そのフィールドをどのSS7文脈で解釈するかも示す必要がある。

Application Serverは特定のRouting Keyに対応する論理サービスだ。キーは選択規則であり、処理対象となるSS7通信の範囲をパラメーター集合で定義する。たとえば宛先・発信元ポイントコードやサービス指示子が使われ、アプリケーションによってはISUP回線識別コードやSCCPサブシステム番号などのユーザー部フィールドも加わる。これは例であり、共通の必須セットではない。キーは連続しない範囲を表せるし、意味のあるフィールドは用途と網に依存する。

Routing Contextはその条件の短縮形ではない。Routing Keyを識別する値である。SGPの分配機能はキーに照らして通信を判定し、制御メッセージはContextを使って開始、停止、登録の対象となる通信集合を指す。キーは規則、Contextは規則を参照するハンドル、Application Serverはその規則が選ぶサービス、と考えるとよい。一方を他方で代用すれば、照合条件か制御操作に必要な参照のどちらかが失われる。

Network Appearanceはローカルな文脈

Network Appearanceは別の問いに答える。信号メッセージをどのSS7網の文脈で解釈するのか、である。信号点コードは網の文脈と組み合わせてはじめて信号ノードを特定できる。ゲートウェイが複数の国別・専用SS7網に接続し、ポイントコードを共有している場合には、この次元が重要になる。

一方、Network Appearanceは世界共通の網番号ではない。RFC 3332では、Signalling Gateway ProcessとApplication Server間で調整するローカル参照として設計された。RFC 3332を置き換えた2006年のRFC 4666は、同じ実ネットワークがSGPごとに異なる値で表され得ると明確にしている。対応表なしにゲートウェイ間の整数を比較して、同じ網を示すとみなすことはできない。

単一網だけを提供するゲートウェイや、単一の網文脈に限定したアソシエーションでは、このフィールドを省略できる場合がある。省略は構成されたトポロジーの性質であって、すべての網が一つだという証拠ではない。同様に、制限された単一キー構成ではRouting Contextが暗黙となり、各メッセージに載せなくてもよい。値が一意に決まる場合に省略を許す仕様であって、その理由を知るには構成記録が必要だ。

一つのアソシエーション、複数のAS状態

フェイルオーバーでは、この区別が運用上重要になる。ASPはプロセスの実体であり、サービス定義そのものではない。一つのASPが複数のApplication Serverに設定され、単一のSCTPアソシエーションがそれらに関係する通信を運ぶこともある。RFC 3332はASPの状態をASごとに管理する。ACTIVEはソケットやマシン全体の属性ではなく、特定のアプリケーションサービスにおけるプロセスの通信状態だ。

Overrideでは一つのASPを選び、他を待機系にできる。Loadshareは活動中の複数プロセスに通信を分配し、Broadcastは対象となる活動プロセスすべてに送る。どの方式が適するかはアプリケーション次第である。SGPが受信先を選ぶには、状態遷移、Routing Context、構成されたキーを結びつけなければならない。ASやContextを示さない「ASPはACTIVE」は不完全であり、「SCTP接続あり」から分かることはさらに少ない。

遠隔ユーザーに届く前にも検証層がある。M3UAはDATAとともに、宛先の到達不能、到達可能、制限、輻輳などの通知を運べる。トランスポートの接続状態が示すのは端点間の通信可能性だけだ。ポイントコードとNetwork Appearanceの組が正しく解釈されたか、認可されたRouting Keyに一致したか、該当ASでASPがACTIVEだったか、遠隔ISUP/SCCP処理が完了したかは、各層の記録で確かめる必要がある。

2002年のRFCと2006年の後継

歴史的な対象はRFC 3332であり、現在の規範文書だという意味ではない。2006年9月、RFC 4666がこれを置き換えた。改訂版でも中心的な区別は維持された。Routing Keyは通信選択、Routing Contextはキーの識別、Network AppearanceはローカルなSS7網の文脈を担う。現在の仕様を理解するには後継文書を読み、設計史を追うには旧版と比べればよい。

現在のIANA SCTPパラメーター表はM3UAのPayload Protocol Identifier 3をRFC 4666とともに記載する。サービス名・ポート表にはSCTP 2905番のm3uaがある。これは割り当てを示すだけで、事業者の導入、実装の適合性、特定のアソシエーション上での通話を証明しない。RFC 9260が現在のSCTP仕様であることも、既存M3UA設備がそれを採用している根拠にはならない。

RFC 3331のM2UAは隣接するが異なる境界を扱う。M2UAではMTP2ユーザーの境界を運び、物理回線はゲートウェイ側に残る。M3UAが運ぶのはMTP3ユーザー信号で、ISUPやSCCPを含み得る。RFC 4233のIUAとRFC 4165のM2PAにもそれぞれ異なる適応境界がある。SIGTRANの系譜やSCTPの共用だけでは、名前や状態モデルを同一視できない。

運用上は四つの問いを分ける。どのSS7パラメーターが通信を選んだか。どのRouting Contextが選択を示したか。このSGP/ASPの組でポイントコードの意味を定めたローカルNetwork Appearanceは何か。どのAS別ASP状態が配信を許したか。その確認後にSCTPアソシエーションを伝送経路として結びつける。RFC 3332の要点は、規則、規則のハンドル、網の領域、メッセージを運ぶ線を同じものとして扱わないことだ。

出典