[要約] RFC 6159は、Diameterプロトコルにおけるセッション固有の明示的なリクエストルーティングに関する仕様です。その目的は、Diameterネットワーク内でのリクエストの効率的なルーティングと処理を実現することです。
Independent Submission T. Tsou
Request for Comments: 6159 Huawei Technologies (USA)
Category: Informational G. Zorn
ISSN: 2070-1721 Network Zen
T. Taylor, Ed.
Huawei Technologies
April 2011
Session-Specific Explicit Diameter Request Routing
セッション固有の明示的な直径要求ルーティング
Abstract
概要
This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session.
このドキュメントでは、特定の直径プロキシが直径セッションを構成するすべてのメッセージ交換のパスにとどまることを可能にするメカニズムについて説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6159.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6159で取得できます。
IESG Note
IESGノート
Techniques similar to those discussed in this document were discussed in the IETF Diameter Maintenance and Extensions (DIME) Working Group. The group had no consensus that the problems addressed by such work are a real concern in Diameter deployments. Furthermore, there was no consensus that the proposed solutions are in line with the architectural principles of the Diameter protocol. As a result, the working group decided not to undertake the work. There has also not been a formal request for this functionality from any standards body. This RFC represents a continuation of the abandoned work. Readers of this specification should be aware that the IETF has not reviewed this specification and cannot say anything about suitability for a particular purpose or compatibility with the Diameter architecture and other extensions.
このドキュメントで説明したものと同様の手法については、IETFの直径のメンテナンスと拡張機能（DIME）ワーキンググループで説明しました。このグループは、そのような作業によって対処されている問題が直径の展開における真の関心事であるというコンセンサスを持っていませんでした。さらに、提案されたソリューションが直径プロトコルの建築原理に沿っているというコンセンサスはありませんでした。その結果、ワーキンググループは仕事を引き受けないことを決定しました。また、標準団体からのこの機能に対する正式な要求もありませんでした。このRFCは、放棄された作業の継続を表しています。この仕様の読者は、IETFがこの仕様をレビューしておらず、特定の目的や直径アーキテクチャやその他の拡張機能との適合性について何も言えないことを認識する必要があります。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. The 3GPP Wireless LAN (WLAN) Access Architecture ................4
3.1. Maintaining the Routing Path ...............................5
4. Diameter Explicit Routing (ER) ..................................6
4.1. Originating a Request (ER-Originator) ......................6
4.2. Relaying and Proxying Requests (ER-Proxy) ..................8
4.3. Receiving Requests (ER-Destination) .......................10
4.4. Diameter Answer Processing ................................11
4.5. Failover and Failback Considerations ......................12
4.6. Attribute-Value Pairs .....................................12
4.6.1. Explicit-Path-Record AVP ...........................12
4.6.1.1. Proxy-Host AVP ............................13
4.6.1.2. Proxy-Realm AVP ...........................13
4.6.2. Explicit-Path AVP ..................................13
4.7. Error Handling ............................................13
5. Example Message Flow ...........................................14
6. RADIUS/Diameter Protocol Interactions ..........................16
7. Security Considerations ........................................17
8. Acknowledgements ...............................................17
9. References .....................................................18
9.1. Normative References ......................................18
9.2. Informative References ....................................18
In the Diameter base protocol [RFC3588], the routing of request messages is based solely on the routing decisions made separately by each node along the path. [RFC5729] has added the ability to force messages to pass through a specified set of realms through the use of Network Access Identifier (NAI) decoration. However, no other specification provides the ability to force routing through a specific set of agents. Therefore, in a topology where multiple paths exist from source to destination, there is no guarantee that all messages relating to a given session will take the same path. In general, this has not caused problems, but some architectures (e.g., WLAN Third Generation Partnership Project (3GPP) IP access [TS23.234]) require that once certain agents become engaged in a session, they be able to process all subsequent messages for that session.
直径ベースプロトコル[RFC3588]では、リクエストメッセージのルーティングは、パスに沿った各ノードによって個別に行われたルーティング決定のみに基づいています。[RFC5729]は、ネットワークアクセス識別子（NAI）装飾を使用して、指定されたレルムのセットを通過するようにメッセージを強制する機能を追加しました。ただし、他の仕様では、特定のエージェントセットを介してルーティングを強制する機能はありません。したがって、ソースから宛先への複数のパスが存在するトポロジでは、特定のセッションに関連するすべてのメッセージが同じパスを取るという保証はありません。一般に、これは問題を引き起こしていませんが、いくつかのアーキテクチャ（例：WLAN第3世代パートナーシッププロジェクト（3GPP）IPアクセス[TS23.234]）が必要とする必要があります。そのセッションのために。
While the solution presented in this document is valid, it violates one of the basic premises of Diameter -- the robustness of its architecture. With normal Diameter routing, sessions will survive failures of agents along the routing path. With the proposals in this document, routing becomes pinned to specific agents whose failure will terminate the session.
このドキュメントに示されているソリューションは有効ですが、直径の基本的な前提の1つであるアーキテクチャの堅牢性に違反しています。通常の直径ルーティングでは、セッションはルーティングパスに沿ってエージェントの障害に耐えます。このドキュメントの提案により、ルーティングはセッションを終了する特定のエージェントに固定されます。
The authors see no interaction between explicit routing and the specific applications with which it is employed. Hence, in principle it can be added to existing applications if they support the necessary extensibility, and equally can be used with new applications.
著者は、明示的なルーティングとそれが採用されている特定のアプリケーションとの間に相互作用は見られません。したがって、原則として、必要な拡張性をサポートする場合、既存のアプリケーションに追加でき、新しいアプリケーションでも同様に使用できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following terms are used to define the functionality and participants in the routing extensions described in this document.
次の用語は、このドキュメントで説明されているルーティング拡張機能の機能と参加者を定義するために使用されます。
ER Explicit routing -- the mechanism provided by this specification to allow proxies traversed by the initial message of a session to ensure that they remain on the messaging path for all subsequent request messages of a session.
ER明示的なルーティング - この仕様によって提供されるメカニズムは、セッションの最初のメッセージによって移動するプロキシを可能にし、セッションの後続のすべての要求メッセージのメッセージングパスに留まることを保証します。
ER-Proxy A proxy that implements the ER mechanism and can therefore use it to remain in the path for subsequent messages of a session.
ER-Proxy ERメカニズムを実装するプロキシであるため、セッションの後続のメッセージのパスにとどまるために使用できます。
ER-Destination A Diameter node that is capable of participating in ER and that will ultimately consume the request sent by an ER-Originator.
ER-destination ERに参加できる直径ノードで、最終的にER-Originatorから送信されたリクエストを消費します。
ER-Originator A Diameter node initiating a session and sending the requests. The ER-Originator can be any Diameter node sending a request, i.e., a client, server or proxy capable of initiating sessions and participating in ER.
ER-ORIGINATORセッションを開始してリクエストを送信する直径ノード。ER-Originatorは、リクエストを送信する任意の直径ノード、つまりセッションを開始してERに参加できるクライアント、サーバー、またはプロキシであることができます。
Authentication, Authorization, and Accounting (AAA) Relays Other Diameter nodes interspersed between the ER-Originator, ER-Proxies, and the ER-Destination. These nodes represent existing Diameter agents and proxies that do not participate in ER and do not recognize Explicit-Path Attribute Value Pairs (AVPs).
認証、承認、および会計（AAA）は、ERオリジーネーター、ERプロキシ、およびER-destinationの間に散在する他の直径ノードを中継します。これらのノードは、ERに参加せず、明示的なパス属性値ペア（AVP）を認識しない既存の直径エージェントとプロキシを表します。
The 3GPP WLAN IP access architecture [TS23.234] is one example of a system requiring that certain agents (stateful proxies, in this case) remain in the forwarding path of all session messages. The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side, enabling a 3GPP subscriber to use a WLAN to access 3GPP services.
3GPP WLAN IPアクセスアーキテクチャ[TS23.234]は、特定のエージェント（この場合はステートフルプロキシ）がすべてのセッションメッセージの転送パスにとどまることを要求するシステムの一例です。3GPP WLANインターワーキングアーキテクチャは、3GPPサービスをWLANアクセス側に拡張し、3GPPサブスクライバーがWLANを使用して3GPPサービスにアクセスできるようにします。
WLAN AAA provides access to the WLAN to be authenticated and authorized through the 3GPP system. This access control can permit or deny a subscriber access to the WLAN system and/or the 3GPP system.
WLAN AAAは、3GPPシステムを介して認証および承認されるWLANへのアクセスを提供します。このアクセス制御は、WLANシステムおよび/または3GPPシステムへのサブスクライバーアクセスを許可または拒否できます。
There are two 3GPP WLAN interworking reference models:
2つの3GPP WLANインターワーキングリファレンスモデルがあります。
1. In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control as well as charging.
1. 非ローミングの場合、モデルには、ホームネットワーク内のWLANアクセスネットワークと3GPP AAAサーバーが含まれます。3GPP AAAサーバーは、アクセス制御と充電を担当します。
2. In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network, and the 3GPP AAA server in the home network. The 3GPP AAA server is responsible for access control. Charging records may be generated by the AAA proxy and/or the AAA server. The AAA proxy relays access control and charging messages to the AAA server. The AAA proxy will also do offline charging, if required.
2. ローミングの場合、モデルには、WLANアクセスネットワーク、訪問ネットワークの3GPPAAAプロキシ、およびホームネットワークの3GPP AAAサーバーが含まれます。3GPP AAAサーバーは、アクセス制御を担当します。充電レコードは、AAAプロキシおよび/またはAAAサーバーによって生成される場合があります。AAAプロキシは、アクセスコントロールと充電メッセージをAAAサーバーにリレーします。AAAプロキシは、必要に応じてオフライン充電も行います。
The roaming case presents two problems for which the Diameter routing mechanism described in [RFC3588] does not offer any unambiguous and standard solution.
ローミングケースは、[RFC3588]で説明されている直径ルーティングメカニズムが明確で標準的なソリューションを提供しない2つの問題を提示します。
Network Selection Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network.
ネットワークの選択、（おそらく多くの）代替ネットワークに訪問されたネットワークへの直径セッションの初期メッセージパスの選択。
Explicit Routing (ER) Maintaining the selected message path for all messages in the Diameter session.
明示的なルーティング（ER）直径セッション内のすべてのメッセージの選択されたメッセージパスを維持します。
Selecting an initial message path is outside the scope of this document. A mechanism for maintaining the selected message path is described in detail below.
初期メッセージパスの選択は、このドキュメントの範囲外です。選択したメッセージパスを維持するためのメカニズムについては、以下で詳しく説明します。
After a successful authentication, a Diameter session is established involving (at least) the following stateful entities:
認証が成功した後、（少なくとも）次のステートフルエンティティを含む直径セッションが確立されます。
o the Diameter client in the WLAN access node (e.g., the 3GPP AAA client in the terminal visited network),
o WLANアクセスノードの直径クライアント（例：ターミナルに訪問されたネットワークの3GPP AAAクライアントなど）、
o a Diameter proxy in the visited mobile network (e.g., the 3GPP AAA proxy in the terminal visited network), and
o 訪問したモバイルネットワークの直径プロキシ（例：ターミナル訪問ネットワークの3GPPAAAプロキシ）、および
o a Diameter server in the user's home realm (e.g., the destination 3GPP AAA server in the terminal home network).
o ユーザーのホームレルムの直径サーバー（ターミナルホームネットワークの宛先3GPP AAAサーバーなど）。
Message routing for the initial session request uses the normal Diameter routing tables (Section 2.7 of [RFC3588]) in the 3GPP AAA client, the 3GPP AAA proxy in the visited network, and any intermediate proxies after that. The 3GPP AAA client sends the initial session request to the 3GPP AAA proxy in the visited network. The 3GPP AAA proxy processes the request, then forwards it towards the destination 3GPP AAA server, through an intermediate proxy if necessary. The request may be forwarded through other intermediate proxies in the same way, until it reaches the destination 3GPP AAA server in the terminal home network.
初期セッション要求のメッセージルーティングでは、3GPP AAAクライアントの通常の直径ルーティングテーブル（[RFC3588]のセクション2.7）、訪問ネットワークの3GPP AAAプロキシ、およびその後の中間プロキシを使用します。3GPP AAAクライアントは、訪問されたネットワークの3GPPAAAプロキシに初期セッション要求を送信します。3GPP AAAプロキシは要求を処理し、必要に応じて中間プロキシを介して、宛先3GPP AAAサーバーに転送します。リクエストは、ターミナルホームネットワークの宛先3GPP AAAサーバーに到達するまで、同じ方法で他の中間プロキシを介して転送される場合があります。
The functions assigned to the 3GPP AAA proxy include:
3GPP AAAプロキシに割り当てられた関数は次のとおりです。
o Reporting charging information to the offline charging system in the visited network,
o 訪問されたネットワークのオフライン充電システムに充電情報を報告する、
o Policy enforcement based on roaming agreements, and
o ローミング契約に基づく政策施行、および
o Service termination initiated by the visited network's operator.
o 訪問されたネットワークのオペレーターによって開始されたサービス終了。
These functions all require that state be maintained within the visited network. The 3GPP's choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session.
これらの機能はすべて、状態が訪問されたネットワーク内で維持されることを要求します。3GPPの選択は、3GPP AAAプロキシでその状態を維持することです。これは、後者が同じセッションに関連するすべての後続のメッセージのメッセージングパスにとどまる必要があることを意味します。
This section outlines a Diameter ER mechanism by which Diameter nodes participating in ER can remain in the path of all request messages for a specific session. A new Explicit-Path AVP is defined to enable ER participants to manipulate the Destination-Host and/or Destination-Realm AVPs of request messages in order to ensure the correct routing behavior. The following sections describe the extensions to the request routing in [RFC3588] to implement the ER mechanism. The proposed extensions utilize existing routing strategies in [RFC3588] and do not mandate modifications to it. The mechanism imposes loose rather than strict source routing, in that subsequent messages of a session are forced through the participating nodes, but not through any individual non-participating nodes. In summary, only Diameter nodes interested in participating in the ER scheme will be involved in it.
このセクションでは、ERに参加する直径ノードが特定のセッションのすべての要求メッセージのパスにとどまることができる直径ERメカニズムの概要を説明します。ER参加者が正しいルーティング動作を確保するために、ER参加者がリクエストメッセージの宛先ホストおよび/または宛先RealM AVPを操作できるようにするために、新しい明示的パスAVPが定義されています。次のセクションでは、ERメカニズムを実装するための[RFC3588]のリクエストルーティングの拡張について説明します。提案された拡張機能は、[RFC3588]の既存のルーティング戦略を利用しており、変更を義務付けません。メカニズムは、厳密なソースルーティングではなくゆるいソースルーティングを課します。その後のセッションのメッセージは、参加しているノードを介して強制されますが、個々の非参加ノードを介してではありません。要約すると、ERスキームへの参加に関心のある直径ノードのみが関与します。
A Diameter node acting as an ER-Originator for a particular session MUST maintain a local cache that enumerates all the Diameter identities of the ER-Proxies that the request messages must traverse along the path to the ER-Destination. The identity of a Diameter node is defined in [RFC3588]. The local cache MAY also include the node's realm. The data structure of the cache is left up to the implementation and SHOULD persist as part of the session attributes or properties.
特定のセッションのER-Originatorとして機能する直径ノードは、要求メッセージがER-Destinationへのパスに沿って横断する必要があるERプロキシのすべての直径アイデンティティを列挙するローカルキャッシュを維持する必要があります。直径ノードのIDは[RFC3588]で定義されています。ローカルキャッシュには、ノードの領域も含まれる場合があります。キャッシュのデータ構造は実装に任されており、セッション属性またはプロパティの一部として持続する必要があります。
An ER-Originator sending request messages MUST add an Explicit-Path AVP to these requests. The contents of the cache SHOULD be used to populate the Explicit-Path AVP, with each cached entry represented by a corresponding instance of the Explicit-Path-Record AVP. ER-Proxies along the path of the request message MUST examine the contents of the Explicit-Path AVP and make routing adjustments based on records it contains. An example of the message flow is shown in Section 5. Note that the ER-Originator can be any Diameter node, i.e., a client, server, or proxy.
リクエストメッセージを送信するER-Originatorは、これらのリクエストに明示的なパスAVPを追加する必要があります。キャッシュの内容を使用して、明示的なパスAVPを入力し、各キャッシュエントリを明示的なパス記録AVPの対応するインスタンスで表す必要があります。リクエストメッセージのパスに沿ったERプロキシは、明示的なパスAVPの内容を調べ、含まれるレコードに基づいてルーティング調整を行う必要があります。メッセージフローの例は、セクション5に示されています。ERオリジネーターは、任意の直径ノード、つまりクライアント、サーバー、またはプロキシであることに注意してください。
The ER-Originator can populate the cache either by pre-configuring its contents or by using the first request message of the session to gather identities of participating ER-Proxies along the routing path. The latter scheme is known as Explicit-Path discovery. The contents of the cache can be pre-configured if the ER-Originator has explicit knowledge of the ER-Proxies the request messages must traverse; otherwise, the ER-Originator can use Explicit-Path discovery. It is RECOMMENDED that Explicit-Path discovery be used whenever possible since pre-configuration is less flexible by nature.
ER-Originatorは、コンテンツを事前に構成するか、セッションの最初の要求メッセージを使用して、ルーティングパスに沿って参加しているERプロキシのアイデンティティを収集することにより、キャッシュに登録できます。後者のスキームは、明示的なパス発見として知られています。キャッシュの内容は、ER-OriginatorがERプロキシの明示的な知識を持っている場合、リクエストメッセージが通過する必要がある場合に事前に構成できます。それ以外の場合、ER-Originatorは明示的なパスディスカバリーを使用できます。事前構成は本質的に柔軟性が低いため、可能な限り明示的なパスの発見を使用することをお勧めします。
Explicit-Path discovery is useful if the identities of the ER-Proxies are not known or if there are several ER-capable proxies (a cluster of proxies) that can be dynamically chosen based on other routing policies. In Explicit-Path discovery, the cache of the ER-Originator is initially empty. To initiate discovery, when the ER-Originator sends the first request message of a session, it MUST include the Explicit-Path AVP containing a single Explicit-Path-Record AVP with the identity and/or the realm of the ER-Originator. The ER-Originator MUST set the Destination-Host and/or Destination-Realm AVP of the request message to the identity and/or the realm of the ER-Destination, respectively, as specified in [RFC3588].
ERプロキシのアイデンティティが不明な場合、または他のルーティングポリシーに基づいて動的に選択できるいくつかのER対応プロキシ（プロキシのクラスター）がある場合、明示的なパスの発見が役立ちます。明示的なパスの発見では、ER-Originatorのキャッシュは最初は空です。発見を開始するには、ER-Originatorがセッションの最初の要求メッセージを送信する場合、ER-Originatorのアイデンティティおよび/または領域を含む単一の明示的パス録画AVPを含む明示的パスAVPを含める必要があります。ER-ORIGINATORは、[RFC3588]で指定されているように、それぞれIDおよび/またはER-destinationの領域にリクエストメッセージの宛先ホストおよび/または宛先RealM AVPを設定する必要があります。
Note that ER-Originator initial request message routing procedures and the process of population of the Destination-Realm may be affected by the User-Name AVP NAI decoration [RFC5729]. NAI decoration is a form of request message source routing and defines realms that the request message must traverse through before routing towards the ER-Destination. Diameter nodes participating in request message routing must examine and process the User-Name AVP, and modify the Destination-Realm AVP accordingly as long as there are realms left in the decorated NAI. Source routing based upon NAI decoration does not affect Explicit-Path discovery as defined in this document.
ER-Originator初期要求メッセージのルーティング手順と宛先REALMの母集団のプロセスは、ユーザー名AVP NAI装飾[RFC5729]の影響を受ける可能性があることに注意してください。NAI装飾は、リクエストメッセージソースルーティングの一形態であり、ER-Destinationに向かってルーティングする前にリクエストメッセージが通過する必要があるレルムを定義します。リクエストメッセージルーティングに参加する直径ノードは、ユーザー名のAVPを調べて処理し、装飾されたNAIにレルムが残っている限り、宛先RealM AVPを変更する必要があります。NAIの装飾に基づくソースルーティングは、このドキュメントで定義されている明示的なパスの発見には影響しません。
If the path taken by the initial request encounters one or more participating ER-Proxies and a participating ER-Destination, the procedures described in Section 4.2 and Section 4.3 ensure that a successful response to that request will contain an Explicit-Path AVP that includes one or more Explicit-Path-Records containing the ER-Originator's identity, the identities of all participating ER-Proxies, and the identity of the ER-Destination. The ER-Originator SHOULD populate its local cache with the contents of the Explicit-Path AVP received in this initial answer message.
最初のリクエストが取ったパスが1つ以上の参加しているERプロキシと参加しているER-destinationに遭遇した場合、セクション4.2およびセクション4.3で説明した手順により、その要求への成功した応答が1つを含む明示的なパスAVPを含むことを保証します。または、ER-Originatorのアイデンティティ、すべての参加しているERプロキシのアイデンティティ、およびER外立のアイデンティティを含む、より明示的なパス記録。ER-Originatorは、この最初の回答メッセージで受信した明示的なパスAVPの内容にローカルキャッシュを入力する必要があります。
If the answer message does not contain an Explicit-Path AVP or the Result-Code AVP is set to DIAMETER_ER_NOT_AVAILABLE (Section 4.7), it is an indication to the ER-Originator that the destination of the request does not support ER and that the ER-Originator SHOULD avoid sending an Explicit-Path AVP in subsequent request messages.
回答メッセージに明示的なパスAVPが含まれていないか、結果コードAVPがdiameter_er_not_available（セクション4.7）に設定されている場合、それはリクエストの宛先がERをサポートせず、ERがERを指示することを示しています。-Originatorは、後続の要求メッセージで明示的なパスAVPの送信を避ける必要があります。
If the initial request message initiated Explicit-Path discovery, but the Explicit-Path AVP in the answer message contains Explicit-Path-Records for the ER-Originator and ER-Destination only, it is an indication to the ER-Originator that there are no Diameter proxies capable of participating in ER along the path and that the ER-Originator SHOULD NOT send an Explicit-Path AVP in subsequent request messages of this session. See Section 4.5 for more discussion. In such cases, the situation may be transient, and Explicit-Path discovery may find participating proxies in succeeding sessions. It is left up to the ER-Originator to decide if Explicit-Path discovery should be attempted in succeeding sessions.
最初のリクエストメッセージが明示的なパスの発見を開始したが、回答メッセージの明示的なパスAVPには、ERオリジーネーターとER-destinationの明示的なパスレコードが含まれている場合、それはER-Originatorの兆候です。パスに沿ってERに参加できる直径プロキシはなく、ER-Originatorはこのセッションの後続の要求メッセージで明示的なパスAVPを送信してはならないこと。詳細については、セクション4.5を参照してください。そのような場合、状況は一時的なものである可能性があり、明示的なパスの発見は、後続のセッションに参加しているプロキシを見つける可能性があります。後続のセッションで明示的なパスの発見を試みるべきかどうかを判断するのは、ERオリジネーターに任されています。
Once the ER-Originator's local cache has been populated, whether by pre-configuration or through Explicit-Path discovery, all request messages for the session MUST include the Explicit-Path AVP using the contents of the local cache. The Explicit-Path AVP MUST contain the Explicit-Path-Records of all the nodes enumerated in the cache except that of the ER-Originator itself. The identities enumerated in the Explicit-Path AVP MUST appear in the order they will be traversed in the routing path. The last entry in the Explicit-Path AVP MUST be the Explicit-Path-Record of the ER-Destination. In addition, the value of the Destination-Host and possibly the Destination-Realm in the request message MUST be copied from the values of the Proxy-Host AVP and, if present, the Proxy-Realm AVP of the first Explicit-Path-Record AVP present in the Explicit-Path AVP.
ER-ORIGINATORのローカルキャッシュが入力されると、事前構成または明示的なパスの発見を通じて、セッションのすべての要求メッセージには、ローカルキャッシュの内容を使用して明示的なパスAVPを含める必要があります。明示的なパスAVPには、ER-Originator自体を除き、キャッシュに列挙されたすべてのノードの明示的なパスレコードを含める必要があります。明示的なパスAVPに列挙されたアイデンティティは、ルーティングパスで通過する順序で表示する必要があります。明示的なPath AVPの最後のエントリは、ER-Destinationの明示的なパス記録でなければなりません。さらに、リクエストメッセージ内の宛先ホストの値と場合によっては、宛先の宛先の値は、プロキシホストAVPの値からコピーする必要があります。明示的なパスAVPに存在するAVP。
This ensures that the ER-Originator as well as any AAA relays between the ER-Originator and the first ER-Proxy will route the message towards the first ER-Proxy as specified in RFC 3588 [RFC3588].
これにより、ER-OriginatorとER-Originatorと最初のERプロキシ間のAAAリレーが、RFC 3588 [RFC3588]で指定されているように、メッセージを最初のERプロキシに向けてルーティングすることが保証されます。
Subsequent actions taken by the first ER-Proxy upon receipt of the message are described in Section 4.2 and will mimic those of the ER-Originator.
メッセージの受信時に最初のERプロキシが講じた後続のアクションは、セクション4.2で説明されており、ER-Originatorのアクションを模倣します。
Answer messages received by the ER-Originator to subsequent request messages after the Explicit-Path has been established SHOULD NOT have an Explicit-Path AVP. If they do, this SHOULD be considered a suspect condition that may be caused by a misbehaving ER participant. It is left up to the ER-Originator whether to continue using the ER scheme when such a condition arises or to attempt another Explicit-Path discovery for subsequent sessions.
明示的なパスが確立された後にER-Originatorがその後の要求メッセージに受信した回答メッセージは、明示的なパスAVPを持たないはずです。もしそうなら、これは不正行為の参加者によって引き起こされる可能性のある疑わしい状態と見なされるべきです。そのような条件が発生したときにERスキームの使用を続けるか、その後のセッションのために別の明示的なパスの発見を試みるかは、ERオリジネーターに任されています。
The basic action taken by an ER-Proxy upon receiving a request is to check whether explicit routing is supported in the request and if so, check whether it is already a participant in explicit routing for the said request. If it is not an existing participant, if Explicit-Path discovery is in progress, and if it wishes to participate, it appends an Explicit-Path-Record AVP identifying itself to the end of the Explicit-Path AVP. If it is an existing participant, the ER-Proxy pops/removes the Explicit-Path-Record AVP pertaining to itself from the Explicit-Path AVP and then uses the next Explicit-Path-Record AVP for subsequent routing. Details of this operation follow.
リクエストを受信したときにERプロキシが取った基本的なアクションは、要求で明示的なルーティングがサポートされているかどうかを確認することであり、もしそうなら、それがすでにそのリクエストの明示的なルーティングの参加者であるかどうかを確認します。既存の参加者でない場合、明示的なパスの発見が進行中であり、参加を希望する場合、明示的なパスAVPの終わりまで識別する明示的なパス記録AVPを追加します。既存の参加者の場合、ER-Proxyは、明示的なパスAVPからそれ自体に関連する明示的なパス記録AVPをポップ/削除し、次の明示的なパス記録AVPを使用して後続のルーティングに使用します。この操作の詳細は次のとおりです。
An ER-Proxy is not required to keep local state or cache state regarding the explicit routing procedure. However, it MUST check whether an incoming request contains an Explicit-Path AVP. The following cases can occur.
明示的なルーティング手順に関して、地方の状態またはキャッシュ状態を維持するためにERプロキシは必要ありません。ただし、着信要求に明示的なパスAVPが含まれているかどうかを確認する必要があります。次のケースが発生する可能性があります。
1. If an incoming request does not contain an Explicit-Path AVP, then the ER-Proxy takes no action beyond processing and forwarding the request as specified in [RFC3588].
1. 着信要求に明示的なパスAVPが含まれていない場合、ER-Proxyは[RFC3588]で指定されているようにリクエストの処理と転送を超えてアクションを実行しません。
2. If the incoming request contains an Explicit-Path AVP, the ER-Proxy MUST check whether its identity is present in the Explicit-Path AVP. Determining whether its identity is present can be done by matching its identity to the Proxy-Host AVP contained in each Explicit-Path-Record. If its identity is not present, then:
2. 着信要求に明示的なパスAVPが含まれている場合、ERプロキシはそのアイデンティティが明示的なパスAVPに存在するかどうかを確認する必要があります。そのアイデンティティが存在するかどうかを判断することは、そのアイデンティティを各明示的パスレコードに含まれるプロキシホストAVPに一致させることで実行できます。そのアイデンティティが存在しない場合、次のとおりです。
A. If it wishes to participate in explicit routing, the ER-Proxy MUST verify that Explicit-Path discovery is in progress by verifying that the Proxy-Host AVP in the first Explicit-Path-Record AVP in the Explicit-Path AVP does not match the Destination-Host AVP (if present). If this verification succeeds or the Destination-Host AVP is absent, the ER-Proxy MAY append a new Explicit-Path-Record as the last AVP in the Explicit-Path AVP prior to forwarding the request. The new Explicit-Path-Record MUST contain a Proxy-Host AVP set to the proxy's identity, and MAY contain a Proxy-Realm AVP giving the proxy's realm. If, however, the Destination-Host AVP is present and matches the Proxy-Host AVP of the first Explicit-Path-Record AVP, then the Explicit-Path contains an already-defined source route that does not include the ER-Proxy. The ER-Proxy SHOULD process the request as if the ER-Path AVP were absent.
A.明示的なルーティングに参加したい場合、ERプロキシは、明示的なパスAVPの最初の明示的パス記録AVPのプロキシホストAVPが確認されないことを確認することにより、明示的なパスの発見が進行中であることを確認する必要があります宛先ホストAVPを一致させます（存在する場合）。この検証が成功した場合、または宛先ホストAVPが存在しない場合、ER-Proxyは、リクエストを転送する前に、明示的パスAVPの最後のAVPとして新しい明示的パスレコードを追加する場合があります。新しい明示的なパスレコードには、プロキシのIDに設定されたプロキシホストAVPを含める必要があり、プロキシの領域を与えるプロキシRealM AVPを含めることができます。ただし、宛先ホストAVPが存在し、最初の明示的なパス記録AVPのプロキシホストAVPと一致する場合、明示的なパスには、ERプロキシを含まないすでに定義されたソースルートが含まれています。ER-Proxyは、ER-PATH AVPが存在しないかのようにリクエストを処理する必要があります。
B. If the ER-Proxy does not wish to participate in the ER, it SHOULD NOT modify the Explicit-Path AVP and SHOULD simply process and forward the request as specified in [RFC3588] using the existing values of the Destination-Host and/or Destination-Realm AVPs. Non-ER-Proxies and relays that do not support ER and do not recognize Explicit-Path AVP will take the same action.
B. ER-ProxyがERに参加したくない場合、明示的なパスAVPを変更してはならず、[RFC3588]で指定されているように、宛先ホストの既存の値を使用して[RFC3588]で指定された要求を処理して転送する必要があります。または宛先realm avps。ERをサポートせず、明示的なパスAVPを認識していない非プロキシとリレーは、同じアクションをとります。
3. If the identity of the ER-Proxy is present in the Explicit-Path AVP, then:
3. ERプロキシのアイデンティティが明示的なパスAVPに存在する場合、次のとおりです。
A. If it is not the first Explicit-Path-Record in the AVP, this MUST be considered an error, and an answer message with the 'E' bit set and the Result-Code set to DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the ER-Originator (Section 4.7).
A. AVPでの最初の明示的なパスレコードではない場合、これはエラーと「E」ビットセットを備えた回答メッセージとdiameter_invalid_proxy_path_stackへの結果コードセットをERに返信する必要があります。-ORIGINATOR（セクション4.7）。
B. If the identity of the ER-Proxy matches the first Explicit-Path-Record, the ER-Proxy MUST remove this record from the Explicit-Path AVP and repopulate the Destination-Host and possibly the Destination-Realm AVP from the next Explicit-Path-Record present in the Explicit-Path AVP. Setting the Destination-Host and possibly the Destination-Realm AVP will ensure that the ER-Proxy as well as all AAA relays between the current ER-Proxy and the next ER-Proxy enumerated in the Explicit-Path AVP will route the message towards the next ER-Proxy. The process of removing the ER-Proxy's record is analogous to popping an entry from a stack represented by the Explicit-Path AVP.
B. ER-ProxyのIDが最初の明示的なパスレコードと一致する場合、ER-Proxyはこのレコードを明示的なパスAVPから削除し、宛先ホスト、場合によっては次の明示的な宛先-RealM AVPを再現する必要があります-path-record explicit-path avpに存在します。Destination-HostおよびDestination-RealM AVPを設定すると、ERプロキシと現在のERプロキシと明示的なパスで列挙された次のERプロキシの間のすべてのAAAリレーが、メッセージをルーティングしていることを保証します。次のer-proxy。ER-Proxyのレコードを削除するプロセスは、明示的なパスAVPで表されるスタックからエントリをポップすることに類似しています。
The behavior specified above also applies to a Diameter node that acts as a relay agent and participates in the ER scheme.
上記の動作は、リレーエージェントとして機能し、ERスキームに参加する直径ノードにも適用されます。
A Diameter node that locally processes requests sent by the ER-Originator (Section 4.1) and is able to support ER (an ER-Destination) MUST check for the presence of an Explicit-Path AVP in the request message.
ER-Originator（セクション4.1）から送信された要求をローカルに処理し、ER（ER-destination）をサポートできる直径ノードは、リクエストメッセージに明示的なパスAVPの存在を確認する必要があります。
1. If an incoming request does not contain an Explicit-Path AVP, then it is an indication that messages belonging to this session will not use ER. The ER-Destination MUST simply process the request for local consumption and formulate an answer message as specified in [RFC3588].
1. 着信要求に明示的なパスAVPが含まれていない場合、これはこのセッションに属するメッセージがERを使用しないことを示しています。ER-destinationは、[RFC3588]で指定されているように、現地消費の要求を単純に処理し、回答メッセージを策定する必要があります。
2. If the incoming request contains an Explicit-Path AVP, the ER-Destination MUST check whether its identity is present in the Explicit-Path AVP. If its identity is not present, indicating that Explicit-Path discovery is in progress, then:
2. 着信要求に明示的なパスAVPが含まれている場合、ER-destinationはそのアイデンティティが明示的なパスAVPに存在するかどうかを確認する必要があります。そのアイデンティティが存在しない場合、明示的なパスの発見が進行中であることを示してください。
A. If it wishes to participate in the ER, and subject to paragraph B below, the ER-Destination MUST append a new Explicit-Path-Record to the Explicit-Path AVP in the received message. The new Explicit-Path-Record MUST contain at the least a Proxy-Host AVP set to the ER-Destination's identity. The ER-Destination MUST then copy the resulting Explicit-Path AVP to the subsequent answer message.
A. ERに参加したい場合は、以下のパラグラフBの対象である場合、ER-destinationは、受信したメッセージの明示的なパスAVPに新しい明示的なパスレコードを追加する必要があります。新しい明示的なパスレコードには、ER-DestinationのIDに設定された少なくともプロキシホストAVPに含まれる必要があります。次に、ER-Destinationは、結果の明示的なAVPを後続の回答メッセージにコピーする必要があります。
B. If there is only one Explicit-Path-Record in the incoming Explicit-Path AVP, then this is an indication of a successful Explicit-Path discovery, but with no participating ER-Proxies. The ER-Destination SHOULD NOT copy the Explicit-Path AVP into the subsequent answer message.
B.着信明示的なAVPに明示的なパス記録が1つしかない場合、これは明示的なパス発見の成功の兆候ですが、参加しているERプロキシはありません。ER-Destinationは、明示的なパスAVPをその後の回答メッセージにコピーしないでください。
C. If the ER-Destination supports ER but does not wish to or cannot participate, it MAY send a Result-Code AVP set to DIAMETER_ER_NOT_AVAILABLE as defined in Section 4.7. The ER-Destination MUST NOT include any Explicit-Path AVP in the subsequent answer. Diameter servers that do not support ER and do not recognize the Explicit-Path AVP will also omit the Explicit-Path AVP from the answer message.
C. ER-destinationがERをサポートしているが参加できない場合、または参加できない場合、セクション4.7で定義されているように、結果コードAVPセットをDiameter_ER_NOT_AVAILABLEに送信する場合があります。ER-destinationは、その後の回答に明示的なパスAVPを含めてはなりません。ERをサポートせず、明示的なパスAVPを認識しない直径サーバーも、回答メッセージから明示的なパスAVPを省略します。
3. If the identity of the ER-Destination matches a record in the Explicit-Path AVP, then it MUST be the only Explicit-Path-Record present in the Explicit-Path AVP. Otherwise, this MUST be considered an error, and an answer message with the 'E' bit set and containing an Experimental-Result-Code AVP set to DIAMETER_INVALID_PROXY_PATH_STACK MUST be sent back to the ER-Originator (Section 4.7). If the identity of the ER-Destination does match the only existing Explicit-Path-Record, then this is an indication that the request reached the ER-Destination by way of a successfully executed explicit route. The ER-Destination MUST NOT include the Explicit-Path AVP in the subsequent answer message.
3. ER-destinationのアイデンティティが明示的なパスAVPのレコードと一致する場合、それは明示的なパスAVPに存在する唯一の明示的なパス記録でなければなりません。それ以外の場合は、これはエラーと見なされる必要があり、「E」ビットセットを備えた回答メッセージと、diameter_invalid_proxy_path_stackに設定された実験結果コードAVPを含む必要があります。ER-destinationのアイデンティティが既存の既存の明示的パスレコードと一致する場合、これは、リクエストが正常に実行された明示的なルートによってER-destinationに到達したことを示しています。ER-Destinationは、その後の回答メッセージに明示的なパスAVPを含めてはなりません。
There is no requirement on Diameter nodes participating in ER to provide special handling or routing of answer messages. Answer messages SHOULD be processed normally as specified in [RFC3588]. However, a Diameter node acting as an ER-Destination MUST formulate a proper Explicit-Path AVP in answer messages as described in Section 4.3.
ERに参加する直径ノードには、応答メッセージの特別な取り扱いまたはルーティングを提供する要件はありません。回答メッセージは、[RFC3588]で指定されているように正常に処理する必要があります。ただし、ER-destinationとして機能する直径ノードは、セクション4.3で説明されているように、回答メッセージの適切な明示的パスAVPを定式化する必要があります。
If there is no ER-Proxy along the selected path, the answer message MAY contain an Explicit-Path AVP that contains only the Explicit-Route-Records of the ER-Originator and the ER-Destination, indicating that there is no ER support found in Diameter nodes along the path. It is left to the ER-Originator to continue with processing of the request without ER support or terminate the session. The ER-Originator SHOULD NOT attempt to perform Explicit-Path discovery in subsequent request messages of this session in such cases, to protect against failback conditions where an ER-Proxy suddenly appears in the path and attempts to add a new Explicit-Path-Record for request messages other than the initial request.
選択したパスに沿ってERプロキシがない場合、Answerメッセージには、ER-Originatorの明示的なルート録音とER照射のみが含まれる明示的なパスAVPが含まれている場合があり、ERサポートが見つかっていないことを示しています。パスに沿った直径ノード。ER-オリジナーターに任され、ERサポートなしでリクエストの処理を続行したり、セッションを終了したりします。ER-Originatorは、このセッションの後続のリクエストメッセージで明示的なパス発見を実行しようとしないようにして、ER-Proxyが突然パスに現れ、新しい明示的パス録画を追加しようとするフェイルバック条件から保護する必要があります。初期リクエスト以外のリクエストメッセージの場合。
Allowing an ER-Proxy to join the session after the initial request makes sense only if the application requirements do not mandate that every participating ER-Proxy receive all of the messages of a session.
最初の要求後にER-Proxyがセッションに参加できるようにすると、アプリケーション要件がすべての参加しているER-Proxyがセッションのすべてのメッセージを受信することを義務付けていない場合にのみ理にかなっています。
However, depending on local policy, the ER-Originator MAY attempt ER path discovery in subsequent sessions despite the lack of proxy participants in the earlier attempt.
ただし、ローカルポリシーに応じて、ER-Originatorは、以前の試みでプロキシ参加者が不足しているにもかかわらず、その後のセッションでERパス発見を試みる場合があります。
If a failover occurs in a Diameter node preceding an ER-Proxy when the Explicit-Path is already established, it is possible that a DIAMETER_UNABLE_TO_DELIVER error will be received by the ER-Originator if there are no alternative paths towards the ER-Proxy. In such a case, it is left to the ER-Originator to handle the error as specified in the Diameter application or in [RFC3588].
明示的なパスが既に確立されているときにERプロキシの前に直径ノードでフェールオーバーが発生すると、ER-Proxyに向けた代替パスがない場合、ER-OriginatorによってDiameter_unable_to_deliverエラーが受信される可能性があります。そのような場合、直径アプリケーションまたは[RFC3588]で指定されているようにエラーを処理するために、ER-Originatorに任されています。
The following sections define the AVPs used in the ER process. All of these AVPs MUST have the 'V' bit set and the 'M' bit cleared, with the Vendor-ID field set to 2011 (as assigned by IANA in "Private Enterprise Numbers" registry; see http://www.iana.org/).
次のセクションでは、ERプロセスで使用されるAVPを定義します。これらのAVPはすべて、「V」ビットセットと「M」ビットがクリアされている必要があり、ベンダーIDフィールドは2011年に設定されています（「プライベートエンタープライズ番号」レジストリでIANAによって割り当てられています。http：//www.ianaを参照してください。.org/）。
The Explicit-Path-Record AVP (AVP Code 35001) is of type Group. The identity added in the Proxy-Host [RFC3588] element of this AVP MUST be the same as the one advertised by the Diameter node in the Origin-Host AVP during the Capabilities Exchange messages.
明示的なパス記録AVP（AVPコード35001）は、タイプグループです。このAVPのプロキシホスト[RFC3588]要素に追加されたアイデンティティは、機能交換メッセージ中にOrigin-Host AVPの直径ノードによって宣伝されているものと同じでなければなりません。
Explicit-Path-Record ::= < AVP Header: 35001 >
{ Proxy-Host }
[ Proxy-Realm ]
The Proxy-Host AVP (AVP Code 35004) is of type DiameterIdentity. It identifies the ER node that is inserting the record. The Proxy-Host AVP MUST be present.
プロキシホストAVP（AVPコード35004）は、直径のタイプです。レコードを挿入しているERノードを識別します。プロキシホストAVPが存在する必要があります。
The Proxy-Realm AVP (AVP Code 35002) is of type DiameterIdentity, and contains the realm of the ER node inserting the record. The Proxy-Realm AVP MAY be present in the Explicit-Path-Record. If it is present, the realm name included in the value of the Proxy-Host AVP MUST match the value of the Proxy-Realm AVP.
Proxy-RealM AVP（AVPコード35002）は、直径のタイプであり、レコードを挿入するERノードの領域が含まれています。Proxy-RealM AVPは、明示的なパスレコードに存在する場合があります。存在する場合、プロキシホストAVPの値に含まれるレルム名は、プロキシRealM AVPの値と一致する必要があります。
The Explicit-Path AVP (AVP Code 35003) is of type Grouped. This AVP MUST be present in all request messages performing ER. It MAY be present in the answer to the initial session request message if Explicit-Path discovery was successfully executed for the request.
明示的なパスAVP（AVPコード35003）は、グループ化されたタイプです。このAVPは、ERを実行するすべての要求メッセージに存在する必要があります。これは、明示的なパスの発見がリクエストのために正常に実行された場合、最初のセッションリクエストメッセージの回答に存在する場合があります。
Explicit-Path ::= < AVP Header: 35003 >
1* [ Explicit-Path-Record ]
* [ AVP ]
The following error conditions may occur during ER processing. All error indications MUST be encapsulated in an instance of the Experimental-Result AVP [RFC3588] with the Vendor-ID AVP set to 2011 and the Experimental-Result-Code set as specified below.
ER処理中に次のエラー条件が発生する場合があります。すべてのエラー適応症は、ベンダー-ID AVPが2011年に設定され、以下に指定されているように実験的結果コードセットを使用して、実験と結果のAVP [RFC3588]の例でカプセル化する必要があります。
DIAMETER_INVALID_PROXY_PATH_STACK 3501
diameter_invalid_proxy_path_stack 3501
A request message received by an ER-Proxy or ER-Destination after an Explicit-Path has been established has the first or only Explicit-Path-Record AVP not matching the ER-Proxy's or the ER-Destination's identity. The same error applies to ER-Destinations receiving an Explicit-Path-AVP containing more than one Explicit-Path-Record or an Explicit-Path-AVP with only one Explicit-Path-Record not matching its own identity.
明示的なパスが確立された後にER-ProxyまたはER-destinationによって受信された要求メッセージには、ER-ProxyまたはER-Destinationのアイデンティティと一致しない最初のまたは唯一の明示的な記録AVPがあります。同じエラーが、複数の明示的パスレコードまたは明示的なパスAVPを含む明示的パスAVPを受信したER縮小にも当てはまります。
This error SHOULD be considered a protocol failure and SHOULD be treated on a per-hop basis; Diameter proxies may attempt to correct the error, if possible. Diameter answer messages containing this error indication MUST have the 'E' bit set and MUST conform to Section 7.2 of [RFC3588].
このエラーはプロトコル障害と見なされる必要があり、ホップごとに扱う必要があります。直径プロキシは、可能であればエラーを修正しようとする場合があります。このエラー表示を含む直径回答メッセージには、「E」ビットが設定されている必要があり、[RFC3588]のセクション7.2に適合する必要があります。
DIAMETER_ER_NOT_AVAILABLE 4501
diameter_er_not_available 4501
An ER-Destination that supports ER routing but is unable to comply for unknown reasons MAY send an answer message with the Result-Code AVP set to this error code. This error value SHOULD be considered a transient failure indicating that subsequent ER attempts may succeed.
ERルーティングをサポートしているが、不明な理由で従うことができないER予定は、結果コードAVPがこのエラーコードに設定された回答メッセージを送信する場合があります。このエラー値は、その後のERの試みが成功する可能性があることを示す一時的な障害と見なされる必要があります。
The example presented here illustrates the flow of Diameter messages with the typical attributes present in the ER scenario.
ここに示す例は、ERシナリオに存在する典型的な属性を含む直径メッセージの流れを示しています。
The ER-Originator in the example below shows the use of Explicit-Path discovery with the first request. However, the ER-Originator could also use a pre-configured cache. The ER-Originator can be any Diameter node sending a request, i.e., a client, server, or proxy. In this scenario, the local cache of the ER-Originator is initially empty.
以下の例のERオリジーターは、最初のリクエストで明示的なパス発見の使用を示しています。ただし、ER-Originatorは、事前に構成されたキャッシュを使用することもできます。ER-Originatorは、要求を送信する任意の直径ノード、つまりクライアント、サーバー、またはプロキシである可能性があります。このシナリオでは、ER-Originatorのローカルキャッシュが最初に空です。
The AAA relays between the ER-Proxies, ER-Originator, and ER-Destination may or may not be present and are shown here to depict routing paths that the requests may take prior to being processed by nodes participating in the ER scheme. The AAA relays also depict existing Diameter relays or proxies that do not recognize Explicit-Path AVPs and therefore do not participate in ER.
AAAは、ERプロキシ、ERオリジーネーター、およびER-destinationの間のリレーが存在する場合と存在しない場合があり、ERスキームに参加するノードによって処理される前にリクエストが取る可能性のあるルーティングパスを描写するようにここに示されています。AAAリレーは、明示的なパスAVPを認識しないため、ERに関与しない既存の直径リレーまたはプロキシを示しています。
ER- ER- ER- ER-
Originator AAA relays Proxy1 AAA relays Proxy2 Destination
(o.r1 (p.r1 (p.r2 (d.r2
.example) .example) .example) .example)
| | | | |
cache=(empty) | | | | |
------------->|--------->| | | |
(1st request of the session)| | | |
Explicit-Path= | | | |
o.r1.example,r1.example | | |
dest-host=d.r2.example | | | |
dest-realm=r2.example | | | |
| | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=o.r1.example,r1.example
| | record2=p.r1.example,r1.example
| | dest-host=d.r2.example |
| | dest-realm=r2.example |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path=
| | | record1=o.r1.example,
| | | r1.example
| | | record2=p.r1.example,
| | | r1.example
| | | record3=p.r2.example,
| | | r2.example
| | | dest-host=d.r2.example
| | | dest-realm=r2.example
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.r1.example,r1.example (answer) |
record2=p.r1.example,r1.example Explicit-Path=
record3=p.r2.example,r2.example record1=o.r1.example,r1.example
record4=d.r2.example,r2.example record2=p.r1.example,r1.example
| | record3=p.r2.example,r2.example
| | record4=d.r2.example,r2.example
Note: An originator pre-configuring | | |
its local cache can skip the | | |
exchange above and send the | | |
initial request as shown below. | | |
| | | | |
------------->|--------->| | | |
(subsequent request of the session) | | |
Explicit-Path= | | | |
record1=p.r1.example,r1.example | | |
record2=p.r2.example,r2.example | | |
record3=d.r2.example,r2.example | | |
dest-host=p.r1.example | | | |
dest-realm=r1.example | | | |
| |--------->|--------->| |
| | (forwarded request)| |
| | Explicit-Path= | |
| | record1=p.r2.example,r2.example
| | record2=d.r2.example,r2.example
| | dest-host=p.r2.example |
| | dest-realm=r2.example |
| | | | |
| | | |--------->|
| | | (forwarded request)
| | | Explicit-Path
| | | record1=d.r2.example,
| | | r2.example
| | | dest-host=d.r2.example
| | | dest-realm=r2.example
| | | | |
cache= |<---------|<---------|<---------|<---------|
record1=o.r1.example,r1.example (answer) | |
record2=p.r1.example,r1.example * no Explicit-Path-AVP present
record3=p.r2.example,r2.example | | |
record4=d.r2.example,r2.example | | |
| | | | |
| | | | |
(subsequent request of the session will repeat the process above)
| | | | |
| | | | |
Figure 1: Example ER Message Flow
図1：ERメッセージフローの例
No actions need to be taken with regards to RADIUS/Diameter interaction. The routing extension described in this document is transparent to any translation gateway and relevant only to Diameter routing. The assumption is that if there is a RADIUS proxy chain between Diameter translation agents, the route between translation agents remains stable during the session and does not cause an invalidation of the proxy path stack.
半径/直径の相互作用に関して行動をとる必要はありません。このドキュメントで説明されているルーティング拡張機能は、任意の翻訳ゲートウェイに対して透明であり、直径ルーティングにのみ関連します。仮定は、直径翻訳エージェント間に半径プロキシチェーンがある場合、翻訳エージェント間のルートはセッション中は安定したままであり、プロキシパススタックの無効化を引き起こさないということです。
The security considerations in [RFC3588] apply to this extension. In addition, this extension raises questions of authorization and can potentially allow a new denial-of-service attack.
[RFC3588]のセキュリティ上の考慮事項は、この拡張機能に適用されます。さらに、この拡張機能は認可の問題を提起し、新しいサービス拒否攻撃を可能にする可能性があります。
The authorization issue comes about because the proxies that participate in ER are self-selected. An ER-Proxy is able, through the operation of ER, to guarantee that it can monitor every message of a session. This is in contrast to ordinary Diameter routing, where some messages may pass by an alternate route. The question is whether the originating party is prepared to extend this additional degree of trust to arbitrary parties along the path. If not, the ER-Originator requires a mechanism to determine whether an ER-Proxy listed in the returned Explicit-Path AVP can be trusted. If it has such a mechanism, then an unwanted ER-Proxy can be deleted from its cache and thus not appear in the ER-Path AVP in subsequent requests. This specification assumes that either the originating party is prepared to allow arbitrary Diameter nodes along the path to attach themselves to the session as ER-Proxies, or the ER-Originator maintains a pre-configured list of ER-Proxies in its cache.
承認の問題は、ERに参加するプロキシが自己選択されているためです。ERプロキシは、ERの操作を通じて、セッションのすべてのメッセージを監視できることを保証することができます。これは、一部のメッセージが代替ルートで通過する場合がある通常の直径ルーティングとは対照的です。問題は、この追加の信頼度をパスに沿ってarbitrary意的な当事者に拡張する準備ができているかどうかです。そうでない場合、ER-Originatorは、返された明示的パスAVPにリストされているERプロキシが信頼できるかどうかを判断するメカニズムを必要とします。そのようなメカニズムがある場合、そのキャッシュから不要なERプロキシを削除することができ、その後のリクエストではER-PATH AVPには表示されません。この仕様は、発信者がパスに沿って任意の直径ノードをERプロキシとしてセッションに取り付けることを許可するように準備されているか、ER-OriginatorがキャッシュにERプロキシの事前に構成されたリストを維持することを前提としています。
The potential denial-of-service attack is not a serious one because the same result can be obtained more directly. An attacker with control of a Diameter node along the path of the original request could insert an Explicit-Path-Record containing the identity of another node or a non-existent node, rather than its own identity. Routing subsequent messages of the session through another node could result in violation of the trust assumptions made upstream. Routing subsequent messages to a non-existent node causes them to be lost and terminates the session. It would seem simpler to perpetrate whatever harm the attacker intends at the subverted Diameter node itself. The advantage of using ER to accomplish either of the attacks is that it makes it more difficult to determine which node misbehaved, but the extra effort involved to implement the attack does not seem to be worth the potential gain.
潜在的なサービス拒否攻撃は深刻な攻撃ではありません。同じ結果がより直接的に得られるためです。元のリクエストのパスに沿った直径ノードを制御する攻撃者は、独自のアイデンティティではなく、別のノードまたは存在しないノードのIDを含む明示的なパス記録を挿入できます。別のノードを介したセッションの後続のメッセージをルーティングすると、上流で構成される信頼の仮定に違反する可能性があります。存在しないノードに後続のメッセージをルーティングすると、それらが失われ、セッションが終了します。攻撃者が覆われた直径ノード自体で意図する害を与えるものを実行する方が簡単に思えるでしょう。ERを使用していずれかの攻撃を達成することの利点は、どのノードが誤解されているかを判断することがより困難になることですが、攻撃を実施するための特別な努力は潜在的な利益に値しないようです。
The authors gratefully acknowledge the contributions of Tony Zhang, Fortune Huang, Rajith R., Victor Fajardo, Jouni Korhonen, Tolga Asveren, Mark Jones, Avi Lior, Steve Norreys, Lionel Morand, Dave Frascone, and Hannes Tschofenig.
著者は、トニー・チャン、フォーチュン・ファン、ラジス・R、ビクター・ファジャルド、ジュニア・コルホネン、トルガ・アスベレン、マーク・ジョーンズ、アヴィ・リオール、スティーブ・ノリーズ、ライオネル・モランド、デイブ・フラスコーネ、ハンヌ・ツェフェニグの貢献に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC5729] Korhonen, J., Ed., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
[RFC5729] Korhonen、J.、Ed。、Jones、M.、Morand、L。、およびT. Tsou、「ユーザー名と領域に基づく直径要求のルーティングに関する説明」、RFC 5729、2009年12月。
[TS23.234] 3GPP, "3GPP system to Wireless Local Area Network (WLAN) interworking; System description", TS 23.234 Version 7.4.0, 2006.
[TS23.234] 3GPP、「3GPPシステムからワイヤレスローカルエリアネットワーク（WLAN）インターワーキング、システム説明」、TS 23.234バージョン7.4.0、2006。
Authors' Addresses
著者のアドレス
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
Tina Tsou Huawei Technologies（USA）2330 Central Expressway Santa Clara、CA 95050 USA
Phone: +1 408 330 4424
EMail: tena@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na、Bangkok 10260 Thail
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave. Ottawa Canada
トム・テイラー（編集者）Huawei Technologies 1852 Lorraine Ave. Ottawa Canada
EMail: tom111.taylor@bell.net