2. プロトコル概要

基本的な Diameter プロトコルは、ピアとの接続の確立、能力交渉、メッセージがピアを通じてどのように送信およびルーティングされるか、そして最終的に接続がどのように切断されるかに関係しています。基本プロトコルはまた、Diameter ノード間のすべてのメッセージ交換に適用される特定のルールを定義します。

Diameter ピア間の通信は、あるピアが別の Diameter ピアにメッセージを送信することから始まります。メッセージに含まれる AVP のセットは、特定の Diameter アプリケーションによって決定されます。ユーザーのセッションを参照するために含まれる AVP の 1 つは Session-Id です。

ユーザーの認証および/または認可の初期リクエストには、Session-Id AVP が含まれます。Session-Id は、ユーザーのセッションを識別するために、その後のすべてのメッセージで使用されます（詳細についてはセクション 8 を参照してください）。通信相手は、リクエストを受け入れるか、Result-Code AVP をエラーが発生したことを示すように設定した応答メッセージを返すことで拒否することができます。リクエストを受信した Diameter サーバーまたはクライアントの具体的な動作は、使用される Diameter アプリケーションに依存します。

セッション状態（Session-Id に関連付けられている）は、Session-Termination-Request、Session-Termination-Answer の受信時、Session-Timeout AVP で認可されたサービス時間の期限切れ時、および特定の Diameter アプリケーションで確立されたルールに従って解放する必要があります。

基本的な Diameter プロトコルは、それ自体で課金アプリケーションに使用できます。認証と認可については、常に特定のアプリケーション用に拡張されます。

Diameter クライアントは、課金を含む基本プロトコルをサポートする必要があります。さらに、ネットワークアクセスサーバー要件（NASREQ）[RFC2881] および/または Mobile IPv4 など、クライアントのサービスを実装するために必要な各 Diameter アプリケーションを完全にサポートする必要があります。Diameter クライアントは、「Diameter クライアント」ではなく、サポートするアプリケーションを表す「Diameter X クライアント」と呼ばれる必要があります。

Diameter サーバーは、課金を含む基本プロトコルをサポートする必要があります。さらに、NASREQ および/または Mobile IPv4 など、意図されたサービスを実装するために必要な各 Diameter アプリケーションを完全にサポートする必要があります。Diameter サーバーは、「Diameter サーバー」ではなく、サポートするアプリケーションを表す「Diameter X サーバー」と呼ばれる必要があります。

Diameter リレーおよびリダイレクトエージェントは Diameter アプリケーションに対して透過的ですが、課金を含む Diameter 基本プロトコルとすべての Diameter アプリケーションをサポートする必要があります。

Diameter プロキシは、課金を含む基本プロトコルをサポートする必要があります。さらに、NASREQ および/または Mobile IPv4 など、プロキシされるサービスを実装するために必要な各 Diameter アプリケーションを完全にサポートする必要があります。Diameter プロキシは、「Diameter プロキシ」ではなく、サポートするアプリケーションを表す「Diameter X プロキシ」と呼ばれる必要があります。

2.1. トランスポート

Diameter トランスポートプロファイルは [RFC3539] で定義されています。

基本的な Diameter プロトコルは、TCP [RFC0793] と SCTP [RFC4960] の両方でポート 3868 で実行されます。TLS [RFC5246] およびデータグラムトランスポート層セキュリティ（DTLS）[RFC6347] の場合、メッセージ交換の前に接続を開始する Diameter ノードは、ポート 5658 で実行する必要があります。TLS を使用する場合は TCP 上で、DTLS を使用する場合は SCTP 上で実行されることが想定されています。

Diameter ピアがポート 5658 で TLS/TCP および DTLS/SCTP 接続の受信をサポートしていない場合（つまり、ピアが RFC 3588 にのみ準拠している場合）、開始側はポート 3868 で TCP または SCTP を使用することに戻すことができます。このスキームは下位互換性の目的でのみ保持されており、初期の CER/CEA メッセージが保護されずに送信される場合、固有のセキュリティ脆弱性があることに注意してください（セクション 5.6 を参照）。

Diameter クライアントは TCP または SCTP をサポートする必要があります。エージェントとサーバーは両方をサポートすべきです。

