One document matched: draft-tschofenig-dime-dlba-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC6733 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733'>
<!ENTITY I-D.ietf-dime-overload-reqs PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-overload-reqs'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc ipr="trust200902"
category="std" docName="draft-tschofenig-dime-dlba-00.txt">
<front>
<title abbrev="DLBA">The Diameter Load Balancing Application (DLBA)</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>Operations and Management</area>
<workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Diameter</keyword>
<keyword>Load Balancing</keyword>
<abstract>
<t>This specification documents a Diameter Load Balancing Application
(DLBA), which uses the normal Diameter application approach for the capability
negotiation, propagation and management of Diameter load information between
Diameter nodes to enable load balancing of Diameter requests.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" 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 specifies Diameter Load Balancing Application
(DLBA), which uses the AVPs defined in <xref target="I-D.tschofenig-dime-overload-arch"/>. As the name indicates, this document focuses on load balancing.
</t>
<t>The Diameter Load Balancing Application
(DLBA) typically runs between a load balancer and a Diameter server. The load balancer may act as a DLBA client and the Diameter server as a DLBA server but the roles may also be reversed without loss in protocol functionality since Diameter is flexible as a protocol.
There may be zero or more intermediate Diameter agents on the path between
the DLBA client and the DLBA server. Understanding the DLBA functionality is not
expected from relays and redirect agents.</t>
<t>The main usage for this application is within a single realm, as shown in Figure 2 of <xref target="I-D.tschofenig-dime-overload-arch"/>, where a load balancer distributes
incoming Diameter requests to different Diameter servers. Designing the load balancing functionality as a stand-alone application prevents
Diameter servers and load balancers to adjust their information exchange frequency to meet the needs of the network administrator regardless
of remaining Diameter application traffic.</t>
</section>
<!-- ******************************************************************** -->
<section title="Requirements">
<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 title="Commands" anchor="command-codes">
<t>The DLBA-Report-Request message is used to request load
information.
</t>
<t>
<figure><artwork><![CDATA[
<DLBA-Report-Request> ::= < Diameter Header: TBD2, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
{ Destination-Host }
[ Auth-Session-State ]
* [ Class ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
[ Supported-Features ]
[ Sending-Rate ]
[ Load-Info ]
* [ AVP ]
]]></artwork></figure>
</t>
<t>The DLBA-Report-Answer message is used
as a response to the DLBA-Report-Request. The message MAY piggyback load
information in order to avoid unnecessary DLBA-Report-Request
messages in the reverse direction.</t>
<t>
<figure><artwork><![CDATA[
<DLBA-Report-Answer> ::= < Diameter Header: TBD2, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Auth-Session-State ]
* [ Class ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
[ Supported-Features ]
[ Sending-Rate ]
[ Load-Info ]
* [ AVP ]
]]></artwork></figure>
</t>
<t> Diameter
is flexible from a message handling point of view. Therefore, any the DLBA capable Diameter
node, such as a load balancer or a Diameter server, MAY initiate a DLBA-Report-Request at any given time.
The receiver of
the DLBA-Report-Request responds with a DLBA-Report-Answer and includes
the Result-Code AVP indicating whether it
could honor the action/report in the request. The DLBA-Report-Answer SHOULD
also piggyback load information.
</t>
<t>A DLBA client MUST
set the Auth-Session-State AVP to the value NO_STATE_MAINTAINED and SHOULD
include load information into the
DLBA-Report-Request message, if available. The
DLBA-Report-Response message MUST contain the Auth-Session-State AVP set to
value NO_STATE_MAINTAINED.
</t>
</section>
<section title="Attribute Value Pair Flag Rules">
<t>
<figure><artwork><![CDATA[
+---------+
|AVP flag |
|rules |
+----+----+
AVP Defined | |MUST|
Attribute Name Code in Value Type |MUST| NOT|
+-----------------------------------------------------+----+----+
|Load-Info TBD RFC XYZ Grouped | M | V |
+-----------------------------------------------------+----+----+
|Load TBD RFC XYZ Unsigned32 | M | V |
+-----------------------------------------------------+----+----+
|Supported-Features TBD RFC XYZ Uint64 | M | V |
+-----------------------------------------------------+----+----+
|Sending-Rate TBD RFC XYZ Unsigned32 | M | V |
+-----------------------------------------------------+----+----+
]]></artwork></figure>
</t>
<t>All AVPs are defined in <xref target="I-D.tschofenig-dime-overload-arch"/>.</t>
</section>
<section title="Example">
<t>This example shows the simplicity of the DLBA application. Here the load balancer initiates the DLBA exchange and solicits load information from a Diameter server. The rate at which these messages are exchange depend on the Sending-Rate AVP. The Diameter server may, however, at any time send an unsolicited DLBA-Report-Request message in case the load situation changes unexpectedly.
</t>
<t>
<figure><artwork><![CDATA[
Diameter-based Diameter
Load Balancer Server
| |
| DLBA-Report-Request Command |
| Supported-Features AVP |
| Sending-Rate AVP |
|------------------------------>|
| |
| |
| DLBA-Report-Answer Command |
| Load AVP |
|<------------------------------|
| |
: :
: :
| |
|...more load info exchanges... |
| |
| |
]]></artwork></figure>
</t>
</section>
<section title="Transport Considerations" anchor="sctp">
<t>In case of Stream Control Transmission Protocol (SCTP) transport,
it is RECOMMENDED to mark Diameter packets using
the DLBA defined SCTP Payload Protocol Identifier (PPID) TBD1. The PPID MAY
be used by intermediating network nodes or agents to peek into SCTP
message and find out that this is about overload control. Such information
can be used for prioritizing SCTP packet handling as an example.
</t>
</section>
<section title="IANA Considerations">
<section title="Application Identifiers">
<t>This specification reserves a new Diameter Application-ID TBD14 for
the Diameter Load Balancing Application (DLBA) from the 'Authentication,
Authorization, and Accounting (AAA) Parameters' Application IDs registry.
</t>
</section>
<section title="SCTP Payload Protocol Identifier">
<t><xref target="sctp"/> reserves a new SCTP Payload Protocol
Identifier for the DLBA application usage. The value is reserved from
the existing SCTP Payload Protocol Identifiers registry.
</t>
</section>
<section title="Command Codes">
<t>Two command codes are defined in <xref target="command-codes"/>.
The DLBA-Report-Request Command Code is TBD and the DLBA-Report-Answer Command Code is TBD.
Both are allocated
from the 'Authentication, Authorization, and Accounting (AAA) Parameters'
Command Codes registry.
</t>
</section>
<section title="Result-Code Values">
<t>This specification adds Diameter Overload Control Application
specific Permanent Failure codes from the 'Authentication, Authorization,
and Accounting (AAA) Parameters' Result-Code AVP Values (code 268) -
Permanent Failure registry:
</t>
<figure><artwork><![CDATA[
AVP Values | Attribute Name | Reference
-----------+-------------------------------+----------
5xxx | DIAMETER_RATE_TOO_BIG | RFCxxxx
5xxx | DIAMETER_NO_COMMON-FEATURES | RFCxxxx
]]></artwork></figure>
</section>
</section>
<section title="Security Considerations">
<t>This Diameter application uses the Diameter <xref target="RFC6733"/> security mechanisms and, what is more important,
is primarily used within a single realm to allow a load balancer to obtain load information from Diameter servers for
distributing Diameter requests depending on the utilization of these servers. Passing load information beyond an administrative
domain is possible with Diameter but not advisable to avoid leaking valuable information to potentially untrustworthy parties.
</t>
</section>
<section title="Acknowledgements">
<t>This document re-uses the design from the Diameter-OVL application.
</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&RFC2119;
&RFC6733;
</references>
<references title="Informative References">
&I-D.ietf-dime-overload-reqs;
<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>
| PAFTECH AB 2003-2026 | 2026-04-22 16:20:54 |