idnits 2.17.1 draft-korhonen-dime-ovl-01.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 date (February 25, 2013) is 4078 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: A later version (-13) exists of draft-ietf-dime-overload-reqs-04 ** Downref: Normative reference to an Informational draft: draft-ietf-dime-overload-reqs (ref. 'I-D.ietf-dime-overload-reqs') Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions J. Korhonen 3 (DIME) Renesas Mobile 4 Internet-Draft H. Tschofenig, Ed. 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: August 29, 2013 February 25, 2013 8 The Diameter Overload Control Application (DOCA) 9 draft-korhonen-dime-ovl-01.txt 11 Abstract 13 This specification documents a Diameter Overload Control Application 14 (DOCA), which uses the normal Diameter application approach for the 15 capability negotiation, propagation and management of Diameter 16 overload control information between Diameter nodes. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 29, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DOCA Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. DOCA Commands . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 6 57 5.1. OC-Information AVP . . . . . . . . . . . . . . . . . . . . 6 58 5.2. OC-Scope AVP . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.3. OC-Applications AVP . . . . . . . . . . . . . . . . . . . 8 60 5.4. OC-Action AVP . . . . . . . . . . . . . . . . . . . . . . 9 61 5.5. OC-Algorithm AVP . . . . . . . . . . . . . . . . . . . . . 9 62 5.6. OC-Level AVP . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.7. OC-Utilization AVP . . . . . . . . . . . . . . . . . . . . 11 64 5.8. OC-Tocl AVP . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.9. OC-Sending-Rate AVP . . . . . . . . . . . . . . . . . . . 11 66 5.10. OC-Best-Before AVP . . . . . . . . . . . . . . . . . . . . 12 67 5.11. OC-Origin AVP . . . . . . . . . . . . . . . . . . . . . . 12 68 5.12. OC-Priority AVP . . . . . . . . . . . . . . . . . . . . . 12 69 5.13. Attribute Value Pair flag rules . . . . . . . . . . . . . 13 70 6. Transport Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 8.1. Application Identifiers . . . . . . . . . . . . . . . . . 15 74 8.2. SCTP Payload Protocol Identifier . . . . . . . . . . . . . 15 75 8.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 15 76 8.4. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.5. Result-Code Values . . . . . . . . . . . . . . . . . . . . 15 78 8.6. New Registries . . . . . . . . . . . . . . . . . . . . . . 16 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Appendix A. Design Justification . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 The existing toolbox offered by the Diameter Base Protocol [RFC6733] 90 to prevent and recover from signaling overload situations is rather 91 limited. Apart from out-of-band altering of the transport connection 92 congestion control behavior or other non-standard application level 93 throttling, the protocol error DIAMETER_TOO_BUSY, the permanent error 94 DIAMETER_UNABLE_TO_COMPLY (for some unspecified reason) and the 95 Disconnect-Cause Attribute Value Pair (AVP) code BUSY or 96 DO_NOT_WANT_TO_TALK_TO_YOU are more or less all there is. 97 Unfortunately, the mentioned three indications are coarse, concern 98 one peer connection at a time or lack detailed information for 99 problem diagnosis and mitigation. They also treat all applications 100 in a single Diameter node (identified by a single DiameterIdentity) 101 as a lump. There is no way communicate any kind of grouping of 102 applications or what is the scope/partitioning of the delivered 103 information. Furthermore, there is no way to signal when the 104 overload situation is over. The request initiator and forwarders are 105 therefore forced to keep re-submitting their messages to determine 106 whether the situation has changed. 108 The situation is further complicated by the hop-by-hop nature of 109 Diameter deployments. This makes the propagation of possible 110 overload situation information non-trivial, even for existing 111 protocol errors since every intermediate Diameter node is allowed to 112 react to the error situation. Either the information is never 113 propagated to the originator of the request or it takes an 114 unacceptable long time. 116 A problem statement of overload control for Diameter and requirements 117 are documented in [I-D.ietf-dime-overload-reqs]. This specification 118 describes a solution to the Diameter overload Diameter Overload 119 Control Application (DOCA), which fulfills the requirements of 120 [I-D.ietf-dime-overload-reqs] and defines a Diameter application to 121 convey overload information between Diameter nodes. 123 Note: The recent publication of 124 [I-D.campbell-dime-overload-data-analysis] illustrates the overload 125 information data model and the design space. As the working group 126 makes progress in deciding about specific features this document will 127 be updated accordingly. 129 2. Requirements 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 3. DOCA Overview 137 Any the DOCA capable Diameter node MAY initiate a DOCA-Report-Request 138 at any given time. The receiver of the DOCA-Report-Request 139 acknowledges with a DOCA-Report-Answer and includes the Result-Code 140 AVP indicating whether it could honor the action/report in the 141 request. The DOCA-Report-Answer SHOULD also piggyback overload 142 control information. 144 A DOCA client MUST set the Auth-Session-State AVP to the value 145 NO_STATE_MAINTAINED and SHOULD include the OC-Information AVP with 146 overload information into the DOCA-Report-Request, if available. The 147 DOCA-Report-Response message MUST contain the Auth-Session-State AVP 148 set to value NO_STATE_MAINTAINED. 150 Note that information exchanges regarding various DOCA related timers 151 serve only as a hint since they cannot be enforced. Consequently, 152 care should be taken not to send DOCA-Report-Requests too frequently. 154 When a Diameter node receives overload control information and is 155 also requested to act on it, the DOCA functionality is applied to all 156 specified applications within a given scope. How the Diameter node 157 accomplishes the node wide DOCA action enforcement is implementation 158 specific. 160 When a Diameter node receives (interim) overload information but the 161 overload condition has not exceeded a certain threshold, then the 162 receiver is not required to act based on the received information. 163 However, it is RECOMMENDED that the receiver makes proactive actions 164 to avoid entering the overload condition based on the newly received 165 overload information. 167 There may be zero or more intermediate Diameter agents on the path 168 between the DOCA client and the DOCA server. Understanding the DOCA 169 functionality is not expected from relays and redirect agents. A 170 Diameter proxy, which obviously understands the DOCA application, MAY 171 inspect the DOCA related AVPs in the DOCA-Report-Request/Answer 172 message pair and depending on the value of the OC-Scope AVP (see 173 Section 5.2) inject its own information. A proxy is always 174 RECOMMENDED to react according to the overload information when it 175 comes to, for example, peer selection and traffic throttling. 177 When a Diameter agent receives overload control information and is 178 also requested to act on it, the DOCA functionality is applied to all 179 specified applications within a given scope. How the Diameter agent 180 accomplishes the node wide DOCA action enforcement is implementation 181 specific. 183 4. DOCA Commands 185 The DOCA-Report-Request (DRR) message is used to report overload 186 condition information. The message can be originated as a result of 187 emerging overload condition or as a periodic unsolicited report. 189 ::= < Diameter Header: TBD2, REQ, PXY > 190 < Session-Id > 191 { Auth-Application-Id } 192 { Origin-Host } 193 { Origin-Realm } 194 { Destination-Realm } 195 { Auth-Request-Type } 196 { Destination-Host } 197 [ Auth-Session-State ] 198 * [ Class ] 199 [ Origin-State-Id ] 200 * [ Proxy-Info ] 201 * [ Route-Record ] 203 { OC-Scope } 204 [ OC-Algorithm ] 205 [ OC-Action ] 206 [ OC-Tocl ] 207 [ OC-Applications ] 208 * [ OC-Information ] 210 * [ AVP ] 212 The DOCA-Report-Answer (DRA) message is used as a response to the 213 DOCA-Report-Request. The message MAY piggyback overload condition 214 information in order to avoid unnecessary DOCA-Report-Request 215 messages to the reverse direction. 217 ::= < Diameter Header: TBD2, PXY > 218 < Session-Id > 219 { Result-Code } 220 { Origin-Host } 221 { Origin-Realm } 222 [ Auth-Session-State ] 223 * [ Class ] 224 [ Error-Message ] 225 [ Error-Reporting-Host ] 226 [ Failed-AVP ] 227 [ Origin-State-Id ] 228 * [ Redirect-Host ] 229 [ Redirect-Host-Usage ] 230 [ Redirect-Max-Cache-Time ] 231 * [ Proxy-Info ] 233 { OC-Scope } 234 [ OC-Action ] 235 * [ OC-Information ] 237 * [ AVP ] 239 5. Attribute Value Pairs 241 5.1. OC-Information AVP 243 The OC-Information AVP (AVP Code TBD3) is of type Grouped and 244 contains a set AVPs that identify the source of the overload control 245 information (the OC-Origin AVP), the overload information itself and 246 which applications the information concerns. 248 OC-Information ::= < AVP Header: TBD3 > 249 { OC-Origin } 250 { OC-Best-Before } 251 [ OC-Level ] 252 [ OC-Algorithm ] 253 [ OC-Sending-Rate ] 254 [ Vendor-Id ] 255 [ OC-Applications ] 256 [ Product-Name ] 257 [ OC-Utilization ] 258 [ OC-Priority ] 259 * [ AVP ] 261 Diameter proxies on path MAY add one or more OC-Information AVPs into 262 the DOCA-Report-Request/answer messages. 264 5.2. OC-Scope AVP 266 The OC-Scope (AVP Code TBD4) is of type Unsigned32 and contains the 267 scope where and concerning what the overload control information can 268 be injected. The OC-Scope is formatted as a vector of scope flag 269 bits. The following scopes are supported: 271 Host scope (0x00000001) 273 The OC-Information AVP concerns only a single host within a realm 274 (which internally MAY represent of pool). 276 Realm scope (0x00000002) 278 The OC-Information AVP concerns a realm. No specific hosts are 279 identified. 281 Only origin realm (0x00000004) 283 The OC-Information AVP can only be included by a Diameter node on 284 the path that has the same Origin-Realm as the DOCA client. 286 Application information (0x00010000) 288 The OC-Information AVP MAY contain application related information 289 (the OC-Applications AVP). 291 Node utilization information (0x00020000) 293 The OC-Information AVP MAY contain node wide load related 294 information (the OC-Utilization AVP). 296 Application priorities (0x00040000) 298 The OC-Information AVP SHOULD priority information (the OC- 299 Priority AVP) so when the overload condition is on, Diameter nodes 300 are able to prioritize between different applications, for 301 example, when dropping or throttling messages. 303 Any other value is reserved. 305 A scope is active when a corresponding flag is set in the OC-Scope 306 AVP. During the initialization state a DOCA client includes those 307 scopes it supports and is interested in. A DOCA server then returns 308 the scope that it has in common with the DOCA client (and intends to 309 use). The common scopes are then used during the established state. 310 Note that some scope combinations make little sense while still being 311 valid. The general guide when multiple scopes collide is that the 312 least restrictive wins. 314 A sender of the overload information MUST adhere to the scope it 315 announces regarding the information it itself sends. 317 If a DOCA server does not have a common scope with a DOCA client or 318 the DOCA server cannot agree on one based on a local policy, then the 319 DOCA server MUST send the DOCA-Report-Answer indicating an error and 320 set the Result-Code to the DIAMETER_NO_COMMON_SCOPE value. 322 5.3. OC-Applications AVP 324 The OC-Applications (AVP Code TBD5) is of type Grouped and contains a 325 list of Application-IDs of interest when found in the DOCA-Report- 326 Request/Answer command main level and meant to be used during the 327 initialization state to agree on the common set of supported 328 applications of monitoring interest. When used within the OC- 329 Information AVP, the OC-Applications AVP identify those applications 330 the overload information concerns. The OC-Applications AVPs on the 331 command main level and inside the OC-Information AVP MUST NOT have 332 conflicting views of the applications of interest. However, the OC- 333 Applications AVP can be see as a superset of applications i.e., not 334 all applications of interest need to be included every time into the 335 OC-Information AVP. 337 OC-Applications ::= < AVP Header: TBD3 > 338 * [ Auth-Application-Id ] 339 * [ Acct-Application-Id ] 340 * [ Vendor-Specific-Application-Id ] 341 * [ AVP ] 343 The absence of the OC-Applications AVP indicates the Diameter node 344 has no specific preference or interest in specific applications. The 345 overload information is then signaled as concerning the whole 346 Diameter node. This default behavior is useful when the DOCA does 347 not maintain session state. If there are no common applications, 348 then the DOCA-Report-Answer MUST contain the Result-Code with the 349 DIAMETER_NO_COMMON_APPLICATION value. 351 When the DOCA maintains state, there is no need to include the OC- 352 Applications AVP into the DOCA-Report-Request/Answer command main 353 level after the initial message exchange. The agreed common set of 354 application is expected to be known by both DOCA client and server 355 throughout the session lifetime. 357 5.4. OC-Action AVP 359 The OC-Action (AVP Code TBD6) is of type OctetString and size of one 360 octet. The octet has the following three possible values: 362 Start (1) 364 Signals the start of the overload condition. This implies the 365 receiver is requested to act according to the information found in 366 the OC-Information. 368 Stop (2) 370 Signals the end of the overload condition. 372 Interim (3) 374 Updates the overload information. The interim can be sent during 375 the overload condition or during the normal condition. This is 376 the default value. 378 Any other value is reserved. 380 5.5. OC-Algorithm AVP 382 The OC-Algorithm (AVP Code TBD7) is of type Unsigned32. The contains 383 supported 'algorithms' to mitigate the overload condition. The OC- 384 Algorithm AVP is formatted as a vector of algorithm flag bits. The 385 following 'algorithms' are supported: 387 Drop (0x00000001) 389 Messages are plain dropped. It is RECOMMENDED to drop messages 390 selectively based, for example, on application priorities. This 391 is the default algorithm. 393 Throttle (0x00000002) 395 The message sending rate is according to the OC-Sending-Rate AVP. 397 Prioritize (0x00000004) 399 Apply priorities among applications and the other used means for 400 holding traffic. 402 Any other value is reserved. 404 The 'algorithms' are only applied at a Diameter node when the 405 overload condition has been signaled. 407 During the initialization state a DOCA client includes those 408 algorithms it supports and is interested in. A DOCA server then 409 returns the algorithm that it has in common with the DOCA client (and 410 intends to use). One or more common algorithms are then used during 411 the established state. 413 If a DOCA server does not have a common algorithm with a DOCA client 414 or the DOCA server cannot agree on one based on a local policy, then 415 the DOCA server MUST send the DOCA-Report-Answer indicating an error 416 and set the Result-Code to the DIAMETER_NO_COMMON_ALGORITHM value. 418 5.6. OC-Level AVP 420 The OC-Level (AVP Code TBD8) is of type OctetString and size of one 421 octet. The octet has the following five possible values: 423 Normal (1) 425 Everything is in control. Meaningful only when the OC-Action is 426 set to 'Interim' since when the overload condition level is 427 considered normal, the overload condition SHOULD be stopped. This 428 is the default value. 430 Raising (2) 432 There is a sign of increasing load. 434 Alarming (3) 436 The overload condition is reaching the level where quick measures 437 SHOULD be done to mitigate the overload condition. 439 Panic (4) 441 The overload condition is severe. Apply any measure to mitigate 442 the overload condition but still allowed to send messages. 444 Hold (5) 446 Do not send any messages, please. When this level is signaled, 447 the OC-Best-Before time SHOULD NOT be respected but an explicit 448 overload condition stop has to be received (with an exception the 449 Diameter node realizes its other end has rebooted or otherwise 450 lost its state). 452 Switch servers (6) 454 Do not talk to me again. When this level is signaled, the DOCA 455 client MUST switch to an alternative server. 457 Any other value is reserved. 459 If the receiver cannot agree on or does not understand the OC-Level 460 AVP value, the an error MUST be returned with the Result-Code AVP set 461 to the value DIAMETER_INVALID_AVP_VALUE and the Failed-AVP AVP 462 containing the OC-Level AVP. 464 5.7. OC-Utilization AVP 466 The OC-Utilization (AVP Code TBD9) is of type Float32 and tells the 467 overall utilization level percentage of the Diameter node. Values 468 between 0.0 to 100.0 are valid. 470 5.8. OC-Tocl AVP 472 The OC-Tocl (AVP Code TBD10) is of type Unsigned32 and tells the Tolc 473 timer value in milliseconds. This timer defines the interval for 474 sending periodic DOCA-Report-Request messages with the OC-Action AVP 475 set to 'Interim'. The value of zero (0) means no periodic DOCA- 476 Report-Request messages are sent or desired. The default value is 477 120000. 479 The OC-Tocl AVP can be considered as a hint for a desired sending 480 rate of subsequent messages. 482 If a DOCA server find the Tocl value proposed by a DOCA client either 483 too small (i.e. too frequent periodic messages) or too big (i.e. too 484 seldom periodic messages), then the DOCA server MUST send the DOCA- 485 Report-Answer indicating an error and set the Result-Code either to 486 the DIAMETER_TOCL_TOO_SMALL or DIAMETER_TOCL_TOO_BIG value. 488 5.9. OC-Sending-Rate AVP 490 The OC-Sending-Rate (AVP Code TBD11) is of type Float32 and tells the 491 the maximum Diameter message sending rate per second the sender of 492 this information wishes to receive Diameter messages. Only positive 493 values are valid. A value of zero (0.0) of the absence of this AVP 494 means the information sender has no specific rate preference. 496 If a DOCA server finds the sending rate value proposed by a DOCA 497 client too big (i.e., too frequent periodic messages), then the DOCA 498 server MUST send the DOCA-Report-Answer indicating an error and set 499 the Result-Code to the DIAMETER_RATE_TOO_BIG value. 501 5.10. OC-Best-Before AVP 503 The OC-Best-Before (AVP Code TBD12) is of type Time and tells the 504 expiration time/date for the information received in the OC- 505 Information. For example, when the overload condition is on, the 506 expiration of the 'best before' timer causes the same as receiving a 507 DOCA-Report-Request/Answer with the OC-Action set to 'Stop'. 509 [Editor's node: to be decided whether a duration timer is a better 510 measure. Using Time has the assumptions nodes have actually 511 clocks that a running approximately same time.] 513 5.11. OC-Origin AVP 515 The OC-Origin (AVP Code TBD13) is of type DiameterIdentity and tells 516 the identity of the Diameter node that originated included the 517 overload control information. Both host and realm information MUST 518 be included in the OC-Origin AVP. Note, if the OC-Scope AVP 519 indicates only a realm wide scope for the overload information, then 520 the realm part of the OC-Origin AVP is meaningful and the host 521 information only serves as an additional information of the 522 representative for the realm wide information. 524 5.12. OC-Priority AVP 526 The OC-Priority (AVP Code TBD14) is of type Unsigned32 and defines 527 the priority level. The value of 0x00000000 is the highest priority 528 and the value of 0xffffffff is the lowest priority. The absence of 529 the OC-Priority AVP means there is not specific priority level 530 defined and the priority SHOULD be considered as the lowest possible. 532 When used within the OC-Information grouped AVP, the OC-Priority AVP 533 defines the priority for the listed applications within the OC- 534 Applications AVP. 536 5.13. Attribute Value Pair flag rules 538 +---------+ 539 |AVP flag | 540 |rules | 541 +----+----+ 542 AVP Section | |MUST| 543 Attribute Name Code Defined Value Type |MUST| NOT| 544 +---------------------------------------------------+----+----+ 545 |OC-Information TBD3 x.x Grouped | M | V | 546 +---------------------------------------------------+----+----+ 547 |OC-Scope TBD4 x.x Unsigned32 | M | V | 548 +---------------------------------------------------+----+----+ 549 |OC-Application TBD5 x.x Grouped | M | V | 550 +---------------------------------------------------+----+----+ 551 |OC-Action TBD6 x.x OctetString | M | V | 552 +---------------------------------------------------+----+----+ 553 |OC-Algorithm TBD7 x.x Unsigned32 | M | V | 554 +---------------------------------------------------+----+----+ 555 |OC-Level TBD8 x.x OctetString | M | V | 556 +---------------------------------------------------+----+----+ 557 |OC-Utilization TBD9 x.x Float32 | M | V | 558 +---------------------------------------------------+----+----+ 559 |OC-Tocl TBD10 x.x Unsigned32 | M | V | 560 +---------------------------------------------------+----+----+ 561 |OC-Sending-Rate TBD11 x.x Float32 | M | V | 562 +---------------------------------------------------+----+----+ 563 |OC-Best-Before TBD12 x.x Time | M | V | 564 +---------------------------------------------------+----+----+ 565 |OC-Origin TBD13 x.x DiameterIdentity | M | V | 566 +---------------------------------------------------+----+----+ 567 |OC-Priority TBD14 x.x Unsigned32 | M | V | 568 +---------------------------------------------------+----+----+ 570 6. Transport Considerations 572 In case of Stream Control Transmission Protocol (SCTP) transport, the 573 DOCA application is RECOMMENDED to mark its Diameter packets using 574 the DOCA defined SCTP Payload Protocol Identifier (PPID) TBD1. The 575 PPID MAY be used by intermediating network nodes or agents to peek 576 into SCTP message and find out that this is about overload control. 577 Such information can be used for prioritizing SCTP packet handling as 578 an example. 580 7. Examples 582 Consider the following simplified scenario shown in Figure 1 where 583 two servers are connected to a proxy. All three nodes understand the 584 DOCA application. These three nodes belong to the same 585 administrative domain and the operator decided that he wants to hide 586 the Diameter topology of his own network. Consequently, aggregate 587 information is provided by the proxy for any Diameter overload 588 message exchange. The Diameter client also supports the DOCA 589 application. Between the client and the Diameter proxy we assume an 590 arbitrary Diameter network that passes Diameter messages back and 591 forth. 593 +------------------+ +------------------+ 594 | Server 1 | | Server 2 | 595 | (DOCA capable) | | (DOCA capable) | 596 +----------`.------+ +------------------+ 597 `. 598 `. 599 `. 600 `. 601 +-------`.---------+ 602 | Proxy | 603 | (DOCA capable) | 604 +--------+---------+ 605 | 606 ......................+...................... 607 | 608 +-------`.'--------+ 609 | | 610 | Intermediate | 611 | Diameter nodes | 612 +--------+---------+ 613 | 614 | 615 +--------+---------+ 616 | Client | 617 | (DOCA capable) | 618 +------------------+ 620 Figure 1 622 Let us assume that the DOCA exchange is initiated by server 1 who 623 determines that the load situation increases. It sends a DOCA- 624 Report-Request message (with piggybacked overload information) 625 towards the client. The message also instructs the client to reduce 626 it's sending rate. The proxy, who receives the DOCA-Report-Request 627 decides to change the included OC-Origin information and forwards the 628 request to the client. 630 When the client receives the DOCA-Report-Request message is processes 631 the content, evaluates the overload information content and reacts 632 accordingly, and returns a DOCA-Report-Answer message back to 633 acknowledge the receipt. 635 Alternatively, let us assume that the proxy does not forward the 636 message but instead terminates the DOCA-Report-Request received from 637 Server 1. It instead decides to route traffic to the backup server, 638 Server 2. In this case the entire process was transparent for the 639 client. 641 8. IANA Considerations 643 8.1. Application Identifiers 645 This specification reserves a new Diameter Application-ID TBD14 for 646 the Diameter Overload Control Application (DOCA) from the 647 'Authentication, Authorization, and Accounting (AAA) Parameters' 648 Application IDs registry. 650 8.2. SCTP Payload Protocol Identifier 652 Section 6 reserves a new SCTP Payload Protocol Identifier for the 653 DOCA application usage. The value is reserved from the existing SCTP 654 Payload Protocol Identifiers registry. 656 8.3. Command Codes 658 Two command codes are defined in Section 4. The DOCA-Report-Request 659 Command Code is TBD and the DOCA-Report-Answer Command Code is TBD. 660 Both are allocated from the 'Authentication, Authorization, and 661 Accounting (AAA) Parameters' Command Codes registry. 663 8.4. AVP Codes 665 New AVPs defined by this specification are listed in Section 5. All 666 AVP codes allocated from the 'Authentication, Authorization, and 667 Accounting (AAA) Parameters' AVP Codes registry. 669 8.5. Result-Code Values 671 This specification adds several Diameter Overload Control Application 672 specific Permanent Failure codes from the 'Authentication, 673 Authorization, and Accounting (AAA) Parameters' Result-Code AVP 674 Values (code 268) - Permanent Failure registry: 676 AVP Values | Attribute Name | Reference 677 -----------+-------------------------------+---------- 678 5xxx | DIAMETER_NO_COMMON_SCOPE | RFCxxxx 679 5xxx | DIAMETER_NO_COMMON_ALGORITHM | RFCxxxx 680 5xxx | DIAMETER_TOCL_TOO_SMALL | RFCxxxx 681 5xxx | DIAMETER_TOCL_TOO_BIG | RFCxxxx 682 5xxx | DIAMETER_RATE_TOO_BIG | RFCxxxx 684 8.6. New Registries 686 Four new registries are needed under the 'Authentication, 687 Authorization, and Accounting (AAA) Parameters' registry: 689 o OC-Scope AVP Values: the policy for this registry is Specification 690 Required. 691 o OC-Action AVP Values: the policy for this registry is Standards 692 Action. 693 o OC-Level AVP Values: the policy for this registry is Standards 694 Action. 695 o OC-Algorithm AVP Values: the policy for this registry is 696 Specification Required. 698 9. Security Considerations 700 The security properties of the Diameter Overload Control Application 701 (DOCA) follows the security model of Diameter [RFC6733]. This 702 implies there is no proper means to verify the message and AVP 703 content correctness if multiple intermediate Diameter agents are 704 present on the path between the DOCA client and server. As a result 705 a malicious intermediate could feed incorrect overload control 706 information to DOCA clients and peers, and thus affect negatively to 707 the overload condition recovery. A possible way to overcome the 708 obvious security vulnerability is to mandate the use of end-to-end 709 security at the Diameter AVP level. 711 As such, like any other Diameter application this document would 712 benefit from a Diameter end-to-end security mechanism. While work is 713 in progress it has not yet been finalized and therefore this 714 specification does not rely on it. 716 10. Acknowledgements 718 The author thanks Annett Seefeldt for her constructive comments on 719 the technical aspects on this document. 721 11. References 723 11.1. Normative References 725 [I-D.ietf-dime-overload-reqs] 726 McMurry, E. and B. Campbell, "Diameter Overload Control 727 Requirements", draft-ietf-dime-overload-reqs-04 (work in 728 progress), February 2013. 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, March 1997. 733 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 734 "Diameter Base Protocol", RFC 6733, October 2012. 736 11.2. Informative References 738 [I-D.campbell-dime-overload-data-analysis] 739 Campbell, B., Tschofenig, H., Korhonen, J., and A. Roach, 740 "Diameter Overload Data Analysis", 741 draft-campbell-dime-overload-data-analysis-00 (work in 742 progress), February 2013. 744 [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter 745 Straightforward-Naming Authority Pointer (S-NAPTR) Usage", 746 RFC 6408, November 2011. 748 Appendix A. Design Justification 750 Section 1 discussed the motivation and the background for the 751 Diameter enhancements for an explicit Diameter overload control 752 solution. This specification solves the overload control at the 753 application level instead of extending the Diameter base protocol or 754 piggybacking overload control information on top of existing 755 applications. The reasoning is the following: 757 1. The support for Diameter overload control capability between 758 Diameter peers is explicit (i.e., a new application-id is 759 advertised) and thus not build on an exchange of optional 760 Attribute Value Pairs (AVPs). 761 2. The support for Diameter overload control capability between 762 Diameter client and server is explicit. 764 3. The peer selection follows the existing standards including DNS- 765 based discovery [RFC6408] and does not assume additional peer 766 selection criteria learnt from an exchange of optional AVPs. 767 4. The application based solution is able to traverse and also 768 propagate overload control information through realms that deploy 769 relay agents without Diameter overload control support. 770 5. The propagation does not depend on a modified behavior of already 771 specified Diameter command codes. 772 6. Pretending not to establish a state when there actually is an 773 overload capability and information state still maintained. The 774 state might not be at the application level but is there. 775 7. Trying to avoid information flooding, especially across 776 administrative domains. 777 8. The use of the application concept allows established mechanisms 778 for filtering and Diameter traffic engineering, since it behaves 779 like any other Diameter application. 780 9. The use of the dedicated application allows to isolate (even 781 physically) the overload signaling into a dedicated transport 782 that is not affected by other Diameter messages and network 783 traffic. 785 Authors' Addresses 787 Jouni Korhonen 788 Renesas Mobile 789 Porkkalankatu 24 790 Helsinki 00180 791 Finland 793 Email: jouni.nospam@gmail.com 795 Hannes Tschofenig (editor) 796 Nokia Siemens Networks 797 Linnoitustie 6 798 Espoo 02600 799 Finland 801 Phone: +358 (50) 4871445 802 Email: Hannes.Tschofenig@gmx.net 803 URI: http://www.tschofenig.priv.at