Internet DRAFT - draft-tschofenig-dime-overload-arch
draft-tschofenig-dime-overload-arch
DIME H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track July 16, 2013
Expires: January 17, 2014
Diameter Overload Architecture and Information Model
draft-tschofenig-dime-overload-arch-00.txt
Abstract
This document describes the architecture for Diameter overload
control architecture in form of principles and presents an
information model.
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-DraDiameter Overload Architecture and Information Mo July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Architectural Principles . . . . . . . . . . . . . . . . . . 3
4. Information Exchanges . . . . . . . . . . . . . . . . . . . . 4
4.1. End-to-End Overload Feedback . . . . . . . . . . . . . . 4
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 5
5. Information Elements . . . . . . . . . . . . . . . . . . . . 6
5.1. Capability Indication . . . . . . . . . . . . . . . . . . 6
5.2. Information for Rejecting Diameter Requests . . . . . . . 6
5.3. Information Elements for Load Balancing . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. Overload Capability Registry . . . . . . . . . . . . . . 9
7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Diameter was developed to provide an Authentication, Authorization,
and Accounting (AAA) framework for a number of applications,
including network access, mobility, and real-time multimedia
application layer services. Over the last 10 years it has enjoyed
widespread industry acceptance and can be found in many large
(mobile) operator networks.
When a Diameter server becomes overloaded, it may need to ask
Diameter clients and agents to gracefully reduce the amount of
signaling traffic destined for it. For Diameter clients and agents
that are asked to reduce traffic there are two basic approaches for
doing so:
o by sending a portion of new requests to other Diameter servers
which still have capacity available (load balancing), and
o by rejecting new requests.
[3] aims to provide background information and requirements. This
document defines the next step, namely the architecture and the
information model.
2. Terminology
Tschofenig Expires January 17, 2014 [Page 2]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
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 [1].
This document re-uses terminology from the Diameter base
specification [2].
The term "load balancer" in this document refers to a Diameter proxy
that uses load information received from Diameter servers and
configuration settings to adjust standard Diameter routing.
3. Architectural Principles
This section outlines several principles guiding the solution design.
Avoid premature optimizations. Diameter is an extensible protocol
and new extensions can be added at any time (when necessary).
Instead of developing the most "complete" solution there are
benefits from starting with a minimal core that helps to gain
initial implementation and deployment experience. This minimal
core can then be used as a basis for subsequent refinements.
Complexity often comes with optimizations and constraints imposed
by incremental deployment strategies.
Focus on real-world problems. The number of theoretical use cases is
large, almost unbounded. What use cases and optimizations are
worthwhile to explore and to standardize solutions for? Is the
"sounds good" test enough or is evidence of a documented and
reproducible real-world problem needed?
Overload conditions are rare events. The Diameter backend
infrastructure is hopefully dimensioned in a way that overload
situations are the exception rather than the norm. Consequently,
it is less useful to develop many optimization for those rare
events (e.g., optimizations in the form of message reduction).
Instead, it is more beneficial to optimize for the case where
there is no overload.
Consider advances in information technology. At the time of writing
cloud computing and virtualization has gained widespread industry
interest, even in the telecommunication sector. These new
computing paradigms provide built-in support for handling load
variation (e.g., by spawning new virtual machines or migrating
code). The orchestration and management of these virtual machine
instances is often provided in a centralized fashion using a
hypervisor and these hypervisors come with management interfaces
that obtain load and other status information from their virtual
machine instances. It is not unlikely that these developments
will also impact deployments of Diameter servers within a single
administrative domain.
Tschofenig Expires January 17, 2014 [Page 3]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
Load Balancing and Rejecting Requests are different. Load balancing
is a technique that is best applied within a local administrative
domain to re-distribute requests. For maximum benefit knowledge
by the load balancer about the system architecture and the nature
of applications is required. Rejecting requests, on the other
hand, requires information signaling to the Diameter clients since
Diameter is not an end-to-end protocol and information about the
failure situation needs to be passed along to the source of the
end system, such as VoIP phones initiating phone calls, end
devices seeking network access.
Delegating rejection policies creates a lot of complexity. When a
Diameter server reaches an overload state and wants to reduce the
number of requests it gets it has a number of choices. In the
simplest form it could return reject responses without engaging in
heavy application specific processing. In such a model the
Diameter server acts as a Policy Decision Point (PDP) and as a
Policy Enforcement Point (PEP). By co-locating the PEP and the
PDP the decision making is implementation internal, which is also
the beautify of this model. If the PEP functionality, however,
gets moved to the Diameter client (or to any other node) the need
for standardizing a "Diameter request rejection policy language"
arises. Delegating functionality from the PDP to the PEP requires
the PEP to have a reasonable amount of information about the
problem the Diameter server and the support infrastructure is
facing. Additionally, the PEP would benefit from knowing about
the tradeoff decisions the network operators wants to make
regarding the different types of requests.
4. Information Exchanges
4.1. End-to-End Overload Feedback
The information elements described in this document follow the
pattern shown in Figure 1. Following the exchange of Diameter
application messages between a Diameter client and a Diameter server
(through zero or more Diameter intermediaries) a Diameter server may
indicate that it is currently suffering an overload situation. To
ensure that the load information is understood by the Diameter client
a prior capability exchange is provided.
Overload + Rejection
Information Policies
+-------+ +***************************************+
| End | * *
| Point | * *
+-------+ * Capability Indication *
^ * +------------------------+ *
Tschofenig Expires January 17, 2014 [Page 4]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
| * | | *
| v | v *
|Front-End +------------+ Diameter Msg +------------+
|Protocol | Diameter | Exchanges | Diameter |
+--------->| Client |<----------------->| Server |
+------------+ +------------+
Figure 1: Information Exchange for End-to-End Overload Feedback.
The basic functionality starts with the support of DIAMETER_TOO_BUSY,
which is defined in the Diameter Base specification. While it does
indeed not provide information to the Diameter client about how it
react on future Diameter messages. While this can be seen as a
design weakness it also has the benefit of a lower standardization
need and minimal implementation complexity. This document defines
the information elements that can be used by an existing Diameter
application to convey overload information.
The necessary AVPs are defined in the Section 5.1 and in Section 5.2.
4.2. Load Balancing
Figure 2 shows the information exchange between different Diameter
servers and a load balancer within the same administrative domain.
Following the capability exchange between the load balancer and the
Diameter servers load information is exchanged. Incoming Diameter
requests are distributed based on the collected load information and
based on the configuration of the load balancer.
Exchange of Load Info
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\+
+ |
+---v------+ |
| Diameter | |
| Server A <--+ Diameter +-----v--+ Incoming
+----------+ | Exchanges |Load | Diameter Requests
+----------+ +--------------+Balancer|<<<------------------
| Diameter | | +-----^--+
| Server B <--+ |
+----^-----+ |
+ |
//////////////////////////////+
Exchange of Load Info
Figure 2: Information Exchange for Load Balancing.
Tschofenig Expires January 17, 2014 [Page 5]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
The information elements relevant to load balancing are described in
Section 5.1 and in Section 5.3.
5. Information Elements
5.1. Capability Indication
5.1.1. Supported-Features AVP
The Supported-Features AVP (AVP code TBD) is of type Uint64, and
contains a bitmap that allows capability indication. The bitmap
allows for up to 64 total values to be defined.
+---------+-----------------------+
| Bitmask | Feature |
+---------+-----------------------+
| 0000001 | [TBD: This document.] |
+---------+-----------------------+
5.1.2. Sending-Rate AVP
The Sending-Rate AVP (AVP Code TBD10) is of type Unsigned32 and
indicates the time in milliseconds between subsequent load updates.
Higher values lead to fewer load updates and therefore reduce the
signaling overhead but lead to less up-to-date information.
5.2. Information for Rejecting Diameter Requests
5.2.1. Overload-Info AVP
The Overload-Info AVP (AVP Code TBD) is of type Grouped, and is used
as a top-level container for information about the overload status.
The grouped data field of the Overload-Info AVP has the following
grammar:
< Overload-Info > ::= < AVP Header: TBD >
{ Overload }
[ Period-Of-Validity ]
* [ AVP ]
Tschofenig Expires January 17, 2014 [Page 6]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
5.2.2. Period-Of-Validity AVP
The Period-Of-Validity AVP (AVP code TBD) is of type Unsigned32, and
is used to indicate the length of time, in seconds, the Overload-
Metric is to be considered valid. The maximum value in this AVP is 5
minutes, which is also the default value. If this AVP is absent in a
subsequent message then the indicated value is valid till the next
overload report is received.
5.2.3. Overload AVP
The Overload AVP (AVP code TBD) is of type Enumerated. Four values
are defined:
NO_OVERLOAD 0 The Diameter server uses this value
to indicate that it is currently not overload and that the
Diameter client should not reject any request.
INCREASING_OVERLOAD 1 The Diameter server uses this value
to inform the client that overload has increased and that the
Diameter client shall decrease the sending rate into half
(calculated over the last 10 minutes).
DECREASING_OVERLOAD 2 The Diameter server uses this value
to inform the client that the overload situation has improved and
that the Diameter client is allowed to increase the rate of
Diameter requests by 10% of the requests transmitted since the
last overload message was received from the server.
Consequencely, the Diameter server can quickly increase the
sending rate by the client by including Overload AVPs with a value
set to 'DECREASING_OVERLOAD' in subsequent exchanges.
OVERLOADED 3 The Diameter server uses this value
to inform the client that it is completely overloaded and that the
Diameter client shall not send further requests.
The increase and decrease of the sending rate refers to new requests
to the same realm and the same application ID as the message carrying
the overload information.
5.3. Information Elements for Load Balancing
5.3.1. Load-Info AVP
The Load-Info AVP (AVP Code TBD) is of type Grouped, and is used as a
top-level container for information about the load status.
The grouped data field of the Load-Info AVP has the following
grammar:
Tschofenig Expires January 17, 2014 [Page 7]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
< Load-Info > ::= < AVP Header: TBD >
{ Load }
* [ AVP ]
5.3.2. Load AVP
The Load AVP (AVP code TBD) is of type Unsigned32. The indicated
value MUST be between 0 and 10. The semantics of the values are as
follows: a Diameter server indicating a value of zero (0) notifies a
load balancer that there is no overload condition. A Diameter server
indicating a value of ten (10) indicates that it is experiencing
extreme overload and cannot process any further requests. The
remaining other values express situations between these two extremes.
Note that there is no requirement that the Diameter server reports
values in incremental steps; a Diameter server may, for whatever
reason, notice that it needs to report a value of 10 even though it
had previously reported a value of 0. A load balancer receiving
values other than 0 MUST reduce the sending rate of Diameter requests
to the Diameter server correspondingly by redistributing a portion of
the requests (the higher the value the bigger the portion) to
Diameter servers.
Note that the load value does not refer to any specific resource,
such as CPU utilization, database interconnection, etc. The value is
computed locally by the Diameter server based on an algorithm that is
not further specified. Implementers should, however, ensure that the
resources that matter for the specific Diameter deployment are taken
into account in defining the algorithm. The lack of a standardized
algorithm does, however, not impact interoperability. A load
S.balancer provided by vendor A and Diameter servers provided by
vendor B will interoperate because they make decisions based on these
artificial values. For example, a network operator may decide to
configure the load balancer in such a way that the second server is
only used once the load value of the first server reaches a certain
threshold.
The lifetime of the load information is bound to the value
communicated in the Sending-Rate AVP during the capability exchange.
6. Security Considerations
This document describes architectural principles and an information
model. Security considerations are described in the documents that
utilize these AVPs.
Tschofenig Expires January 17, 2014 [Page 8]
Internet-DraDiameter Overload Architecture and Information Mo July 2013
7. IANA Considerations
7.1. Overload Capability Registry
IANA is requested to create a new registry under the 'Authentication,
Authorization, and Accounting (AAA) Parameters' registry for the
overload capability bitmap (with a total of 64 values). The policy
for this registry is 'Specification Required'. One value is defined
by this document, see Section 5.1.1.
7.2. AVP Codes
New AVPs defined by this specification are listed in Section 5. All
AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry.
8. Acknowledgments
The author would like to thank Ulrich Wiehe for his feedback.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
9.2. Informative References
[3] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", draft-ietf-dime-overload-reqs-07 (work in
progress), June 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 9]