Diameter ノードは、着信接続を受け入れると宣言するポート以外のソースポートから接続を開始することができますが、TCP または SCTP の場合はポート 3868 で、TLS/TCP および DTLS/SCTP 接続の場合はポート 5658 で接続を受信する準備を常にしておく必要があります。DNS ベースのピア検出（セクション 5.2）が使用される場合、SRV レコードから受信したポート番号がデフォルトポート（3868 および 5658）よりも優先されます。

ピア状態マシンの特定の Diameter インスタンスは、特定のピアと通信するために複数のトランスポート接続を使用してはなりません。ただし、ピアに複数のインスタンスが存在する場合は、プロセスごとに個別の接続が許可されます。

ピアとのトランスポート接続が存在しない場合、定期的に接続を試みる必要があります。この動作は Tc タイマーによって処理されます（詳細についてはセクション 12 を参照）。推奨値は 30 秒です。この規則には、ピアが通信を希望しないことを示してトランスポート接続を終了した場合などの特定の例外があります。

ピアに接続する際、ゼロまたはそれ以上のトランスポートが指定されている場合、まず TLS を試し、次に DTLS、次に TCP、最後に SCTP を試すべきです。ピア検出の詳細については、セクション 5.2 を参照してください。

Diameter 実装は、セキュリティポリシーに従って、ICMP プロトコルポート到達不能メッセージをサーバーが到達不能であることの明示的な指示として解釈できる必要があります。ICMP エラーの処理に関する詳細なガイダンスは、[RFC5927] および [RFC5461] に記載されています。Diameter 実装はまた、トランスポートからのリセットとタイムアウトした接続試行を解釈できる必要があります。Diameter が下位層から受信したデータがピアによって作成された Diameter エラーとして解析または識別できない場合、ストリームは危険にさらされており、回復できません。トランスポート接続は、RESET 呼び出し（TCP RST ビットを送信）または SCTP ABORT メッセージを使用して閉じる必要があります（正常なクローズが危険にさらされています）。

2.1.1. SCTP ガイドライン

Diameter メッセージは、ヘッドオブライン（HOL）ブロッキングを回避する方法で SCTP ストリームにマッピングする必要があります。この要件を満たすマッピングを実行するさまざまな方法の中で、Diameter ノードが順序なしフラグを設定してストリームゼロ上ですべての Diameter メッセージ（リクエストまたはレスポンス）を送信することが推奨されます。ただし、Diameter ノードは、順序なしフラグをクリアした複数のストリームを使用するなど、HOL ブロッキングを回避するための他の設計代替案を選択して実装することができます（RFC 3588 で最初に指示されたように）。受信側では、Diameter エンティティは任意のストリーム上で Diameter メッセージを受信する準備をしておく必要があり、異なるストリーム上で応答を返すことができます。このように、両側は、特定の Diameter メッセージを送信するために相手側が選択したストリームとは独立して、送信方向で利用可能なストリームを管理します。これらのメッセージは順序が異なる可能性があり、異なる Diameter セッションに属する可能性があります。

接続の確立と終了の間、順序なし配信には特別な懸念があります。接続が確立されると、レスポンダ側は CEA メッセージを送信し、セクション 5.6 で指定されているように R-Open 状態に移行します。CEA の直後にアプリケーションメッセージが送信され、順序なしで配信される場合、まだ Wait-I-CEA 状態にある開始側はアプリケーションメッセージを破棄し、接続を閉じます。この競合状態を回避するために、受信側は、開始側から最初のメッセージを受信し、I-Open 状態に移行したことを証明するまで、順序なし配信方法を使用すべきではありません。このようなメッセージをトリガーするために、受信側は CEA を送信した直後に DWR を送信できます。対応する DWA を受信すると、受信側は HOL ブロッキングに対処するために順序なし配信方法の使用を開始すべきです。

DPR および DPA メッセージが使用される場合、別の競合状態が発生する可能性があります。DPR と DPA はどちらもサイズが小さいため、順序なし配信メカニズムが使用される場合、アプリケーションメッセージよりも速くピアに配信される可能性があります。したがって、アプリケーションメッセージがまだ転送中である間に DPR/DPA 交換が完了し、これらのメッセージが失われる可能性があります。実装は、たとえばタイマーを使用してこの競合状態を軽減し、トランスポート接続を切断する前に保留中のアプリケーションレベルメッセージが到着するまで短時間待つことができます。最終的に、失われたメッセージはセクション 5.5.4 で説明されている再送信メカニズムによって処理されます。

