[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-tsou-dime-realm-based-redirect) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 7075

Internet Engineering Task Force                                  T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Standards Track                                  R. Hao
Expires: January 17, 2013                                  Comcast Cable
                                                          T. Taylor, Ed.
                                                     Huawei Technologies
                                                           July 16, 2012


                  Realm-Based Redirection In Diameter
                draft-ietf-dime-realm-based-redirect-05

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.

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 January 17, 2013.

Copyright Notice

   Copyright (c) 2012 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



Tsou, et al.            Expires January 17, 2013                [Page 1]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Support of Realm-Based Redirection Within Applications  . . . . 3
   3.  Realm-Based Redirection . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Configuration of the Redirecting Server . . . . . . . . . . 4
     3.2.  Behaviour of Diameter Nodes . . . . . . . . . . . . . . . . 4
       3.2.1.  Behaviour at the Redirecting Server . . . . . . . . . . 4
       3.2.2.  Proxy Behaviour . . . . . . . . . . . . . . . . . . . . 5
       3.2.3.  Client Behaviour  . . . . . . . . . . . . . . . . . . . 6
     3.3.  The Redirect-Realm AVP  . . . . . . . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7


























Tsou, et al.            Expires January 17, 2013                [Page 2]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


1.  Introduction

   The usual redirect indication, as described in Section 6.1.8 and
   Sections 6.12-6.14 of [RFC3588bis], 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.

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



Tsou, et al.            Expires January 17, 2013                [Page 3]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


   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.


3.  Realm-Based Redirection

   This section specifies an extension to [RFC3588bis] 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.

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

3.2.1.  Behaviour at the Redirecting Server

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



Tsou, et al.            Expires January 17, 2013                [Page 4]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


   If a server configured as described in Section 3.1 receives a request
   for which the indicated local action is to perform realm-based
   redirection, the server MUST proceed as follows:

   o  If the request contains a Destination-Host AVP, the server MUST
      set the 'E' bit in the answer and set the Result-Code AVP to
      DIAMETER_UNABLE_TO_DELIVER.

   o  Otherwise, 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 identifiers 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.

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.  If it does so, 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.  Verify that the new realm is authorized to provide the requested
       service on behalf of the realm specified in the original request.

   3.  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 [RFC3588bis].

   4.  If again successful:

       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.





Tsou, et al.            Expires January 17, 2013                [Page 5]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


       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.

   5.  If any of the preceding steps 2-4 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-4 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.  In other cases, the client SHOULD verify that the realm
   from which it received the response is authorized to act on behalf of
   the realm to which it directed the original request.  If this
   authorization fails, the response SHOULD be ignored.

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.


4.  Security Considerations

   Because realm-based redirection implies a change in business
   relationships, the node acting on the redirect indication SHOULD
   verify that the new realm is authorized to perform the requested
   service.  Similarly the originator of the request SHOULD perform an
   authorization check of the path as described in Section 2.10 of
   [RFC3588bis].






Tsou, et al.            Expires January 17, 2013                [Page 6]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


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.

   [RFC3588bis]
              Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", June 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 January 17, 2013                [Page 7]

Internet-Draft     Realm-Based Redirection In Diameter         July 2012


   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 January 17, 2013                [Page 8]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/