Internet DRAFT - draft-tschofenig-dime-dlba
draft-tschofenig-dime-dlba
Diameter Maintenance and Extensions (DIME) H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track July 16, 2013
Expires: January 17, 2014
The Diameter Load Balancing Application (DLBA)
draft-tschofenig-dime-dlba-00.txt
Abstract
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.
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, 2014.
Copyright Notice
Copyright (c) 2013 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
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.
Tschofenig Expires January 17, 2014 [Page 1]
Internet-Draft DLBA July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Transport Considerations . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7.1. Application Identifiers . . . . . . . . . . . . . . . . . 5
7.2. SCTP Payload Protocol Identifier . . . . . . . . . . . . 6
7.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 6
7.4. Result-Code Values . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
The problem statement for Diameter overload control can be found in
[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.
[I-D.tschofenig-dime-overload-arch] goes a step further in providing
an outline of architectural principles and an information model.
This document specifies Diameter Load Balancing Application (DLBA),
which uses the AVPs defined in [I-D.tschofenig-dime-overload-arch].
As the name indicates, this document focuses on load balancing.
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.
The main usage for this application is within a single realm, as
shown in Figure 2 of [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
Tschofenig Expires January 17, 2014 [Page 2]
Internet-Draft DLBA July 2013
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.
2. Requirements
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].
3. Commands
The DLBA-Report-Request message is used to request load information.
<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 ]
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.
<DLBA-Report-Answer> ::= < Diameter Header: TBD2, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Auth-Session-State ]
* [ Class ]
[ Error-Message ]
Tschofenig Expires January 17, 2014 [Page 3]
Internet-Draft DLBA July 2013
[ 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 ]
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.
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.
4. Attribute Value Pair Flag Rules
+---------+
|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 |
+-----------------------------------------------------+----+----+
All AVPs are defined in [I-D.tschofenig-dime-overload-arch].
Tschofenig Expires January 17, 2014 [Page 4]
Internet-Draft DLBA July 2013
5. Example
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.
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... |
| |
| |
6. Transport Considerations
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.
7. IANA Considerations
7.1. Application Identifiers
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.
Tschofenig Expires January 17, 2014 [Page 5]
Internet-Draft DLBA July 2013
7.2. SCTP Payload Protocol Identifier
Section 6 reserves a new SCTP Payload Protocol Identifier for the
DLBA application usage. The value is reserved from the existing SCTP
Payload Protocol Identifiers registry.
7.3. Command Codes
Two command codes are defined in Section 3. 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.
7.4. Result-Code Values
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:
AVP Values | Attribute Name | Reference
-----------+-------------------------------+----------
5xxx | DIAMETER_RATE_TOO_BIG | RFCxxxx
5xxx | DIAMETER_NO_COMMON-FEATURES | RFCxxxx
8. Security Considerations
This Diameter application uses the Diameter [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.
9. Acknowledgements
This document re-uses the design from the Diameter-OVL application.
10. References
Tschofenig Expires January 17, 2014 [Page 6]
Internet-Draft DLBA July 2013
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
10.2. Informative References
[I-D.ietf-dime-overload-reqs]
McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", draft-ietf-dime-overload-reqs-07 (work in
progress), June 2013.
[I-D.tschofenig-dime-overload-arch]
Tschofenig, Hannes., "Diameter Overload Architecture and
Information Model", July 2013.
Author's Address
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Tschofenig Expires January 17, 2014 [Page 7]