Diameter エージェントは、未指定のペイロードプロトコル識別子（値 0）のみを使用するのではなく、クリアテキストおよび暗号化された SCTP DATA チャンクに専用のペイロードプロトコル識別子（PPID）を使用する必要があります。この目的のために、2 つの PPID 値が割り当てられます。PPID 値 46 はクリアテキスト SCTP DATA チャンク内の Diameter メッセージ用で、PPID 値 47 は保護された DTLS/SCTP DATA チャンク内の Diameter メッセージ用です。

2.2. Diameter メッセージの保護

Diameter ピア間の接続は、TLS/TCP および DTLS/SCTP によって保護される必要があります。すべての Diameter 基本プロトコル実装は、TLS/TCP および DTLS/SCTP の使用をサポートする必要があります。必要に応じて、IPsec [RFC4301] など、Diameter から独立した代替セキュリティメカニズムをデプロイして、ピア間の接続を保護できます。Diameter プロトコルは、TLS、DTLS、または IPsec のいずれかなしで使用してはなりません。

2.3. Diameter アプリケーション準拠

アプリケーション ID は、能力交換フェーズ中にアドバタイズされます（セクション 5.3 を参照）。アプリケーションのサポートをアドバタイズすることは、送信者がそれぞれの Diameter アプリケーション仕様で指定された機能をサポートすることを意味します。

実装は、M ビットがクリアされた任意のオプション AVP（ベンダー固有の AVP を含む）をアプリケーションで定義されたコマンドに追加できますが、コマンドの CCF 構文仕様がそれを許可している場合に限ります。詳細については、セクション 11.1.1 を参照してください。

2.4. アプリケーション識別子

各 Diameter アプリケーションには、IANA 割り当てのアプリケーション ID が必要です。基本プロトコルは、そのサポートが必須であるため、アプリケーション ID を必要としません。能力交換中に、Diameter ノードはローカルでサポートされているアプリケーションをピアに通知します。さらに、すべての Diameter メッセージにはアプリケーション ID が含まれており、メッセージ転送プロセスで使用されます。

次のアプリケーション ID 値が定義されています。

Diameter common message       0
Diameter base accounting      3
Relay                         0xffffffff

リレーおよびリダイレクトエージェントはリレーアプリケーション ID をアドバタイズする必要があり、他のすべての Diameter ノードはローカルでサポートされているアプリケーションをアドバタイズする必要があります。リレーサービスをアドバタイズする能力交換メッセージの受信者は、送信者がすべての現在および将来のアプリケーションをサポートすると想定する必要があります。

Diameter リレーおよびプロキシエージェントは、特定のメッセージのアプリケーションをサポートする上流サーバーを見つける責任があります。見つからない場合、Result-Code AVP が DIAMETER_UNABLE_TO_DELIVER に設定されたエラーメッセージが返されます。

2.5. 接続とセッション

このセクションでは、本文書全体で広く使用される用語である「接続」と「セッション」の違いを読者に理解してもらうことを試みます。

接続とは、Diameter メッセージの送受信に使用される 2 つのピア間のトランスポートレベルの接続を指します。セッションは、Diameter クライアントと Diameter サーバー間に存在するアプリケーション層の論理的な概念であり、Session-Id AVP を介して識別されます。

          +--------+          +-------+          +--------+
          | Client |          | Relay |          | Server |
          +--------+          +-------+          +--------+
                   <---------->       <---------->
                ピア接続 A         ピア接続 B

                   <----------------------------->
                         ユーザーセッション x

             図 1：Diameter 接続とセッション

図 1 に示された例では、ピア接続 A はクライアントとリレーの間に確立されています。ピア接続 B はリレーとサーバーの間に確立されています。ユーザーセッション X は、クライアントからリレーを経由してサーバーにまたがっています。サービスの各「ユーザー」は、一意のセッション識別子を持つ認証リクエストが送信されます。サーバーによって受け入れられると、クライアントとサーバーの両方がセッションを認識します。

