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

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-dime-realm-based-redirect-00" ipr="trust200811">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>Realm-Based Redirection In Diameter</title>

    <author fullname="Tina Tsou" initials="T." role="editor"
            surname="Tsou">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Bantian, Longgang District</street>

          <!-- Reorder these if your country does things differently -->

          <city>Shenzhen</city>

          <code>518129</code>

          <country>P.R. China</country>
        </postal>

        <email>tena@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="June" year="2009" />

    <!-- Meta-data Declarations -->

    <area>Operations, Administartion and Maintenance</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>Diameter routing</keyword>

    <abstract>
      <t>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. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The usual redirect indication as described in <xref target="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.</t>

<t><xref target="considerata"/> discusses the considerations for a solution to the problem of satisfying this objective. <xref target="solution"/> proposes a specific solution.</t>

<t>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.</t>


      <section title="Requirements Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section>

    <section anchor="considerata" title="Considerations For a Solution">

<t>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 <xref target="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.</t>

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

<list style="numbers">
<t>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</t>

<t>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</t>

<t>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. </t>

</list>
 </t>

<t>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. </t>

<t>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. </t>

<t>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 <xref target="solution"/> is therefore based on the third approach.</t>

    </section>

<section anchor="solution" title="Specification of a Solution">

<t>This section specifies a solution to achieve realm-based routing. The elements of this solution are:
<list style="symbols">
<t>a new AVP, Redirection-Realm, to be inserted into redirect indications by the redirection agent; and </t>
<t>associated behaviour at a Diameter node capable of realm-based redirection when it receives a redirect indication.</t>
</list>
 </t>

<section anchor="AVPspec" title="The Redirect-Realm AVP">

<t>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.</t>

</section><!-- AVPspec -->

<section anchor="redAgent_behav" title="Behaviour at the Redirection Agent">

<t>A redirection agent conforming to this specification MAY insert a [one or more??] Redirect-Realm AVP in a redirect indication otherwise conforming to <xref target="RFC3588"/> if local policy so indicates.</t>

</section><!-- redAgent_behav -->

<section anchor="othNode_behav" title="Behaviour of Other Diameter Nodes">

<t>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.</t>

</section><!-- othNode_behav -->

</section><!-- solution -->

<section anchor="secur" title="Security Considerations">

<t>TBD</t>

</section><!-- secur -->

<section anchor="IANA" title="IANA Considerations">

<t>Add new AVP.</t>

</section><!-- IANA -->


  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC3588;
    </references>

  </back>
</rfc>