One document matched: draft-tsou-dime-realm-based-redirect-00.txt

Internet Engineering Task Force                             T. Tsou, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                             June 11, 2009
Expires: December 13, 2009


                  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 13, 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



Tsou                    Expires December 13, 2009               [Page 1]

Internet-Draft     Realm-Based Redirection In Diameter         June 2009


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Considerations For a Solution . . . . . . . . . . . . . . . . . 3
   3.  Specification of a Solution . . . . . . . . . . . . . . . . . . 4
     3.1.  The Redirect-Realm AVP  . . . . . . . . . . . . . . . . . . 5
     3.2.  Behaviour at the Redirection Agent  . . . . . . . . . . . . 5
     3.3.  Behaviour of Other Diameter Nodes . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5

































Tsou                    Expires December 13, 2009               [Page 2]

Internet-Draft     Realm-Based Redirection In Diameter         June 2009


1.  Introduction

   The usual redirect indication as described in [RFC3588] 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 discusses the considerations for a solution to the problem
   of satisfying this objective.  Section 3 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 [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] 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



Tsou                    Expires December 13, 2009               [Page 3]

Internet-Draft     Realm-Based Redirection In Diameter         June 2009


       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 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:

   o  a new AVP, Redirection-Realm, to be inserted into redirect
      indications by the redirection agent; and

   o  associated behaviour at a Diameter node capable of realm-based
      redirection when it receives a redirect indication.







Tsou                    Expires December 13, 2009               [Page 4]

Internet-Draft     Realm-Based Redirection In Diameter         June 2009


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] 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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.









Tsou                    Expires December 13, 2009               [Page 5]

Internet-Draft     Realm-Based Redirection In Diameter         June 2009


Author's Address

   Tina Tsou (editor)
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: tena@huawei.com










































Tsou                    Expires December 13, 2009               [Page 6]