接続とセッションの間に関係はなく、複数のセッションの Diameter メッセージがすべて単一の接続を通じて多重化されることに注意することが重要です。また、ASR/ASA、RAR/RAA、STR/STA など、アプリケーション固有のメッセージと本文書で定義されているメッセージを含む、セッションに関連する Diameter メッセージは、アプリケーションのアプリケーション ID を持つ必要があることに注意してください。CER/CEA、DWR/DWA、DPR/DPA などのピア接続の確立と維持に関連する Diameter メッセージは、アプリケーション ID ゼロ（0）を持つ必要があります。

2.6. ピアテーブル

Diameter ピアテーブルはメッセージ転送で使用され、ルーティングテーブルによって参照されます。ピアテーブルエントリには次のフィールドが含まれます。

ホスト識別子

セクション 4.3.1 で説明されている DiameterIdentity 派生の AVP データ形式の規則に従って、このフィールドには CER または CEA メッセージで見つかった Origin-Host（セクション 6.3）AVP の内容が含まれます。

StatusT

これはピアエントリの状態であり、セクション 5.6 にリストされている値のいずれかと一致する必要があります。

静的または動的

ピアエントリが静的に構成されたか、動的に検出されたかを指定します。

有効期限

動的に検出されたピアテーブルエントリが更新または期限切れになる時刻を指定します。Diameter セキュリティに公開鍵証明書が使用される場合（たとえば、TLS を使用する場合）、この値は関連する証明書の有効期限を超えてはなりません。

TLS/TCP および DTLS/SCTP 有効

ピアとの通信時に TLS/TCP および DTLS/SCTP を使用するかどうかを指定します。

必要に応じて追加のセキュリティ情報（たとえば、キー、証明書）。

2.7. ルーティングテーブル

すべてのレルムベースのルーティングルックアップは、一般にルーティングテーブルとして知られているものに対して実行されます（セクション 12 を参照）。各ルーティングテーブルエントリには、次のフィールドが含まれます。

レルム名

これは、ルーティングテーブルルックアップで主キーとして使用する必要があるフィールドです。一部の実装では、正確な一致を要求するのではなく、レルムの右側から最長一致に基づいてルックアップを実行することに注意してください。

アプリケーション識別子

アプリケーションはアプリケーション ID によって識別されます。ルートエントリは、メッセージヘッダーのアプリケーション ID に基づいて異なる宛先を持つことができます。このフィールドは、ルーティングテーブルルックアップでセカンダリキーフィールドとして使用する必要があります。

ローカルアクション

ローカルアクションフィールドは、メッセージの処理方法を識別するために使用されます。次のアクションがサポートされています。

LOCAL - ローカルで満たすことができ、別の Diameter エンティティにルーティングする必要がない Diameter メッセージ。
RELAY - このカテゴリに該当するすべての Diameter メッセージは、以下に説明する識別子によって示される次ホップ Diameter エンティティにルーティングする必要があります。ルーティングは、非ルーティング AVP を変更せずに行われます。リレーガイドラインについては、セクション 6.1.9 を参照してください。
PROXY - このカテゴリに該当するすべての Diameter メッセージは、以下に説明する識別子によって示される次の Diameter エンティティにルーティングする必要があります。ローカルサーバーは、ルーティングの前にメッセージに新しい AVP を含めることによって、メッセージにローカルポリシーを適用できます。プロキシガイドラインについては、セクション 6.1.9 を参照してください。
REDIRECT - このカテゴリに該当する Diameter メッセージには、ホーム Diameter サーバーの識別子を追加し、メッセージの送信者に返す必要があります。リダイレクトガイドラインについては、セクション 6.1.8 を参照してください。

サーバー識別子

メッセージをルーティングする 1 つ以上のサーバーの識別子。この識別子は、ピアテーブル（セクション 2.6）のホスト識別子フィールドにも存在する必要があります。ローカルアクションが RELAY または PROXY に設定されている場合、このフィールドにはメッセージをルーティングする必要があるサーバーの識別子が含まれます。ローカルアクションフィールドが REDIRECT に設定されている場合、このフィールドにはメッセージをリダイレクトする必要がある 1 つ以上のサーバーの識別子が含まれます。

静的または動的

ルートエントリが静的に構成されたか、動的に検出されたかを指定します。

有効期限

動的に検出されたルートテーブルエントリが期限切れになる時刻を指定します。Diameter セキュリティに公開鍵証明書が使用される場合（たとえば、TLS を使用する場合）、この値は関連する証明書の有効期限を超えてはなりません。

