要約
- RFC 3057はISDNのDチャネル終端とQ.931の呼処理場所を分けた。シグナリングゲートウェイがQ.921を終端し、IUAがSCTP経由で境界プリミティブをアプリケーションサーバーへ中継する。
- ASPの切替でシグナリング経路は変えられるが、トランスポートの復旧は呼状態の復元ではない。RFC 3057を置き換えたRFC 4233は、IUAの範囲外で状態を共有しなければ、遷移中の呼が失敗し得ると明記した。
動かしたのは上位層で、回線ではない
従来のISDN構成では、Dチャネルが回線交換呼の設定・管理に必要なシグナリングを運ぶ。Q.921がデータリンク機能を提供し、Q.931やQSIGなどの上位プロトコルがそのサービスを利用する。2001年2月のRFC 3057は、このプロトコル境界を使って機能の配置を分けた。
シグナリングゲートウェイ(SG)は標準ISDNインターフェースから信号を受け、Q.921を終端する。IP側のメディアゲートウェイコントローラー(MGC)には、対向するQ.931層と呼処理を置く。その間でISDN Q.921ユーザー適応層、すなわちIUAが、境界プリミティブをSCTPで運ぶ。加入者回線やDチャネル、個々の回路をIPオブジェクトへ変換したのではない。物理インターフェースとローカルなQ.921動作はSGに残った。
この違いは運用に直結する。DL-DATAプリミティブはQ.931メッセージを運び、確立、解放、非確認データはそれぞれ異なるリンク結果を表す。IUAにはインターフェースの識別とプリミティブの意味を保つ必要があった。遠隔のコントローラーは呼シグナリングを処理できても、Dチャネル自体を引き継いだわけではない。
インターフェース識別子はローカルな対応付け
Interface IdentifierはメッセージをSG上の物理インターフェースに結び付ける。整数またはテキストで表せるが、その意味はローカルに限られる。SGとアプリケーションサーバーが値を調整するのであり、別のゲートウェイでも通用する名前ではない。ネットワーク全体の識別子に見えても、実態はシグナリング文脈を結ぶローカルなキーだった。
SGはこの識別子をアプリケーションサーバーと活動中のアプリケーションサーバープロセス(ASP)へ対応付ける。アプリケーションサーバーは単一マシンではなく、主系や待機系など複数ASPを順序付けた論理サービスでもよい。SGは各インターフェースのトラフィックをどのプロセスへ渡すかを把握しなければならず、その割当は切替時に変わり得る。
RFC 3057はSCTPの利用と、Dチャネルごとに別のSCTPストリームを使うことを推奨した。独立したチャネル間の滞留やバッファ遅延を減らすためだ。ストリームはトランスポートの仕組みであり、メッセージがどの物理インターフェースに属するかは識別子が示す。アソシエーションの状態、ストリーム内の順序、ローカルな対応付け、ASPの活動状態は関係していても、相互に代替できない。
プロセスの切替は呼の履歴を複製しない
冗長性の構成は運用者が選べた。1+0には予備ASPがない。1+1のアクティブ/待機構成では、一方がトラフィックを処理し、もう一方が引き継げる。一般化したn+kモデルでは、n個のプロセスが必要な負荷を受け持ち、k個を障害時の予備にする。IUAメッセージはSGとASP間の状態交換やシグナリングの振り分けを助ける。
しかし、待機側とのアソシエーションが生きていても、設定途中の呼状態を把握しているとは限らない。2006年にRFC 3057を置き換えたRFC 4233は、その点を明確にした。通信事業者級ネットワークではASP障害で安定した呼を切断すべきではなく、それにはASP間で呼状態を共有する必要がある場合もある。一方、切替中の呼は失敗し得る。共有メモリーやASP間プロトコルで軽減できるが、後者はIUAの対象外だった。
これはSCTPの隠れた欠陥ではない。SCTPはアソシエーションの状態を伝え、各ストリーム内でメッセージを順序付け、マルチホーミングも支援する。だが、どの呼判断が済んだのか、相手にどのメッセージが届いたのか、呼が安定状態か遷移中かまでは、代替コントローラーに教えない。IUAはシグナリング経路を切り替えられる。アプリケーションの継続性は別の責務として残る。
標準が変えたこと、証明しなかったこと
RFC 3057はSIGTRANアーキテクチャにQ.921ユーザー向けの適応層を定義し、回線交換網との標準境界を残したまま、IPバックホール上で分散した呼処理を可能にした。2006年のRFC 4233がこれを置き換え、同じ適応方式を洗練した。この文書の変遷から、どの事業者が導入したか、何を購入したか、実際の障害で何通の呼が保たれたかは分からない。
工学上の教訓は「電話がIPへ移った」という大づかみな話ではない。物理インターフェースを別の場所に残したまま、サービス境界だけを移すことはできる。リンク終端、プリミティブ適応、トランスポートアソシエーション、受信プロセス、呼を一貫した状態に保つアプリケーション状態は、それぞれ別の証拠で確認すべきだ。SCTPアソシエーションの復旧やASPのActive状態は、呼完了の証明にはならない。
出典
- RFC 3057 — ISDN Q.921-User Adaptation Layer
- RFC Editor — RFC 3057 情報ページ
- RFC 4233 — ISDN Q.921-User Adaptation Layer(RFC 3057を置換)
- RFC 2719 — Framework Architecture for Signaling Transport
- RFC 4960 — Stream Control Transmission Protocol
- RFC 9260 — Stream Control Transmission Protocol
- RFC 4666 — MTP3 User Adaptation Layer
- RFC 4166 — Telephony Signalling Transport over SCTP: Applicability Statement
- IANA サービス名・トランスポートプロトコルポート番号レジストリ
- Datatracker — RFC 3057
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
