要約

  • 更新応答を待つPendingUでは、RETRY_AND_TERMINATEを選んでいてもTx満了時にサービスを許可し、待機状態を維持する。その後の送信失敗や一時エラーでは終了する。
  • 実際に適用される規則はローカル設定を上書きしうる。既存セッションの制御先を切り替えるには、代替サーバーへの到達性だけでなく、切り替えの許可と状態管理が必要になる。

「応答が間に合わなければ停止する」。障害時の規則をそう説明したくなる場面は多い。だがDiameterのクレジット制御では、どの待ち時間が終わったのかを省くと、動作の説明を誤る。アプリケーションのタイマーが満了しても、要求の結果がまだ確定していないことがある。その間もサービスは提供されうる。

対象は限定される。すでに確立したセッションについて、クライアントが更新要求を送り、PendingUで答えを待っている場合だ。RFC8506の第7節、表4では、RETRY_AND_TERMINATEの下でTxが満了すると、サービスを許可してPendingUにとどまる。一方、その後に送信失敗または規定された一時エラーが生じれば、サービスを終了してIdleへ移る。第5.7節の障害処理手順も、この時間順序を理解する手掛かりになる。

これは特定の事業者で確認された障害ではない。仕様から読み取れる挙動である。それでも管理上の意味はある。制御側では「未決」の要求でも、提供されたサービスの利用はすでに起きているからだ。

待機の終了と要求の結末を分ける

セッション単位のクレジット制御では、利用可能な単位を予約し、途中で更新し、最後に使用量を報告する。単位は金額とは限らず、時間、データ量、サービスの数量でもよい。第5.3節は、割り当ての消費、有効期間の満了、関連条件の変化などに応じた途中の問い合わせを扱う。中断を避けるために早めに要求を出すこともできる。

したがって、応答待ちのサービス許可を、クライアントが無制限の新しい割り当てを作ったと理解してはいけない。使用済み単位の報告と、新たな付与単位の受領には関係がある。次の答えが来るまで何を許すかは、その交換の途中に置かれた規則だ。

PendingUでTxが満了した後でも、更新への成功応答が届けば、Txを停止してOpenに戻る。これに対し、送信失敗は、目的の宛先および該当する代替先と通信できない場合や、要求が最終的にタイムアウトする場合などを含む。「一時エラー」も単に返事が遅いという意味ではなく、プロトコルが区別する通知の種類である。

これらを一つの「タイムアウト」にまとめれば、RETRY_AND_TERMINATEが最初はサービスを許し、後には終了させる理由が消えてしまう。観測項目を減らしたつもりで、実際には判断に必要な区別を落とすことになる。

第13節が推奨するTxは10秒だ。ただし、個々のネットワークがその値を設定しているとは言えず、暫定的なサービス提供が必ず10秒以内に収まる保証でもない。単位の有効期間を扱うValidity-Timeと、サーバー側のセッション監視用タイマーも別の役割を持つ。仕様中の一つの数値を、そのまま経営上の許容限度に読み替えることはできない。

継続を認める規則にも境界がある

第8.14節に定義されるCCFHの値は、TERMINATE、CONTINUE、RETRY_AND_TERMINATEの三つである。属性がなければTERMINATEが既定値となる。PendingUでTxが満了すると、TERMINATEはサービスを終了する。残る二つはこの時点ではサービスを許すが、後の送信失敗や一時エラーでは分かれる。CONTINUEは許可を続け、RETRY_AND_TERMINATEは終了する。代替先への再試行は、切り替えのサポートと利用できる代替先があることにも左右される。

ただし、明示的な拒否まで無視できるわけではない。表4のEND_USER_SERVICE_DENIEDは、CCFHの値にかかわらずサービス終了を求める。また、AA-Requestと組み合わされた最初の問い合わせには別の状態機械があり、Tx満了時には切断する。更新待ちの表を、すべての初回接続に適用してはならない。

RFC8506が対象とするのはクレジットの認可であり、サービス固有の認証と認可は対象外だ。継続ポリシーを、利用者の認証を省略する包括的な許可として説明するのは誤りになる。

規則の出所にも注意が要る。第5.7節によれば、ホームAAAサーバーから受けた値はローカル設定より優先し、クレジット制御サーバーの応答に含まれる値は、それまでの値を上書きする。ある遷移を検証するなら、その瞬間の実効値と由来が必要だ。ローカルの既定値だけを示しても、なぜサービスが続いたかの説明にはならない。

引き継ぐのは通信先だけではない

サービスを暫定的に維持することと、確立済みセッションのクレジット制御を別サーバーへ移すことは、別の判断である。第5.7節と第8.4節ではCC-Session-Failoverが後者を規定する。属性がなければFAILOVER_NOT_SUPPORTEDとなり、そのセッションの制御メッセージ列を代替サーバーへ移してはならない。新規セッションで予備のサーバーを選ぶ場合とは異なる。

伝送経路上のピア切り替えも区別が必要だ。それによって重複要求が発生することはありうるが、状態を伴うセッション移行が許可されたことにはならない。

セッションの切り替えをサポートする場合、RFCは主系と副系の間でセッションおよびアカウントの状態を移すことを推奨し、重複や順序違いのメッセージを正しく検出することを要求する。サーバー間の状態転送そのものの方式は実装に委ねられている。Session-IdとCC-Request-Numberが要求を識別していても、予約状態が正しく複製された証明にはならない。予備の宛先に接続できる、という試験だけでは足りない理由がここにある。

利用量の記録も残る。第5.7節は予備のアカウンティング経路を推奨し、CONTINUEとDELIVER_AND_GRANTを組み合わせる例では、利用情報の収集とクレジット制御サーバーとの交換を条件としている。継続は無料、未計測、あるいは確定した損失を意味しない。第5.4節の最終問い合わせも、使用量を報告し未使用の予約を精算する役割を持つ。逆に、サーバーの予約解放だけでは、クライアント側で提供が止まったとは証明できない。

仕様と現場の証拠を混ぜない

公式の書誌情報では、RFC8506は2019年3月のProposed Standardで、RFC4006を置き換える。正誤表の検索は2026年9月8日の確認時点で該当項目を返さなかった。これは製品の適合性、導入規模、障害頻度の証拠ではない。本稿には実際の利用者数や損失額を算出する資料はない。

Lu Hengが述べる「主張の擁護ではなく現実を届ける」という編集方針に沿えば、まず遷移の仕組みを説明すべきだ。インターネット統治の代理問題を論じた文章は、決定する人と結果を負う人を問う視点を与える。ただし、あるDiameter運用組織の動機を立証するものではない。ここで確認できる核心は、未決の制御要求と実際のサービス消費が同時に存在しうる、という点である。