idnits 2.17.00 (12 Aug 2021) /tmp/idnits22656/draft-tschofenig-dime-overload-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 16, 2013) is 3224 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-dime-overload-reqs has been published as RFC 7068 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track July 16, 2013 5 Expires: January 17, 2014 7 Diameter Overload Architecture and Information Model 8 draft-tschofenig-dime-overload-arch-00.txt 10 Abstract 12 This document describes the architecture for Diameter overload 13 control architecture in form of principles and presents an 14 information model. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 17, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Architectural Principles . . . . . . . . . . . . . . . . . . 3 53 4. Information Exchanges . . . . . . . . . . . . . . . . . . . . 4 54 4.1. End-to-End Overload Feedback . . . . . . . . . . . . . . 4 55 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 5 56 5. Information Elements . . . . . . . . . . . . . . . . . . . . 6 57 5.1. Capability Indication . . . . . . . . . . . . . . . . . . 6 58 5.2. Information for Rejecting Diameter Requests . . . . . . . 6 59 5.3. Information Elements for Load Balancing . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. Overload Capability Registry . . . . . . . . . . . . . . 9 63 7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 9.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Diameter was developed to provide an Authentication, Authorization, 73 and Accounting (AAA) framework for a number of applications, 74 including network access, mobility, and real-time multimedia 75 application layer services. Over the last 10 years it has enjoyed 76 widespread industry acceptance and can be found in many large 77 (mobile) operator networks. 79 When a Diameter server becomes overloaded, it may need to ask 80 Diameter clients and agents to gracefully reduce the amount of 81 signaling traffic destined for it. For Diameter clients and agents 82 that are asked to reduce traffic there are two basic approaches for 83 doing so: 85 o by sending a portion of new requests to other Diameter servers 86 which still have capacity available (load balancing), and 87 o by rejecting new requests. 89 [3] aims to provide background information and requirements. This 90 document defines the next step, namely the architecture and the 91 information model. 93 2. Terminology 94 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 95 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 96 specification are to be interpreted as described in [1]. 98 This document re-uses terminology from the Diameter base 99 specification [2]. 101 The term "load balancer" in this document refers to a Diameter proxy 102 that uses load information received from Diameter servers and 103 configuration settings to adjust standard Diameter routing. 105 3. Architectural Principles 107 This section outlines several principles guiding the solution design. 109 Avoid premature optimizations. Diameter is an extensible protocol 110 and new extensions can be added at any time (when necessary). 111 Instead of developing the most "complete" solution there are 112 benefits from starting with a minimal core that helps to gain 113 initial implementation and deployment experience. This minimal 114 core can then be used as a basis for subsequent refinements. 115 Complexity often comes with optimizations and constraints imposed 116 by incremental deployment strategies. 117 Focus on real-world problems. The number of theoretical use cases is 118 large, almost unbounded. What use cases and optimizations are 119 worthwhile to explore and to standardize solutions for? Is the 120 "sounds good" test enough or is evidence of a documented and 121 reproducible real-world problem needed? 122 Overload conditions are rare events. The Diameter backend 123 infrastructure is hopefully dimensioned in a way that overload 124 situations are the exception rather than the norm. Consequently, 125 it is less useful to develop many optimization for those rare 126 events (e.g., optimizations in the form of message reduction). 127 Instead, it is more beneficial to optimize for the case where 128 there is no overload. 129 Consider advances in information technology. At the time of writing 130 cloud computing and virtualization has gained widespread industry 131 interest, even in the telecommunication sector. These new 132 computing paradigms provide built-in support for handling load 133 variation (e.g., by spawning new virtual machines or migrating 134 code). The orchestration and management of these virtual machine 135 instances is often provided in a centralized fashion using a 136 hypervisor and these hypervisors come with management interfaces 137 that obtain load and other status information from their virtual 138 machine instances. It is not unlikely that these developments 139 will also impact deployments of Diameter servers within a single 140 administrative domain. 142 Load Balancing and Rejecting Requests are different. Load balancing 143 is a technique that is best applied within a local administrative 144 domain to re-distribute requests. For maximum benefit knowledge 145 by the load balancer about the system architecture and the nature 146 of applications is required. Rejecting requests, on the other 147 hand, requires information signaling to the Diameter clients since 148 Diameter is not an end-to-end protocol and information about the 149 failure situation needs to be passed along to the source of the 150 end system, such as VoIP phones initiating phone calls, end 151 devices seeking network access. 152 Delegating rejection policies creates a lot of complexity. When a 153 Diameter server reaches an overload state and wants to reduce the 154 number of requests it gets it has a number of choices. In the 155 simplest form it could return reject responses without engaging in 156 heavy application specific processing. In such a model the 157 Diameter server acts as a Policy Decision Point (PDP) and as a 158 Policy Enforcement Point (PEP). By co-locating the PEP and the 159 PDP the decision making is implementation internal, which is also 160 the beautify of this model. If the PEP functionality, however, 161 gets moved to the Diameter client (or to any other node) the need 162 for standardizing a "Diameter request rejection policy language" 163 arises. Delegating functionality from the PDP to the PEP requires 164 the PEP to have a reasonable amount of information about the 165 problem the Diameter server and the support infrastructure is 166 facing. Additionally, the PEP would benefit from knowing about 167 the tradeoff decisions the network operators wants to make 168 regarding the different types of requests. 170 4. Information Exchanges 172 4.1. End-to-End Overload Feedback 174 The information elements described in this document follow the 175 pattern shown in Figure 1. Following the exchange of Diameter 176 application messages between a Diameter client and a Diameter server 177 (through zero or more Diameter intermediaries) a Diameter server may 178 indicate that it is currently suffering an overload situation. To 179 ensure that the load information is understood by the Diameter client 180 a prior capability exchange is provided. 182 Overload + Rejection 183 Information Policies 184 +-------+ +***************************************+ 185 | End | * * 186 | Point | * * 187 +-------+ * Capability Indication * 188 ^ * +------------------------+ * 189 | * | | * 190 | v | v * 191 |Front-End +------------+ Diameter Msg +------------+ 192 |Protocol | Diameter | Exchanges | Diameter | 193 +--------->| Client |<----------------->| Server | 194 +------------+ +------------+ 196 Figure 1: Information Exchange for End-to-End Overload Feedback. 198 The basic functionality starts with the support of DIAMETER_TOO_BUSY, 199 which is defined in the Diameter Base specification. While it does 200 indeed not provide information to the Diameter client about how it 201 react on future Diameter messages. While this can be seen as a 202 design weakness it also has the benefit of a lower standardization 203 need and minimal implementation complexity. This document defines 204 the information elements that can be used by an existing Diameter 205 application to convey overload information. 207 The necessary AVPs are defined in the Section 5.1 and in Section 5.2. 209 4.2. Load Balancing 211 Figure 2 shows the information exchange between different Diameter 212 servers and a load balancer within the same administrative domain. 213 Following the capability exchange between the load balancer and the 214 Diameter servers load information is exchanged. Incoming Diameter 215 requests are distributed based on the collected load information and 216 based on the configuration of the load balancer. 218 Exchange of Load Info 219 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\+ 220 + | 221 +---v------+ | 222 | Diameter | | 223 | Server A <--+ Diameter +-----v--+ Incoming 224 +----------+ | Exchanges |Load | Diameter Requests 225 +----------+ +--------------+Balancer|<<<------------------ 226 | Diameter | | +-----^--+ 227 | Server B <--+ | 228 +----^-----+ | 229 + | 230 //////////////////////////////+ 231 Exchange of Load Info 233 Figure 2: Information Exchange for Load Balancing. 235 The information elements relevant to load balancing are described in 236 Section 5.1 and in Section 5.3. 238 5. Information Elements 240 5.1. Capability Indication 242 5.1.1. Supported-Features AVP 244 The Supported-Features AVP (AVP code TBD) is of type Uint64, and 245 contains a bitmap that allows capability indication. The bitmap 246 allows for up to 64 total values to be defined. 248 +---------+-----------------------+ 249 | Bitmask | Feature | 250 +---------+-----------------------+ 251 | 0000001 | [TBD: This document.] | 252 +---------+-----------------------+ 254 5.1.2. Sending-Rate AVP 256 The Sending-Rate AVP (AVP Code TBD10) is of type Unsigned32 and 257 indicates the time in milliseconds between subsequent load updates. 258 Higher values lead to fewer load updates and therefore reduce the 259 signaling overhead but lead to less up-to-date information. 261 5.2. Information for Rejecting Diameter Requests 263 5.2.1. Overload-Info AVP 265 The Overload-Info AVP (AVP Code TBD) is of type Grouped, and is used 266 as a top-level container for information about the overload status. 268 The grouped data field of the Overload-Info AVP has the following 269 grammar: 271 < Overload-Info > ::= < AVP Header: TBD > 272 { Overload } 273 [ Period-Of-Validity ] 274 * [ AVP ] 276 5.2.2. Period-Of-Validity AVP 278 The Period-Of-Validity AVP (AVP code TBD) is of type Unsigned32, and 279 is used to indicate the length of time, in seconds, the Overload- 280 Metric is to be considered valid. The maximum value in this AVP is 5 281 minutes, which is also the default value. If this AVP is absent in a 282 subsequent message then the indicated value is valid till the next 283 overload report is received. 285 5.2.3. Overload AVP 287 The Overload AVP (AVP code TBD) is of type Enumerated. Four values 288 are defined: 290 NO_OVERLOAD 0 The Diameter server uses this value 291 to indicate that it is currently not overload and that the 292 Diameter client should not reject any request. 293 INCREASING_OVERLOAD 1 The Diameter server uses this value 294 to inform the client that overload has increased and that the 295 Diameter client shall decrease the sending rate into half 296 (calculated over the last 10 minutes). 297 DECREASING_OVERLOAD 2 The Diameter server uses this value 298 to inform the client that the overload situation has improved and 299 that the Diameter client is allowed to increase the rate of 300 Diameter requests by 10% of the requests transmitted since the 301 last overload message was received from the server. 302 Consequencely, the Diameter server can quickly increase the 303 sending rate by the client by including Overload AVPs with a value 304 set to 'DECREASING_OVERLOAD' in subsequent exchanges. 305 OVERLOADED 3 The Diameter server uses this value 306 to inform the client that it is completely overloaded and that the 307 Diameter client shall not send further requests. 309 The increase and decrease of the sending rate refers to new requests 310 to the same realm and the same application ID as the message carrying 311 the overload information. 313 5.3. Information Elements for Load Balancing 315 5.3.1. Load-Info AVP 317 The Load-Info AVP (AVP Code TBD) is of type Grouped, and is used as a 318 top-level container for information about the load status. 320 The grouped data field of the Load-Info AVP has the following 321 grammar: 323 < Load-Info > ::= < AVP Header: TBD > 324 { Load } 325 * [ AVP ] 327 5.3.2. Load AVP 329 The Load AVP (AVP code TBD) is of type Unsigned32. The indicated 330 value MUST be between 0 and 10. The semantics of the values are as 331 follows: a Diameter server indicating a value of zero (0) notifies a 332 load balancer that there is no overload condition. A Diameter server 333 indicating a value of ten (10) indicates that it is experiencing 334 extreme overload and cannot process any further requests. The 335 remaining other values express situations between these two extremes. 336 Note that there is no requirement that the Diameter server reports 337 values in incremental steps; a Diameter server may, for whatever 338 reason, notice that it needs to report a value of 10 even though it 339 had previously reported a value of 0. A load balancer receiving 340 values other than 0 MUST reduce the sending rate of Diameter requests 341 to the Diameter server correspondingly by redistributing a portion of 342 the requests (the higher the value the bigger the portion) to 343 Diameter servers. 345 Note that the load value does not refer to any specific resource, 346 such as CPU utilization, database interconnection, etc. The value is 347 computed locally by the Diameter server based on an algorithm that is 348 not further specified. Implementers should, however, ensure that the 349 resources that matter for the specific Diameter deployment are taken 350 into account in defining the algorithm. The lack of a standardized 351 algorithm does, however, not impact interoperability. A load 352 S.balancer provided by vendor A and Diameter servers provided by 353 vendor B will interoperate because they make decisions based on these 354 artificial values. For example, a network operator may decide to 355 configure the load balancer in such a way that the second server is 356 only used once the load value of the first server reaches a certain 357 threshold. 359 The lifetime of the load information is bound to the value 360 communicated in the Sending-Rate AVP during the capability exchange. 362 6. Security Considerations 364 This document describes architectural principles and an information 365 model. Security considerations are described in the documents that 366 utilize these AVPs. 368 7. IANA Considerations 370 7.1. Overload Capability Registry 372 IANA is requested to create a new registry under the 'Authentication, 373 Authorization, and Accounting (AAA) Parameters' registry for the 374 overload capability bitmap (with a total of 64 values). The policy 375 for this registry is 'Specification Required'. One value is defined 376 by this document, see Section 5.1.1. 378 7.2. AVP Codes 380 New AVPs defined by this specification are listed in Section 5. All 381 AVP codes are allocated from the 'Authentication, Authorization, and 382 Accounting (AAA) Parameters' AVP Codes registry. 384 8. Acknowledgments 386 The author would like to thank Ulrich Wiehe for his feedback. 388 9. References 390 9.1. Normative References 392 [1] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 396 "Diameter Base Protocol", RFC 6733, October 2012. 398 9.2. Informative References 400 [3] McMurry, E. and B. Campbell, "Diameter Overload Control 401 Requirements", draft-ietf-dime-overload-reqs-07 (work in 402 progress), June 2013. 404 Author's Address 406 Hannes Tschofenig 407 Nokia Siemens Networks 408 Linnoitustie 6 409 Espoo 02600 410 Finland 412 Phone: +358 (50) 4871445 413 Email: Hannes.Tschofenig@gmx.net 414 URI: http://www.tschofenig.priv.at