<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-dime-overload-reqs PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-overload-reqs.xml">
<!ENTITY I-D.korhonen-dime-e2e-security PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.korhonen-dime-e2e-security.xml">
<!ENTITY RFC6733 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
]>

<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?> 
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>

<rfc category='std' ipr='trust200902' docName='draft-tschofenig-dime-overload-piggybacking-00.txt'>

  <front>
    <title>Diameter Overload Piggybacking</title>

    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>	
    <date year='2013'/>
    <area>OPS</area>
    <workgroup>DIME</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>Diameter</keyword>
    <keyword>Overload</keyword>
    <keyword>Load Balancing</keyword>

    <abstract>
      <t>This document describes how to piggyback Diameter overload information between Diameter servers and Diameter clients.</t>
  </abstract>
  </front>
  <middle>
    
    <section title='Introduction'>
      
 <t>The problem statement for Diameter overload control can be found in <xref target="I-D.ietf-dime-overload-reqs"/>. 
  It describes the lack of support of conveying load information to enable load balancing of Diameter requests in case Diameter servers 
  become overload and the inability of Diameter servers to communicate with Diameter clients to reject requests when they become 
  severely overloaded. <xref target="I-D.tschofenig-dime-overload-arch"/> goes a step further in providing an outline of architectural principles and an information model.</t>
    
  <t>
  This document is an extension to <xref target="I-D.tschofenig-dime-overload-arch"/> and defines how Diameter servers interact with Diameter clients to report about overload 
  situations. This is accomplished by piggybacking overload information from the Diameter server to the Diameter client within existing Diameter applications, as long as extension points allow adding new AVPs.</t>
  
    <t>Communication overload information to Diameter clients is the last resource when load balancing is either not available, when all available servers are already overloaded, or when a critical failure occurred since this will lead to the Diameter client rejecting requests and returning appropriate error messages to end devices via the front-end protocols (such as SIP).</t>

  </section>
	  
	  <!-- ******************************************************* --> 
      
      
      <section title='Terminology'>
        <t>
          The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD',
          'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this specification are to be
          interpreted as described in <xref target='RFC2119' />.
        </t>
		<t>This document re-uses terminology from the Diameter base specification <xref target="RFC6733"/>.</t>
		
			 </section>

      <!-- ******************************************************* --> 
      
	  <section title="Information Exchanges"> 

      
      <section title="Capability Indication"> 
      
      <t>The Diameter protocol interaction starts with a Diameter client using some Diameter application. The Diameter client MUST add the Supported-Features AVP to indicate support for the functionality supported for overload control. The Supported-Features AVP MUST NOT have the M-bit set since this would require a Diameter application to be defined.</t> 
      
      <t>A Diameter server receiving the Supported-Features AVP from a client is therefore able to know that this client supports the Diameter overload information exchange capability. Otherwise only the Diameter Base protocol functionality <xref target="RFC6733"/> with DIAMETER_TOO_BUSY error message is available. This enables feature discovery and a graceful fall-back to the functionality available with the Diameter Base protocol</t> 
      
      </section> 

      <section title="Overload Information"> 
      
      <t>In the rare and unlikely event of an overload situation the Diameter server (or a proxy, such as a load balancer, acting on behalf of several Diameter servers) may decide to communicate to the Diameter client to reject some or even all Diameter requests. The Diameter server does so by adding the Overload-Info AVP, which contains the Overload and the Period-Of-Validity AVP. The semantic of the Overload and the Period-Of-Validity AVP is described in <xref target="I-D.tschofenig-dime-overload-arch"/>. To inform the Diameter client to reject requests the value of the Overload AVP is set to 'INCREASING_OVERLOAD' or to 'OVERLOADED'. The Diameter server may instruct the client to gradually reduce the number of requests by using the Overload='INCREASING_OVERLOAD' marking on several subsequent messages. The Period-Of-Validity AVP allows the Diameter server to give the "rejection policy" a soft-state nature, i.e., it will automatically expire without leaving orphan state at the Diameter client in case of a Diameter server failure or other error situations.</t> 

      <t>A Diameter client that has received information to reduce the number of Diameter requests has to evaluate the requests based on their destination and their applications.</t> 
            
      <t>In case the Diameter server recovers and is able to accept more Diameter requests it can signal this changed state to the client with the 'DECREASING_OVERLOAD' or the 'NO_OVERLOAD' directive. Waiting for the expiry of the state is another option at the disposal of the Diameter server.</t> 
      
      </section> 
  
  </section> 
  
<!-- ******************************************************* --> 
      
      
    <section title='Security Considerations' anchor='Security'>
  <t>This document utilizes the AVP defined in <xref target="I-D.tschofenig-dime-overload-arch"/>. The ability to use end-to-end signaling allows the Diameter AVP level security mechanisms, described in <xref target="I-D.korhonen-dime-e2e-security"/>, to be re-used. Since the communicated rejection policies are bound to the application and the realm from an earlier request the ability to inject fake message is less likely.</t> 
    </section>

<!-- ******************************************************* --> 
      
      
    <section title='IANA Considerations' anchor='IANA'>
	 <t>This document does not require actions by IANA.</t>
    </section>

<!-- ******************************************************* --> 
      
    <section title='Acknowledgments'>
	     <t>Add your name here.</t>
    </section>

<!-- ******************************************************* --> 
      
  </middle>

  <back>

    <references title='Normative References'>
   &RFC2119; 
   &RFC6733; 
  
    </references>

    <references title='Informative References'>
    &I-D.ietf-dime-overload-reqs; 
    &I-D.korhonen-dime-e2e-security; 
    <reference anchor="I-D.tschofenig-dime-overload-arch">
      <front>
       <title>Diameter Overload Architecture and Information Model</title>
       <author fullname="Hannes Tschofenig" initials="Hannes" surname="Tschofenig"> </author>
       <date year="2013" month="July"/>
      </front>
     </reference>
     
    </references>
  </back>

</rfc>
