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 16, 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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Architectural Principles
• 4. Information Exchanges
• 4.1. End-to-End Overload Feedback
• 4.2. Load Balancing
• 5. Information Elements
• 5.1. Capability Indication
• 5.2. Information for Rejecting Diameter Requests
• 5.3. Information Elements for Load Balancing
• 6. Security Considerations
• 7. IANA Considerations
• 7.1. Overload Capability Registry
• 7.2. AVP Codes
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

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:

• by sending a portion of new requests to other Diameter servers which still have capacity available (load balancing), and
• by rejecting new requests.

[I-D.ietf-dime-overload-reqs] aims to provide background information and requirements. This document defines the next step, namely the architecture and the information model.

2. Terminology

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 [RFC2119].

This document re-uses terminology from the Diameter base specification [RFC6733].

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.

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         *
    ^             *       +------------------------+      *
    |             *       |                        |      *
    |             v       |                        v      *
    |Front-End +------------+   Diameter Msg    +------------+
    |Protocol  |  Diameter  |   Exchanges       |  Diameter  |
    +--------->|  Client    |<----------------->|  Server    |
               +------------+                   +------------+

              
             Exchange of Load Info
     \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\+
     +                              |
 +---v------+                       |
 | Diameter |                       |
 | Server A <--+   Diameter   +-----v--+      Incoming
 +----------+  |   Exchanges  |Load    |   Diameter Requests
 +----------+  +--------------+Balancer|<<<------------------
 | Diameter |  |              +-----^--+
 | Server B <--+                    |
 +----^-----+                       |
      +                             |
      //////////////////////////////+
             Exchange of Load Info

              
+---------+-----------------------+
| Bitmask | Feature               |
+---------+-----------------------+
| 0000001 | [TBD: This document.] |
+---------+-----------------------+

              
           < Overload-Info > ::= < AVP Header: TBD >
                             { Overload }
                             [ Period-Of-Validity ]
                           * [ AVP ]

              
           < Load-Info > ::= < AVP Header: TBD >
                             { Load }
                           * [ AVP ]