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
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
特定于会话的显式Diameter请求路由
Abstract
摘要
This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session.
本文档描述了一种机制，可使特定的Diameter代理保留在构成Diameter会话的所有消息交换的路径中。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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）工作组讨论了与本文件中讨论的技术类似的技术。专家组没有达成共识，认为这类工作所解决的问题是国际社会真正关心的问题。此外，对于提议的解决方案是否符合Diameter协议的架构原则，没有达成共识。因此，工作组决定不进行这项工作。也没有任何标准机构正式请求此功能。本RFC代表废弃工程的继续。本规范的读者应注意，IETF未审查本规范，且不能说明特定用途的适用性或与Diameter架构和其他扩展的兼容性。
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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
在Diameter基本协议[RFC3588]中，请求消息的路由仅基于路径上每个节点单独作出的路由决定。[RFC5729]通过使用网络访问标识符（NAI），增加了强制消息通过指定领域集的能力。但是，没有其他规范提供通过一组特定代理强制路由的能力。因此，在从源到目标存在多条路径的拓扑中，无法保证
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.
与给定会话相关的所有消息将采用相同的路径。一般来说，这不会导致问题，但某些架构（例如，WLAN第三代合作伙伴关系项目（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.
虽然本文中给出的解决方案是有效的，但它违反了Diameter的一个基本前提——其体系结构的健壮性。使用正常直径路由，会话将在路由路径上的代理失败后生存。使用本文档中的建议，路由将固定到特定的代理，其故障将终止会话。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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代理实现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目的地能够参与ER并最终使用ER发起者发送的请求的Diameter节点。
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发起方发起会话并发送请求的Diameter节点。ER发起人可以是发送请求的任何Diameter节点，即能够发起会话并参与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目的地之间的其他Diameter节点。这些节点表示不参与ER且不识别显式路径属性值对（AVP）的现有Diameter代理和代理。
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提供对WLAN的访问，以便通过3GPP系统进行身份验证和授权。该访问控制可允许或拒绝用户访问WLAN系统和/或3GPP系统。
There are two 3GPP WLAN interworking reference models:
有两种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接入网络、访问网络中的3GPP AAA代理和家庭网络中的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]中描述的直径路由机制没有提供任何明确的标准解决方案。
Network Selection Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network.
网络选择选择Diameter会话的初始消息路径，该路径通过（可能是多个）备选访问网络到达家庭网络。
Explicit Routing (ER) Maintaining the selected message path for all messages in the Diameter session.
显式路由（ER）维护Diameter会话中所有消息的选定消息路径。
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:
成功身份验证后，建立Diameter会话，该会话至少涉及以下有状态实体：
o the Diameter client in the WLAN access node (e.g., the 3GPP AAA client in the terminal visited network),
o WLAN接入节点中的Diameter客户端（例如，终端访问网络中的3GPP AAA客户端），
o a Diameter proxy in the visited mobile network (e.g., the 3GPP AAA proxy in the terminal visited network), and
o 到访移动网络中的Diameter代理（例如，终端到访网络中的3GPP AAA代理），以及
o a Diameter server in the user's home realm (e.g., the destination 3GPP AAA server in the terminal home network).
o 用户家庭领域中的Diameter服务器（例如，终端家庭网络中的目标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客户端向访问网络中的3GPP AAA代理发送初始会话请求。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.
本节概述了Diameter机制，通过该机制，参与ER的Diameter节点可以保留在特定会话的所有请求消息的路径中。定义了一个新的显式路径AVP，使ER参与者能够操纵请求消息的目标主机和/或目标域AVP，以确保正确的路由行为。以下各节描述了[RFC3588]中请求路由的扩展，以实现ER机制。建议的扩展使用[RFC3588]中的现有路由策略，不要求对其进行修改。该机制采用松散而非严格的源路由，即会话的后续消息强制通过参与节点，而不是通过任何单个非参与节点。总之，只有对参与ER方案感兴趣的Diameter节点才会参与其中。
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发起者的Diameter节点必须维护一个本地缓存，该缓存枚举请求消息必须沿ER目标路径遍历的ER代理的所有Diameter标识。直径节点的标识在[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发起者必须向这些请求添加显式路径AVP。缓存的内容应用于填充显式路径AVP，每个缓存条目由显式路径记录AVP的对应实例表示。沿请求消息路径的ER代理必须检查显式路径AVP的内容，并根据其包含的记录进行路由调整。第5节显示了消息流的示例。请注意，ER发起人可以是任何Diameter节点，即客户端、服务器或代理。
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发起人可以通过预配置其内容或通过使用会话的第一条请求消息沿路由路径收集参与ER代理的身份来填充缓存。后一种方案称为显式路径发现。如果ER发起者明确知道请求消息必须遍历的ER代理，则可以预先配置缓存的内容；否则，ER发起者可以使用显式路径发现。建议尽可能使用显式路径发现，因为预配置本质上不太灵活。
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发起者的缓存最初是空的。要启动发现，当ER发起者发送会话的第一条请求消息时，它必须包括显式路径AVP，其中包含具有ER发起者身份和/或领域的单个显式路径记录AVP。ER发端人必须按照[RFC3588]中的规定，将请求消息的目标主机和/或目标域AVP分别设置为ER目标的标识和/或域。
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发起者初始请求消息路由过程和目的域的填充过程可能会受到用户名AVP NAI装饰[RFC5729]的影响。NAI装饰是请求消息源路由的一种形式，它定义了请求消息在路由到ER目的地之前必须经过的领域。参与请求消息路由的Diameter节点必须检查和处理用户名AVP，并相应地修改目标域AVP，只要修饰的NAI中还有域。基于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.
如果初始请求采用的路径遇到一个或多个参与ER代理和一个参与ER目的地，第4.2节和第4.3节中描述的程序确保对该请求的成功响应将包含一个显式路径AVP，其中包括一个或多个包含ER发起人身份、所有参与ER代理身份和ER目的地身份的显式路径记录。ER发起者应使用此初始应答消息中接收的显式路径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发端人应避免在后续请求消息中发送显式路径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
如果初始请求消息启动了显式路径发现，但应答消息中的显式路径AVP仅包含ER发起者和ER目的地的显式路径记录，这向ER发端人表明，没有能够沿路径参与ER的Diameter代理，并且ER发端人不应在该会话的后续请求消息中发送显式路径AVP。更多讨论见第4.5节。在这种情况下，情况可能是暂时的，并且
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.
显式路径发现可以在后续会话中找到参与的代理。由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发起人的本地缓存后，会话的所有请求消息必须包括使用本地缓存内容的显式路径AVP。显式路径AVP必须包含缓存中枚举的所有节点的显式路径记录，ER发起者本身的节点除外。显式路径AVP中枚举的标识必须按照在路由路径中遍历的顺序出现。显式路径AVP中的最后一个条目必须是ER目的地的显式路径记录。此外，必须从代理主机AVP的值以及（如果存在）显式路径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发端人以及ER发端人和第一个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.
第4.2节描述了第一个ER代理在收到消息后采取的后续行动，并将模仿ER发起人的行动。
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发起者接收到的后续请求消息的应答消息不应具有明确路径AVP。如果他们这样做，这应被视为可能由行为不端的ER参与者引起的可疑情况。当出现这种情况时，是继续使用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代理从显式路径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代理除了按照[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代理可以在转发请求之前将新的显式路径记录附加为显式路径AVP中的最后一个AVP。新的显式路径记录必须包含设置为代理身份的代理主机AVP，并且可能包含提供代理领域的代理领域AVP。然而，如果目标主机AVP存在并且与第一显式路径记录AVP的代理主机AVP匹配，则显式路径包含不包括ER代理的已经定义的源路由。ER代理应该像不存在ER路径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代理不希望参与ER，则不应修改显式路径AVP，而应使用目标主机和/或目标域AVP的现有值，简单地按照[RFC3588]中的规定处理和转发请求。不支持ER且不识别显式路径AVP的非ER代理和继电器将采取相同的操作。
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\u INVALID\u PROXY\u Path\u堆栈的应答消息发送回ER发起者（第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代理的标识与第一个显式路径记录匹配，则ER代理必须从显式路径AVP中删除该记录，并从显式路径AVP中存在的下一个显式路径记录中重新填充目标主机和目标域AVP。设置目标主机和可能的目标域AVP将确保ER代理以及当前ER代理和显式路径AVP中枚举的下一个ER代理之间的所有AAA中继将消息路由到下一个ER代理。删除ER代理记录的过程类似于从显式路径AVP表示的堆栈中弹出一个条目。
The behavior specified above also applies to a Diameter node that acts as a relay agent and participates in the ER scheme.
上面指定的行为也适用于充当中继代理并参与ER方案的Diameter节点。
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发起者（第4.1节）发送的请求并能够支持ER（ER目的地）的Diameter节点必须检查请求消息中是否存在显式路径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目的地必须简单地处理本地消费请求，并按照[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目的地必须检查其标识是否存在于显式路径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目的地必须将新的显式路径记录附加到所接收消息中的显式路径AVP。新的显式路径记录必须至少包含一个设置为ER目的地标识的代理主机AVP。然后，ER目的地必须将结果显式路径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中只有一条显式路径记录，则这表示显式路径发现成功，但没有参与的ER代理。ER目的地不应将显式路径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目的地支持ER，但不希望或不能参与，则可发送结果代码AVP，设置为第4.7节中定义的“直径\ ER \不可用”。ER目的地不得在后续应答中包含任何显式路径AVP。不支持ER且不识别显式路径AVP的Diameter服务器也将从应答消息中忽略显式路径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目的地的标识与显式路径AVP中的记录匹配，则它必须是显式路径AVP中存在的唯一显式路径记录。否则，这必须被视为一个错误，并且必须将设置了“E”位且包含实验结果代码AVP设置为DIAMETER\u INVALID\u PROXY\u PATH\u STACK的应答消息发送回ER发起者（第4.7节）。如果ER目的地的标识与唯一现有的显式路径记录匹配，则这表示请求通过成功执行的显式路由到达ER目的地。ER目的地不得在后续应答消息中包含显式路径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的Diameter节点不需要提供应答消息的特殊处理或路由。应答信息应按照[RFC3588]中的规定正常处理。然而，作为ER目的地的Diameter节点必须在应答消息中形成正确的显式路径AVP，如第4.3节所述。
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代理，则应答消息可能包含显式路径AVP，该路径AVP仅包含ER发起者和ER目的地的显式路由记录，指示路径上的Diameter节点中没有ER支持。由ER发起人在没有ER支持的情况下继续处理请求或终止会话。在这种情况下，ER发起人不应尝试在此会话的后续请求消息中执行显式路径发现，以防止出现故障回复情况，即ER代理突然出现在路径中，并尝试为初始请求以外的请求消息添加新的显式路径记录。
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代理接收会话的所有消息时，才允许ER代理在初始请求后加入会话才有意义。
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发起人可能会在后续会话中尝试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代理之前的Diameter节点中发生故障转移，则如果没有指向ER代理的替代路径，ER发起者可能会收到Diameter\u UNABLE\u TO\u DELIVER错误。在这种情况下，由ER发起人按照Diameter应用程序或[RFC3588]中的规定处理错误。
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）的类型为Group。此AVP的代理主机[RFC3588]元素中添加的标识必须与源主机AVP中Diameter节点在功能交换消息期间公布的标识相同。
Explicit-Path-Record ::= < AVP Header: 35001 >
{ Proxy-Host }
[ Proxy-Realm ]
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.
代理领域AVP（AVP代码35002）的类型为DiameterIdentity，包含插入记录的ER节点的领域。代理领域AVP可能存在于显式路径记录中。如果存在，则代理主机AVP值中包含的域名称必须与代理域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 ]
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处理过程中可能出现以下错误情况。所有错误指示必须封装在实验结果AVP[RFC3588]实例中，供应商ID AVP设置为2011，实验结果代码设置如下。
DIAMETER_INVALID_PROXY_PATH_STACK 3501
直径\u无效\u代理\u路径\u堆栈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代理或ER目的地接收的请求消息具有不匹配ER代理或ER目的地的标识的第一个或唯一的显式路径记录AVP。同样的错误也适用于ER目的地接收包含多个显式路径记录的显式路径AVP，或仅包含一个与其自身标识不匹配的显式路径记录的显式路径AVP。
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
直径不可用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.
这里给出的示例演示了Diameter消息流以及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发起人也可以使用预配置的缓存。ER发起人可以是发送请求的任何Diameter节点，即客户端、服务器或代理。在这种情况下，ER发起者的本地缓存最初是空的。
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.
ER代理、ER发起者和ER目的地之间的AAA中继可能存在，也可能不存在，并且在这里显示为描述请求在被参与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. | | |
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)
| | | | |
| | | | |
| | | | |
------------->|--------->| | | |
(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.
对于半径/直径相互作用，无需采取任何措施。本文档中描述的路由扩展对任何翻译网关都是透明的，并且仅与Diameter路由相关。假设Diameter翻译代理之间存在RADIUS代理链，则翻译代理之间的路由在会话期间保持稳定，不会导致代理路径堆栈无效。
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的操作来保证它能够监视会话的每条消息。这与普通直径路由不同，在普通直径路由中，一些消息可能通过备用路由传递。问题是发起方是否准备将这种额外的信任度扩展到沿途的任意方。如果不是，ER发起人需要一种机制来确定返回的显式路径AVP中列出的ER代理是否可以信任。如果具有这种机制，则可以从其缓存中删除不需要的ER代理，从而在后续请求中不会出现在ER Path AVP中。本规范假设发起方准备允许路径上任意直径的节点作为ER代理连接到会话，或者ER发起方在其缓存中维护预先配置的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.
潜在的拒绝服务攻击并不严重，因为可以更直接地获得相同的结果。沿原始请求路径控制Diameter节点的攻击者可以插入一条显式路径记录，其中包含另一个节点或不存在的节点的标识，而不是其自身的标识。通过另一个节点路由会话的后续消息可能会违反上游的信任假设。将后续消息路由到不存在的节点会导致它们丢失并终止会话。攻击者在被破坏的Diameter节点本身造成任何伤害似乎更简单。使用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.
作者感谢Tony Zhang、Fortune Huang、Rajith R、Victor Fajardo、Jouni Korhonen、Tolga Asveren、Mark Jones、Avi Lior、Steve Norreys、Lionel Morand、Dave Frascone和Hannes Tschofenig的贡献。
[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 57292009年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.02006。
Authors' Addresses
作者地址
Tina Tsou Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 USA
Tina Tsou Huawei Technologies（美国）美国加利福尼亚州圣克拉拉中央高速公路2330号，邮编95050
Phone: +1 408 330 4424
EMail: tena@huawei.com
URI: http://tinatsou.weebly.com/contact.html
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
格伦佐恩网络禅宗227/358泰国曼谷Thanon Sanphawut Bang Na 10260
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Phone: +66 (0) 87-040-4617
EMail: gwz@net-zen.net
Tom Taylor (editor) Huawei Technologies 1852 Lorraine Ave. Ottawa Canada
汤姆·泰勒（编辑）华为技术公司加拿大渥太华洛林大道1852号
EMail: tom111.taylor@bell.net
EMail: tom111.taylor@bell.net