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
Abstract
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.
Status of This Memo
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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tsou, et al. Expires October 31, 2013 [Page 1]
Internet-Draft Realm-Based Redirection In Diameter April 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Support of Realm-Based Redirection Within
Applications . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Realm-Based Redirection . . . . . . . . . . . . . . . . . . . 3
3.1. Configuration of the Redirecting Server . . . . . . . . . 4
3.2. Behaviour of Diameter Nodes . . . . . . . . . . . . . . . 4
3.2.1. Behaviour at the Redirecting Server . . . . . . . . . 5
3.2.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . 5
3.2.3. Client Behaviour . . . . . . . . . . . . . . . . . . 6
3.3. The Redirect-Realm AVP . . . . . . . . . . . . . . . . . 6
3.4. DIAMETER_REDIRECT_INDICATION Error Code . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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
Tsou, et al. Expires October 31, 2013 [Page 2]
Internet-Draft Realm-Based Redirection In Diameter April 2013
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.
1.1. Requirements Language
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].
2. Support of Realm-Based Redirection Within Applications
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.
3. Realm-Based Redirection
Tsou, et al. Expires October 31, 2013 [Page 3]
Internet-Draft Realm-Based Redirection In Diameter April 2013
This section specifies an extension to [RFC6733] to achieve realm-
based redirection. The elements of this solution are:
o a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD);
o one new attribute-value pair (AVP), Redirect-Realm; and
o associated behaviour at Diameter nodes implementing this
specification. This behaviour includes the optional use of the
Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. In this
document, these AVPs apply to the peer discovered by a node acting
on the server's response, an extension to their normal usage as
described in Sections 6.13 and 6.14 of [RFC6733].
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.
3.1. Configuration of the Redirecting Server
A Diameter server MUST be configured as follows to execute realm-
based redirection:
o configured with an application that incorporates realm-based
redirection;
o the Local Action field of the routing table described in
Section 2.7 of [RFC6733] is set to LOCAL;
o an application-specific field is set to indicate that the required
local action is to perform realm-based redirection;
o an associated application-specific field is configured with the
identities of one or more realms to which the request should be
redirected.
3.2. Behaviour of Diameter Nodes
Tsou, et al. Expires October 31, 2013 [Page 4]
Internet-Draft Realm-Based Redirection In Diameter April 2013
3.2.1. Behaviour at the Redirecting Server
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].
If the redirected request contained a Destination-Host AVP, that
AVP is ignored by the server.
3.2.2. Proxy Behaviour
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:
1. Select a specific realm from amongst those identified in
instances of the Redirect-Realm AVP in the answer message.
2. If successful, locate and establish a route to a peer in the
realm given by the Redirect-Realm AVP, using normal discovery
procedures as described in Section 5.2 of [RFC6733].
3. If again successful:
Tsou, et al. Expires October 31, 2013 [Page 5]
Internet-Draft Realm-Based Redirection In Diameter April 2013
a. update its cache of routing entries for the realm and
application to which the original request was directed,
taking into account the Redirect-Host-Usage and Redirect-Max-
Cache-Time AVPs, if present in the answer.
b. Remove the Destination-Host (if present) and Destination-
Realm AVPs from the original request and add a new
Destination-Realm AVP containing the realm selected in the
initial step.
c. Forward the modified request.
4. If either of the preceding steps 2-3 fail and additional realms
have been identified in the original answer, select another
instance of the Redirect-Realm AVP in that answer and repeat
steps 2-3 for the realm that it identifies.
3.2.3. Client Behaviour
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.
3.3. The Redirect-Realm AVP
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.
3.4. DIAMETER_REDIRECT_INDICATION Error Code
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.
Tsou, et al. Expires October 31, 2013 [Page 6]
Internet-Draft Realm-Based Redirection In Diameter April 2013
4. Security Considerations
Realm-based redirection implies a potential change in business
relationships, the authorization checks described in Section 2.9 of
[RFC6733].
5. IANA Considerations
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.
6. Acknowledgements
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.
7. Normative References
[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.
Authors' Addresses
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: Tina.Tsou.Zouting@huawei.com
URI: http://tinatsou.weebly.com/contact.html
Tsou, et al. Expires October 31, 2013 [Page 7]
Internet-Draft Realm-Based Redirection In Diameter April 2013
Ruibing Hao
Comcast Cable
One Comcast Center
Philadelphia, PA 19103
USA
Phone: +1 215 286 3991(O)
Email: Ruibing_Hao@cable.comcast.com
Tom Taylor (editor)
Huawei Technologies
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
Tsou, et al. Expires October 31, 2013 [Page 8]