Realm-Based Redirection In Diameter
draft-tsou-dime-realm-based-redirect-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 14, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

A Diameter redirect agent can currently 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 the means by which this can be achieved.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Considerations For a Solution
3.  Specification of a Solution
    3.1.  The Redirect-Realm AVP
    3.2.  Behaviour at the Redirection Agent
    3.3.  Behaviour of Other Diameter Nodes
4.  Security Considerations
5.  IANA Considerations
6.  Normative References
§  Author's Address

1.  Introduction

The usual redirect indication as described in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) 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.

Section 2 (Considerations For a Solution) discusses the considerations for a solution to the problem of satisfying this objective. Section 3 (Specification of a Solution) proposes a specific solution.

Within this document, 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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Considerations For a Solution

The existing redirect mechanism relies on the use a specific Result-Code value, DIAMETER_REDIRECT_INDICATION (3006) to indicate redirection. Section 7.1.3 of [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) specifies that when this value is present in the response, the Redirect-Host AVP must also be present. The Redirect-Host AVP is of type Diameter-URI.

The basic problem is how to provide redirection service to upstream Diameter nodes in a backward-compatible fashion. Three basic approaches are possible:

1. the redirect agent is configured with the identities of the Diameter nodes to which it may be connected which can handle realm-based redirection; or
2. the upstream Diameter node indicates in advance that it is capable of handling a redirect indication indicating a realm rather than an individual host; or
3. the redirect indication contains the information needed for a 'legacy' Diameter node to redirect the message successfully (i.e., identifies one or more individual hosts), but also indicates that routing to the realm rather than an individual host would be preferable.

Note that regardless of which approach is used, the original operator cannot escape the necessity to specify at least one individual Redirect-Host in indications to upstream Diameter nodes that cannot handle realm-based redirection.

The second approach requires the upstream node to advertise its ability to handle realm-based redirection when establishing connections with peers -- that is, in the CER-CEA exchange. Advertising that ability simply by placing a new AVP in all requests passing through it is inefficient. It is also ineffective, since the new AVP will generally pass beyond the next Diameter node and provide a false indication to any redirect agent subsequent to that node.

The first and second approaches provide a cleaner solution than the third in the sense that the redirect agent does not have to identify both individual redirect hosts and an alternative realm in the same response. The second approach is preferable because it reduces administrative effort, but requires additional specification to define the signalling within the CER/CEA exchange and associated behaviour. The third approach requires the least amount of additional implementation effort. This seems more important than the processing and bandwidth cost of adding the alternative realm information to redirect responses. This solution specified in Section 3 (Specification of a Solution) is therefore based on the third approach.

3.  Specification of a Solution

This section specifies a solution to achieve realm-based routing. The elements of this solution are:

• a new AVP, Redirection-Realm, to be inserted into redirect indications by the redirection agent; and
• associated behaviour at a Diameter node capable of realm-based redirection when it receives a redirect indication.

3.1.  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 this AVP SHOULD route the original request instead of routing it to a host specified in a Redirect-Host AVP in the same redirect indication. The M and V flags for the Redirect-Realm AVP MUST NOT be set.

3.2.  Behaviour at the Redirection Agent

A redirection agent conforming to this specification MAY insert a [one or more??] Redirect-Realm AVP in a redirect indication otherwise conforming to [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) if local policy so indicates.

3.3.  Behaviour of Other Diameter Nodes

A Diameter node conforming to this specification which receives a redirect indication SHOULD scan the message to determine whether a Redirect-Realm AVP is present. If it finds a Redirect-Realm AVP, it SHOULD reroute the request to the indicated realm rather than the individual host(s) specified in Redirect-Host AVP(s) in the redirect indication.

4.  Security Considerations

TBD

5.  IANA Considerations

Add new AVP.

6. Normative References

Author's Address