Diameter エージェントは、LOCAL、RELAY、PROXY、または REDIRECT 操作モードの少なくとも 1 つをサポートする必要があることに注意することが重要です。エージェントは、プロトコル仕様に準拠するためにすべての操作モードをサポートする必要はありませんが、セクション 2 のプロトコル準拠ガイドラインに従う必要があります。リレーエージェントとプロキシは AVP を並べ替えてはなりません。

ルーティングテーブルには、他のエントリと一致しないリクエストに使用する必要があるデフォルトエントリを含めることができます。ルーティングテーブルは、そのようなエントリのみで構成される場合があります。

リクエストがルーティングされる場合、ターゲットサーバーは、指定されたメッセージのアプリケーション ID をアドバタイズしているか（セクション 2.4 を参照）、リレーまたはプロキシエージェントとして自分自身をアドバタイズしている必要があります。それ以外の場合、Result-Code AVP が DIAMETER_UNABLE_TO_DELIVER に設定されたエラーが返されます。

2.8. Diameter エージェントの役割

クライアントとサーバーに加えて、Diameter プロトコルは、リレー、プロキシ、リダイレクト、および変換エージェントを導入します。これらはそれぞれセクション 1.2 で定義されています。Diameter エージェントは、次のようないくつかの理由で役立ちます。

セキュリティアソシエーションの維持を含む、構成可能なグループへのシステム管理の分散が可能です。
複数の同じ場所に配置された、または分散した NAS 機器セットから、同様のユーザーグループのセットへのリクエストの集中に使用できます。
リクエストまたはレスポンスに対して付加価値処理を実行できます。
負荷分散に使用できます。
複雑なネットワークには複数の認証ソースがあり、リクエストを分類して正しいターゲットに転送できます。

Diameter プロトコルは、エージェントがトランザクション状態を維持することを要求します。これはフェイルオーバーの目的で使用されます。トランザクション状態は、リクエストを転送する際に、そのホップバイホップ識別子が保存されることを意味します。このフィールドは、ローカルで一意の識別子に置き換えられ、対応する応答が受信されると元の値に復元されます。リクエストの状態は、応答の受信時に解放されます。ステートレスエージェントは、トランザクション状態のみを維持するエージェントです。

Proxy-Info AVP により、ステートレスエージェントは Diameter リクエストにローカル状態を追加でき、応答に同じ状態が存在することが保証されます。ただし、プロトコルのフェイルオーバー手順では、エージェントが保留中のリクエストのコピーを維持する必要があります。

ステートフルエージェントは、すべての認可されたアクティブセッションを追跡することによってセッション状態情報を維持するエージェントです。各認可されたセッションは特定のサービスにバインドされており、その状態は、エージェントが別の通知を受け取るか、セッションが期限切れになるまでアクティブと見なされます。各認可されたセッションには有効期限があり、これは Diameter サーバーによって Session-Timeout AVP を介して通知されます。

セッション状態の維持は、次のような特定のアプリケーションで役立つ場合があります。

プロトコル変換（たとえば、RADIUS <-> Diameter）
特定のユーザーに認可されたリソースの制限
ユーザーごとまたはトランザクションごとの監査

Diameter エージェントは、一部のリクエストに対してステートフル方式で動作し、他のリクエストに対してはステートレスである場合があります。Diameter 実装は、一部のリクエストに対しては 1 つのタイプのエージェントとして動作し、他のリクエストに対しては別のタイプのエージェントとして動作する場合があります。

2.8.1. リレーエージェント

リレーエージェントは、リクエストを受け入れ、メッセージ内で見つかった情報（たとえば、Destination-Realm AVP セクション 6.6 の値）に基づいてメッセージを他の Diameter ノードにルーティングする Diameter エージェントです。このルーティング決定は、サポートされているレルムと既知のピアのリストを使用して実行されます。これは、セクション 2.7 でさらに定義されているように、ルーティングテーブルとして知られています。

たとえば、リレーは、共通の地理的エリア（プレゼンスポイント、POP）内の複数のネットワークアクセスサーバー（NAS）からのリクエストを集約するために使用できます。リレーの使用は、NAS が他のレルムの Diameter サーバーと通信するために必要なセキュリティ情報で構成する必要がなくなるため、有利です。同様に、これにより、NAS が追加、変更、または削除されたときに必要となる Diameter サーバーの構成負荷が軽減されます。