要約

  • TGREP は、ドメイン内のゲートウェイから Location Server へ電話経路を登録するためのプロトコルである。
  • ゲートウェイは Send Only であり、他の経路を学習せず、呼ごとの経路選択も実行しない。
  • 広告元データベースの生成方法は規格外で、手動設定の場合もある。
  • TotalCircuitCapacity は管理上の上限であり、次の呼に確保された資源ではない。
  • AvailableCircuits は変動するローカル観測値で、peer LS より先へ伝播してはならない。
  • 更新負荷を抑える時間窓は、値を安定させる一方で現在との差を作る。
  • CallSuccess は過去の成功数と試行数を同じ窓で数える。
  • Alerting まで到達して相手が話中でも、規格上の慣例では成功に含み得る。
  • 切断原因を成功・失敗へ写像する詳細は、報告するゲートウェイの裁量である。
  • consolidation は同一宛先の複数経路を結合し、aggregation は異なる宛先を要約する。
  • IPsec が保証するのは peer 間の保護であり、容量や将来の呼結果の真実性ではない。
  • 登録、鮮度、変換、選択、信号交換、PSTN の処理、業務結果には別々の証跡が必要である。

「現在空いている」は予約ではない

あるゲートウェイが、対象プレフィックスへ到達でき、回線も残っていると UPDATE した。直後にプロキシがその経路を選ぶ。画面だけを見れば、選択は当然に見える。

しかし、その間に別の呼が回線を消費できる。広告値は予約票ではない。RFC 5140 は AvailableCircuits が呼ごとに変化し得ることを認め、更新負荷を減らす措置と十分に大きな時間窓を推奨する。これは拡張性のための正当な設計だが、値が意思決定時刻そのものを観測していない可能性も意味する。

運用画面が数値だけを表示し、観測時刻、時間窓、更新条件、到着呼数を隠せば、平滑化された証拠が即時在庫に見える。期限を過ぎた値を使うなら、選択ポリシーは「未知」を扱わなければならない。古い 10 は新しい 0 より大きいのではなく、比較不能かもしれない。

二つの容量は別の時計を持つ

TotalCircuitCapacity は管理的にプロビジョニングされた総回線数を表す。比較的静的で、保守のため trunk を停止したときなどに変わる。同じ ITAD 内で同一プレフィックスへの経路を集約する場合、各値を加算でき、受信 LS の外へ伝播することもできる。

これに対し AvailableCircuits は、ある時点で残っている回線数である。ゲートウェイとそれを管理する peer LS の間だけで使い、aggregation の対象にはならず、経路に付けて伝播してはならない。

一方は構成された上限、もう一方は局所的な観測である。二つを同じ鮮度の「容量」として並べると、広域に残る静的値が、失われた動的状態の代わりをしてしまう。総量の和も、全回線が同じ条件、方針、障害領域で交換可能だとは証明しない。

成功率の中にはゲートウェイの判断が入る

CallSuccess は、ある宛先について同じ時間窓内の成功数と試行数を運ぶ。試行が増えれば統計的な意味が高まり得る。試行カウンターが周回すれば成功カウンターも整合のためリセットされ、受信側は意味を失わない頻度で取得する必要がある。

重要なのは、成功の分子が観測だけでなく分類でもある点だ。RFC 5140 は、Alerting に達した後、相手が不在または話中で接続しなかった呼を慣例上成功とみなす例を示す。回線や資源不足による切断は失敗とみなす。正確な切断原因の写像は報告ゲートウェイに委ねられる。

この自由は現場に必要だが、比較には契約が要る。ある実装の成功は「宛先網まで届いた」、別の業務指標の成功は「会話が成立した」かもしれない。写像表、窓、分母、カウンター世代、トラフィック構成がなければ、92% と 88% の大小に共通の意味はない。

規格が約束するのは、代替経路から成功確率を高めるために使えることだけである。CallSuccess は集約も伝播もされず、次の一呼を保証しない。

送信者は経路を選ばない

TGREP は TRIP の域内注入とゲートウェイ選択の空白を埋める。ゲートウェイ上の sender は Ingress LS と peer になり、到達性を送る。受信側はそれを Egress LS に渡し、TRIP の域内・域間処理へ進められる。

OPEN では Send Receive Capability を Send Only にする。ゲートウェイには TRIP の Adj-TRIBs-In や Loc-TRIB に相当するデータベースがなく、他者の経路を学ばない。Established 中に UPDATE を受け取っても黙って破棄し、状態を維持する。

したがって Established は、通信路が成立している証拠にはなっても、ゲートウェイが LS の判断を取り込んだ証拠にはならない。peer ごとの Adj-TRIB-GW-Out をどう作るかも規格外で、手動設定の可能性が明記される。署名された UPDATE より前に、構成の出所、権限範囲、変更者、期限、撤回条件を記録する必要がある。

受信側の結合は新しい主張を作る

一つの宛先に複数ゲートウェイから経路が届くと、TGREP receiver は consolidation を行える。RFC の例では、二つの Carrier 値を和集合にし、別の例では複数更新のプレフィックス集合を結合する。同じ宛先について集合的能力を失わないための操作である。

ただし、属性や address family ごとの具体的処理は実装に残される。その後の aggregation は別操作で、異なる宛先を一つの要約へまとめ、情報量を減らす。順番は consolidation が先、aggregation が後である。

下流の候補経路は、単一ゲートウェイが発した原文ではなく、受信側が作った投影になり得る。投影自体は悪くない。構成ゲートウェイ、peer セッション、元経路、各属性、時刻、結合規則、除外値、実装版を逆引きできないことが問題になる。和集合を一者の同時保証に読み替えてはならない。

E.164 や routing-number のプレフィックス、TrunkGroup、Carrier は選択対象を構造化する。セッションはプレフィックス系、TrunkGroup、Carrier の三分類を混在させない。RFC 4904 と RFC 4694 も関連する表現を整える。それでも構文の正しさは、Carrier を代表する権限、trunk の現在制御、回線の実在を証明しない。

保護された bytes の先に現実がある

RFC 5140 は TRIP の IPsec セキュリティを再掲する。AH または ESP は送信元認証、完全性、リプレイ防止を提供し、ESP は機密性も提供できる。これは peer 間のメッセージを保護する。

手動設定した到達性の正しさ、動的値の鮮度、成功分類の妥当性、送信者の商業的権限、PSTN での結末は保護対象外である。暗号は「どの security association から bytes が来たか」を答える。運用は「何を観測し、誰が変換し、何に基づいて選び、何が起きたか」を別に答える。

必要な鎖は、ゲートウェイの身元と広告権限、原 UPDATE、観測と発行時刻、窓とカウンター世代、原因写像、受信側の検証と変換、プロキシのポリシーと代替案、シグナリング応答、PSTN 処理、そして主張したい業務結果である。

TGREP は判断の入口を改善する。出口の事実まで先取りはしない。

出典

  1. RFC 5140 HTML
  2. RFC 5140 テキスト
  3. RFC Editor レコード
  4. IETF Datatracker
  5. 文書履歴
  6. RFC 5140 errata 検索
  7. IANA TRIP parameters
  8. RFC 2871：Telephony Routing Framework
  9. RFC 3219：TRIP
  10. RFC 3261：SIP
  11. RFC 4904：tel/SIP URI の Trunk Group
  12. RFC 4694：Number Portability Parameters
  13. RFC 4301：IPsec Architecture
  14. RFC 4302：AH
  15. RFC 4303：ESP
  16. RFC 4306：IKEv2
  17. RFC 4835：ESP/AH Algorithm Requirements
  18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  20. Running-Code Primacy