| Internet Engineering Task Force | T. Tsou |
| Internet-Draft | Huawei Technologies (USA) |
| Updates: 6733 (if approved) | R. Hao |
| Intended status: Standards Track | Comcast Cable |
| Expires: October 31, 2013 | T. Taylor, Ed. |
| Huawei Technologies | |
| April 29, 2013 |
Realm-Based Redirection In Diameter
draft-ietf-dime-realm-based-redirect-08
The Diameter protocol allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document.
This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The usual redirect indication, as described in Section 6.1.8 and Sections 6.12-6.14 of [RFC6733], returns one or more individual host names to the upstream Diameter node. However, consider the case where an operator has offered a specific service but no longer wishes to do so. The operator has arranged for an alternative domain to provide the service. To aid in the transition to the new arrangement, the original operator maintains a redirect server to indicate the alternative destination to upstream nodes. However, the original operator has no interest in configuring a list of hosts in the alternative operator's domain, and would prefer simply to provide redirect indications to the domain as a whole.
As an example of another use case, consider a 3GPP IMS deployment where subscriber data is provisioned in a geo-redundant Home Subscriber Server (HSS) cluster for reliability. Each Application Server (AS) needs to maintain redundant Diameter Sh links to both cluster nodes for scalability. It is preferable that the AS should go to the local HSS cluster node when it is available. It would be useful for a cluster node to be able to redirect an AS request to its partner node in the cluster without specifying the individual Sh link to that alternate node. This could be accomplished by identifying each cluster node with a separate realm and individual Sh links with separate servers, and redirecting on the basis of realm rather than individual server. There can be multiple geo-redundant HSS clusters, in which case the Subscriber Location Function (SLF) performs the redirection.
Within this specification, the term "realm-based redirection" is used to refer to a mode of operation where the redirect indication specifies a realm and the upstream Diameter node reroutes the message to the realm rather than an individual host.
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].
Because realm-based redirection is not part of base Diameter behaviour, support for realm-based redirection by the agent MUST be specified as part of particular applications. In this way, Diameter's capability negotiation mechanism can be used indirectly to indicate support for realm-based redirection by indicating support for the applications concerned. Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document.
The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent, but instead must be performed by a Diameter server. However, despite the change in executing role, the behaviour itself is a slight modification of the behaviour of a redirect agent as described in Section 2.8.3 of [RFC6733].
An application can specify that realm-based redirection operates only on the initial message of a session, or on any message of a session. In the former case, existing sessions will not be disrupted by the deployment of realm-based redirection. In the latter case, existing sessions will be disrupted if they are stateful.
This section specifies an extension to [RFC6733] to achieve realm-based redirection. The elements of this solution are:
Section 3.2.2 and Section 3.2.3 describe how a proxy or client may update its routing table for the application and initial realm, as a result of selecting a peer in the new realm. Note that as a result, the proxy or client will automatically route subsequent requests for that application to the new realm (with the possible exception of requests within sessions already established with the initial realm) until the cached routing entry expires. This should be borne in mind if the rerouting is intended to be temporary.
A Diameter server MUST be configured as follows to execute realm-based redirection:
As mentioned in Section 2, an application incorporating realm-based redirection may specify that redirection applies for any request or only for the initial request of a session (i.e., to prevent disruption of established sessions).
If a server configured as described in Section 3.1 receives a request to which realm-based redirection applies, the server MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header. The server MUST include the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION. The server MUST also include the alternate realm identifier(s) with which it has been configured, each in a separate Redirect-Realm AVP instance.
The server MAY include a copy of the Redirect-Host-Usage AVP, which SHOULD be set to REALM_AND_APPLICATION. If this AVP is added, the Redirect-Max-Cache-Time AVP MUST also be included. Note that these AVPs apply to the peer discovered by a node acting on the server's response, as described in the next section. This is an extension of their normal usage as described by Sections 6.13 and 6.14 of [RFC6733].
A proxy conforming to this specification that receives an answer message with the Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION MAY attempt to reroute the original request to a server in a realm identified by a Redirect-Realm AVP instance in the answer message, or MAY simply forward the message to the upstream peer. If it chooses to reroute the request, it MUST take the following steps:
A client conforming to this specification MUST be prepared to receive either an answer message containing a Result-Code AVP set to DIAMETER_REALM_REDIRECT_INDICATION, or, as the result of proxy action, some other result from a realm differing from the one to which it sent the original request. In the case where it receives DIAMETER_REALM_REDIRECT_INDICATION, the client SHOULD follow the same steps prescribed in the previous section for a proxy, in order both to update its routing table and to obtain service for the original request.
The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It specifies a realm to which a node receiving a redirect indication containing the result code value DIAMETER_REALM_REDIRECT_INDICATION and the Redirect-Realm AVP SHOULD route the original request. The M flag for the Redirect-Realm AVP MUST be set, and the V flag MUST NOT be set.
The DIAMETER_REDIRECT_INDICATION (3xxx TBD) error code indicates that a server has determined that the request within an application supporting realm-based redirection could not be satisfied locally and the initiator of the request SHOULD direct the request directly to a peer within a realm that has been identified in the response. When set, the Redirect-Realm AVP MUST be present.
Realm-based redirection implies a potential change in business relationships, the authorization checks described in Section 2.9 of [RFC6733].
This specification adds a new AVP code [TBD] Redirect-Realm in the AVP Code registry under Authentication, Authorization, and Accounting (AAA) Parameters.
This specification allocates a new Result-Code value DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD) in the Result-Code AVP Values (code 268) - Protocol Errors registry under Authentication, Authorization, and Accounting (AAA) Parameters.
Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones, Victor Fajardo, Jouni Korhonen, Avi Lior, and Lionel Morand contributed comments that helped to shape this document.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC6733] | Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. |