idnits 2.17.00 (12 Aug 2021) /tmp/idnits15421/draft-korhonen-dime-ovl-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2012) is 3516 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-rfc3588bis has been published as RFC 6733 == Outdated reference: A later version (-02) exists of draft-mcmurry-dime-overload-reqs-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions J. Korhonen, Ed. 3 (DIME) Nokia Siemens Networks 4 Internet-Draft October 3, 2012 5 Intended status: Standards Track 6 Expires: April 6, 2013 8 Diameter Overload Control Application 9 draft-korhonen-dime-ovl-00.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 Requirements 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 6, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Justification for the selected solution approach . . . . . 4 61 2.2. Initialization state with STATE_MAINTAINED . . . . . . . . 6 62 2.3. Initialization state with NO_STATE_MAINTAINED . . . . . . 7 63 2.4. Renegotiation and termination of the session . . . . . . . 8 64 2.5. Established state and the distribution of the overload 65 control information . . . . . . . . . . . . . . . . . . . 8 66 2.5.1. Diameter client and server behavior . . . . . . . . . 8 67 2.5.2. Diameter agent behavior . . . . . . . . . . . . . . . 9 68 3. DOCA-Report-Request/Answer Commands . . . . . . . . . . . . . 9 69 4. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11 70 4.1. OC-Information AVP . . . . . . . . . . . . . . . . . . . . 11 71 4.2. OC-Scope AVP . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. OC-Applications AVP . . . . . . . . . . . . . . . . . . . 13 73 4.4. OC-Action AVP . . . . . . . . . . . . . . . . . . . . . . 14 74 4.5. OC-Algorithm AVP . . . . . . . . . . . . . . . . . . . . . 14 75 4.6. OC-Level AVP . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.7. OC-Utilization AVP . . . . . . . . . . . . . . . . . . . . 16 77 4.8. OC-Tocl AVP . . . . . . . . . . . . . . . . . . . . . . . 16 78 4.9. OC-Sending-Rate AVP . . . . . . . . . . . . . . . . . . . 17 79 4.10. OC-Best-Before AVP . . . . . . . . . . . . . . . . . . . . 17 80 4.11. OC-Origin AVP . . . . . . . . . . . . . . . . . . . . . . 17 81 4.12. OC-Priority AVP . . . . . . . . . . . . . . . . . . . . . 18 82 4.13. Attribute Value Pair flag rules . . . . . . . . . . . . . 19 83 5. Transport considerations . . . . . . . . . . . . . . . . . . . 19 84 6. Deployment considerations . . . . . . . . . . . . . . . . . . 20 85 6.1. Overload information propagation with STATE_MAINTAINED . . 20 86 6.2. Overload information propagation with 87 NO_STATE_MAINTAINED . . . . . . . . . . . . . . . . . . . 20 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 7.1. Application Identifiers . . . . . . . . . . . . . . . . . 20 90 7.2. SCTP Payload Protocol Identifier . . . . . . . . . . . . . 21 91 7.3. Command codes . . . . . . . . . . . . . . . . . . . . . . 21 92 7.4. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 21 93 7.5. Result-Code values . . . . . . . . . . . . . . . . . . . . 21 94 7.6. New registries . . . . . . . . . . . . . . . . . . . . . . 21 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 The existing tool box offered by the Diameter Base Protocol 105 [I-D.ietf-dime-rfc3588bis] to prevent and recover from signaling 106 overload situations is rather limited. Apart from out-of-band 107 altering of the transport connection congestion control behavior or 108 other non-standard application level throttling, the protocol error 109 DIAMETER_TOO_BUSY, the permanent error DIAMETER_UNABLE_TO_COMPLY (for 110 some unspecified reason) and the Disconnect-Cause Attribute Value 111 Pair (AVP) code BUSY or DO_NOT_WANT_TO_TALK_TO_YOU are more or less 112 all there is. Unfortunately, the mentioned three indications are 113 coarse, concerns one peer connection at time or lack proper 114 information what is the cause of the signaled actions. They also 115 treats all applications in a single Diameter node (identified by a 116 single DiameterIdentity) as a lump. There is no way communicate any 117 kind of grouping of applications or what is the scope/partitioning of 118 the delivered information. Furthermore, there is no way to signal 119 when the overload situation is over. The request initiator and 120 forwarders just have to keep trying to find it out. 122 The situation is further complicated by the hop-by-hop nature of 123 Diameter deployments. This makes the propagation of possible 124 overload situation information non-trivial, even for exiting protocol 125 errors (since every intermediate is allowed for to react to the 126 error). Either the information is never propagated to the request 127 originator or it takes unacceptable long time to reach the 128 originator. 130 The Diameter overload control challenges are further discussed and a 131 set of solution requirements for an overall Diameter overload control 132 mechanism are documented in [I-D.mcmurry-dime-overload-reqs]. This 133 specification documents a Diameter Overload Control Application 134 (DOCA), which fulfills the requirements of 135 [I-D.mcmurry-dime-overload-reqs] and uses the normal Diameter 136 application approach for the capability negotiation, propagation and 137 management of Diameter overload control information between Diameter 138 nodes. 140 [Editor's note: There probably still are gaps between the 141 requirements and the feature set of this specification.] 143 2. Solution Overview 145 2.1. Justification for the selected solution approach 147 Section 1 discussed the motivation and the background for the 148 Diameter enhancements for explicit Diameter overload control 149 solution. This specification solves the overload control at the 150 application level instead of 1) extending the Diameter base protocol 151 or 2) piggybacking overload control information on top of existing 152 applications and their commands. The reasoning is the following: 154 1. The support for Diameter overload control capability between 155 Diameter peers is explicit (i.e. a new application-id is 156 advertised) and thus not build on an exchange of optional 157 Attribute Value Pairs (AVPs). 158 2. The support for Diameter overload control capability between 159 Diameter client and server is explicit. 160 3. The peer selection follows the existing standards including DNS- 161 based discovery [RFC6408] and does not assume additional peer 162 selection criteria learnt from an exchange of optional AVPs. 163 4. The application based solution is able to traverse and also 164 propagate overload control information through realms that deploy 165 'vanilla' relay agents without Diameter overload control support. 166 5. The propagation does not depend on a modified behavior of past, 167 existing or future (base protocol) commands or their Command Code 168 Format (CCF). 169 6. Pretending not to establish a state when there actually is an 170 overload capability and information state still maintained. The 171 state might not be at the application level but is there. 172 7. Trying to avoid information flooding, especially across 173 administrative domains. 174 8. Applications allow established mechanisms for filtering and 175 Diameter traffic engineering, since it does not differentiate, 176 from a Diameter point of view, from any normal application. 178 [Editor's note] Whether the application is proxiable or just 179 between two peers is for further study. 181 It is obvious that the Diameter Overload Control Application (DOCA) 182 will contribute to the overall signaling traffic load. Therefore, 183 the DOCA is designed to be as reticent as possible. Since Diameter 184 does not, as such, support unidirectional message delivery at the 185 application level, the DOCA behavior is simple request-reply each 186 time. 188 The application level solution usually requires maintaining an 189 application state. However, the DOCA defines two modes of operation: 191 1. STATE_MAINTAINED where the DOCA client and server first negotiate 192 the appropriate behavior for the subsequent reports of the 193 overload information exchanges. The negotiation (initializing) 194 state consist of one message pair and the reporting (established) 195 state continues using the same message pair. AVPs and their 196 values that remain the same after the session has been 197 established do not need to be repeated in subsequent messaging, 198 thus reducing the overall message size. 200 [Editor's note: To be decided whether maintaining state is worth 201 at all.] 203 2. NO_STATE_MAINTAINED where the DOCA client and server never leave 204 the negotiation (initializing) phase and piggyback the overload 205 information as part of the "negotiation" over and over again. 206 The DOCA clients and servers MAY apply additional intelligence to 207 learn the capabilities of the other DOCA peer. However, such 208 behavior is not required or even expected. 210 In the absence of a Diameter end-to-end security framework, this 211 specification does not define one either. This implies that no 212 mutual authentication between the Diameter client and server takes 213 place. The intermediate Diameter agents are not either authenticated 214 and the integrity of the delivered overload control information 215 cannot be guaranteed. If these security properties are desired, a 216 future revision of this document may add those. 218 Finally, the DOCA concerns Diameter nodes as whole, not a single 219 session. A single persistent DOCA session can cover multiple 220 applications, transport connections and Diameter sessions. One DOCA 221 client MAY also represent a pool of other Diameter nodes. The 222 different Diameter nodes are and can be differentiated based on their 223 DiameterIdentities. How one DOCA capable Diameter node is selected 224 to represent a pool of other Diameter nodes is out of scope of this 225 specification. Furthermore, how the DOCA information is disseminated 226 within the pool is also out of scope this specification. 228 2.2. Initialization state with STATE_MAINTAINED 230 The DOCA is bi-directional when it comes to the distribution of the 231 overload control information and has no concept of statically 232 assigned initiator or responder roles. However, before any overload 233 control information can be sent to a specific destination 234 (Destination-Realm and Destination-Host pair), a DOCA session has to 235 be set up between two Diameter nodes. We call this step as the 236 'initialization state', which involves: 238 o Establishing a session between two Diameter nodes who both can 239 then be originators and consumers of the overload control 240 information. 241 o Agreeing on the scope of the overload control information i.e. 242 whether it concerns the client and server only, any node in a 243 specific realm that happens to be on the path, or any node in any 244 realm on the path. 246 o Agreeing on the set of applications to be monitored. 247 o Agreeing on the 'algorithm' to apply when overload situation takes 248 place. 249 o Agreeing on the maximum rate for a periodic overload control 250 information delivery. 252 The initialization state is started by sending a DOCA-Report-Request, 253 which promotes the request initiator as the 'client' for the 254 forthcoming DOCA session. The Auth-Session-State AVP MUST be set to 255 value STATE_MAINTAINED. If the DOCA-Report-Response contains the 256 Auth-Session-State AVP set to value NO_STATE_MAINTAINED then the DOCA 257 client MUST NOT proceed to the 'established state' (see Section 2.5) 258 and the possible information exchanged during the DOCA-Report- 259 Request/Answer concerns only this one message exchange. 261 In a case two nodes enter the initialization phase simultaneously, 262 the election algorithm as defined in [I-D.ietf-dime-rfc3588bis] is 263 applied to select the 'client'. The winner of the election process 264 becomes the 'client' of the DOCA session. Once the initialization 265 state has completed, i.e. the 'server' has sent a DOCA-Report-Answer 266 with a success Result-Code and the 'client' has received a DOCA- 267 Report-Answer, then the DOCA session shifts to the 'established 268 state' (see Section 2.5). 270 The agreed parameter set MUST be a set of parameters that both the 271 'client' and the 'server' have in common. Of course, the Diameter 272 nodes do not need to advertise all the parameter they have, rather a 273 subset based on some local policy. 275 2.3. Initialization state with NO_STATE_MAINTAINED 277 A DOCA client that wishes not to maintain a session state MUST set 278 the Auth-Session-State AVP to the value NO_STATE_MAINTAINED and 279 SHOULD include the OC-Information AVP with overload information into 280 the DOCA-Report-Request it sends to a DOCA server. If the DOCA 281 server cannot agree on a 'stateless' DOCA overload information 282 exchange it MUST answer with a DOCA-Report-Response including the 283 Result-Code AVP set to value DIAMETER_INVALID_AVP_VALUE and the 284 Failed-AVP AVP containing the Auth-Session-State AVP. If the DOCA 285 server agrees on a 'stateless' DOCA overload information exchange, 286 then the answer DOCA-Report-Response message MUST contain the Auth- 287 Session-State AVP set to value NO_STATE_MAINTAINED. 289 The use of 'stateless' DOCA overload information exchange SHOULD be 290 used with caution. In principle each DOCA-Report-Request/Answer 291 message exchange is independent and the DOCA client and peer MAY have 292 conflicting views on the supported parameters and information 293 content. This may lead to an exchange of information that is a) 294 always silently discarded by the other end and b) considered just as 295 excess signaling. It RECOMMENDED that the 'stateless' DOCA usage is 296 limited into a single realm only. 298 If the 'stateless' use of DOCA is preferred, any the DOCA capable 299 Diameter node MAY initiate a DOCA-Report-Request at any given time. 300 The receiver of the DOCA-Report-Request acknowledges with a DOCA- 301 Report-Answer and includes the Result-Code AVP indicating whether it 302 could honor the action/report in the request. The DOCA-Report-Answer 303 SHOULD also piggyback overload control information. 305 When the session state is not maintained, the DOCA client is 306 implicitly in an 'established state'. The consideration regarding 307 various DOCA related timers serve only as a hint as they cannot be 308 formally mandated due the lack of the session state. 310 2.4. Renegotiation and termination of the session 312 The following applies only when the session state is maintained. If 313 there is a need to renegotiate parameters, the DOCA client just sends 314 a DOCA-Report-Request with a new parameter set and enters the 315 initialization state. Similarly, the DOCA server can request a 316 renegotiation of the parameters by sending a Re-Auth-Request to the 317 DOCA client, which then eventually enters the initialization state. 318 The DOCA server MAY hint about the new parameter set by including 319 specific DOCA AVPs into the Re-Auth-Request. A DOCA session is 320 terminated using the standard Session-Termination-Request/Answer 321 and/or Abort-Session-Request/Answer exchange. 323 2.5. Established state and the distribution of the overload control 324 information 326 2.5.1. Diameter client and server behavior 328 Either the DOCA client or server MAY initiate a DOCA-Report-Request 329 at any given time. The receiver of the DOCA-Report-Request 330 acknowledges with a DOCA-Report-Answer and includes the Result-Code 331 AVP indicating whether it could honor the action/report in the 332 request. The DOCA-Report-Answer SHOULD also piggyback overload 333 control information instead of the responder initiating a DOCA- 334 Report-Request immediately after responding with the DOCA-Report- 335 Answer, assuming an overload control information reporting has been 336 scheduled to the near future. 338 A care should be taken not to send DOCA-Report-Requests too 339 frequently. The sending rate, in a case of normal status reporting, 340 SHOULD follow the Tolc timer negotiated during the initialization 341 state. In case of emerging overload situation and once the overload 342 situation normalizes, the node is allowed to send a DOCA-Report- 343 Request regardless of the Tolc timer value (which also leads to 344 resetting the Tolc timer). 346 When a Diameter node receives overload control information and is 347 also requested to act on it, the DOCA functionality is applied to all 348 specified applications within a given scope. How the Diameter node 349 accomplishes the node wide DOCA action enforcement is implementation 350 specific. 352 When a Diameter node receives (interim) overload information but the 353 overload condition has not started, then the receiver is not required 354 to act based on the received information. However, it is RECOMMENDED 355 that the receiver makes proactive actions to avoid entering the 356 overload condition based on the newly received overload information. 358 2.5.2. Diameter agent behavior 360 There can be zero or more intermediate Diameter agents on the path 361 between the DOCA client and the server. Understanding the DOCA 362 functionality is not expected from both Relay and Redirect agents. A 363 Diameter proxy, which obviously understands the DOCA application, MAY 364 inspect the DOCA related AVPs in the DOCA-Report-Request/Answer 365 message pair and depending on the value of the OC-Scope AVP (see 366 Section 4.2) inject its own information. A proxy is always 367 RECOMMENDED to react according to the overload information when it 368 comes to, for example, peer selection and traffic throttling. [Note: 369 in practice there is no way to prohibit proxies to mangle AVPs due 370 the lack of proper end-to-end security] 372 When a Diameter agent receives overload control information and is 373 also requested to act on it, the DOCA functionality is applied to all 374 specified applications within a given scope. How the Diameter agent 375 accomplishes the node wide DOCA action enforcement is implementation 376 specific. 378 3. DOCA-Report-Request/Answer Commands 380 The DOCA-Report-Request (DRR) is used to report overload condition 381 information. The message can be originated as a result of emerging 382 overload condition or as a periodic unsolicited report. 384 ::= < Diameter Header: TBD2, REQ, PXY > 385 < Session-Id > 386 { Auth-Application-Id } 387 { Origin-Host } 388 { Origin-Realm } 389 { Destination-Realm } 390 { Auth-Request-Type } 391 { Destination-Host } 392 [ Auth-Session-State ] 393 * [ Class ] 394 [ Origin-State-Id ] 395 * [ Proxy-Info ] 396 * [ Route-Record ] 398 { OC-Scope } 399 [ OC-Algorithm ] 400 [ OC-Action ] 401 [ OC-Tocl ] 402 [ OC-Applications ] 403 * [ OC-Information ] 405 * [ AVP ] 407 The DOCA-Report-Answer (DRA) is used as a response to the DOCA- 408 Report-Request. The message MAY piggyback overload condition 409 information in order to avoid unnecessary DOCA-Report-Request 410 messages to the opposite direction. 412 ::= < Diameter Header: TBD2, PXY > 413 < Session-Id > 414 { Result-Code } 415 { Origin-Host } 416 { Origin-Realm } 417 [ Auth-Session-State ] 418 * [ Class ] 419 [ Error-Message ] 420 [ Error-Reporting-Host ] 421 [ Failed-AVP ] 422 [ Origin-State-Id ] 423 * [ Redirect-Host ] 424 [ Redirect-Host-Usage ] 425 [ Redirect-Max-Cache-Time ] 426 * [ Proxy-Info ] 428 { OC-Scope } 429 [ OC-Algorithm ] 430 [ OC-Action ] 431 [ OC-Tocl ] 432 [ OC-Applications ] 433 * [ OC-Information ] 435 * [ AVP ] 437 The OC-Algorithm, OC-Tocl and OC-Applications AVPs can be left out 438 when the DOCA peers do not maintain state. These AVPs at main level 439 of the command are meant for the state maintaining mode negotiation 440 of the overload information set of interest. 442 4. Attribute Value Pairs 444 4.1. OC-Information AVP 446 The OC-Information AVP (AVP Code TBD3) is of type Grouped and 447 contains a set AVPs that identify the source of the overload control 448 information (the OC-Origin AVP), the overload information itself and 449 which applications the information concerns. 451 OC-Information ::= < AVP Header: TBD3 > 452 { OC-Origin } 453 { OC-Best-Before } 454 [ OC-Level ] 455 [ OC-Algorithm ] 456 [ OC-Sending-Rate ] 457 [ Vendor-Id ] 458 [ OC-Applications ] 459 [ Product-Name ] 460 [ OC-Utilization ] 461 [ OC-Priority ] 462 * [ AVP ] 464 Depending on the negotiated scope (see Section 4.2) any Diameter node 465 on path MAY add one or more OC-Information AVPs into the DOCA-Report- 466 Request/answer messages. 468 4.2. OC-Scope AVP 470 The OC-Scope (AVP Code TBD4) is of type Unsigned32 and contains the 471 scope where and concerning what the overload control information can 472 be injected. The OC-Scope is formatted as a vector of scope flag 473 bits. The following scopes are supported: 475 Host scope (0x00000001) 477 The OC-Information AVP concerns only a single host within a realm 478 (which internally MAY represent of pool). 480 Realm scope (0x00000002) 482 The OC-Information AVP concerns a realm. No specific hosts are 483 identified. 485 Only origin realm (0x00000004) 487 The OC-Information AVP can only be included by a Diameter node on 488 the path that has the same Origin-Realm as the DOCA client. 490 Application information (0x00010000) 492 The OC-Information AVP MAY contain application related information 493 (the OC-Applications AVP). 495 Node utilization information (0x00020000) 497 The OC-Information AVP MAY contain node wide load related 498 information (the OC-Utilization AVP). 500 Application priorities (0x00040000) 502 The OC-Information AVP SHOULD priority information (the OC- 503 Priority AVP) so when the overload condition is on, Diameter nodes 504 are able to prioritize between different applications, for 505 example, when dropping or throttling messages. 507 Any other value is reserved. 509 A scope is active when a corresponding flag is set in the OC-Scope 510 AVP. During the initialization state a DOCA client includes those 511 scopes it supports and is interested in. A DOCA server then returns 512 the scope that it has in common with the DOCA client (and intends to 513 use). The common scopes are then used during the established state. 514 Note that some scope combinations make little sense while still being 515 valid. The general guide when multiple scopes collide is that the 516 least restrictive wins. 518 A sender of the overload information MUST adhere to the scope it 519 announces regarding the information it itself sends. 521 If a DOCA server does not have a common scope with a DOCA client or 522 the DOCA server cannot agree on one based on a local policy, then the 523 DOCA server MUST send the DOCA-Report-Answer indicating an error and 524 set the Result-Code to the DIAMETER_NO_COMMON_SCOPE value. 526 4.3. OC-Applications AVP 528 The OC-Applications (AVP Code TBD5) is of type Grouped and contains a 529 list of Application-IDs of interest when found in the DOCA-Report- 530 Request/Answer command main level and meant to be used during the 531 initialization state to agree on the common set of supported 532 applications of monitoring interest. When used within the OC- 533 Information AVP, the OC-Applications AVP identify those applications 534 the overload information concerns. The OC-Applications AVPs on the 535 command main level and inside the OC-Information AVP MUST NOT have 536 conflicting views of the applications of interest. However, the OC- 537 Applications AVP can be see as a superset of applications i.e., not 538 all applications of interest need to be included every time into the 539 OC-Information AVP. 541 OC-Applications ::= < AVP Header: TBD3 > 542 * [ Auth-Application-Id ] 543 * [ Acct-Application-Id ] 544 * [ Vendor-Specific-Application-Id ] 545 * [ AVP ] 547 The absence of the OC-Applications AVP indicates the Diameter node 548 has no specific preference or interest in specific applications. The 549 overload information is then signalled as concerning the whole 550 Diameter node. This default behavior is useful when the DOCA does 551 not maintain session state. If there are no common applications, 552 then the DOCA-Report-Answer MUST contain the Result-Code with the 553 DIAMETER_NO_COMMON_APPLICATION value. 555 When the DOCA maintains state, there is no need to include the OC- 556 Applications AVP into the DOCA-Report-Request/Answer command main 557 level after the initial message exchange. The agreed common set of 558 application is expected to be known by both DOCA client and server 559 throughout the session lifetime. 561 4.4. OC-Action AVP 563 The OC-Action (AVP Code TBD6) is of type OctetString and size of one 564 octet. The octet has the following three possible values: 566 Start (1) 568 Signals the start of the overload condition. This implies the 569 receiver is requested to act according to the information found in 570 the OC-Information. 572 Stop (2) 574 Signals the end of the overload condition. 576 Interim (3) 578 Updates the overload information. The interim can be sent during 579 the overload condition or during the normal condition. This is 580 the default value. 582 Any other value is reserved. 584 4.5. OC-Algorithm AVP 586 The OC-Algorithm (AVP Code TBD7) is of type Unsigned32. The contains 587 supported 'algorithms' to mitigate the overload condition. The OC- 588 Algorithm AVP is formatted as a vector of algorithm flag bits. The 589 following 'algorithms' are supported: 591 Drop (0x00000001) 593 Messages are plain dropped. It is RECOMMENDED to drop messages 594 selectively based, for example, on application priorities. This 595 is the default algorithm. 597 Throttle (0x00000002) 599 The message sending rate is according to the OC-Sending-Rate AVP. 601 Prioritize (0x00000004) 603 Apply priorities among applications and the other used means for 604 holding traffic. 606 Any other value is reserved. 608 The 'algorithms' are only applied at a Diameter node when the 609 overload condition has been signaled. 611 During the initialization state a DOCA client includes those 612 algorithms it supports and is interested in. A DOCA server then 613 returns the algorithm that it has in common with the DOCA client (and 614 intends to use). One or more common algorithms are then used during 615 the established state. 617 If a DOCA server does not have a common algorithm with a DOCA client 618 or the DOCA server cannot agree on one based on a local policy, then 619 the DOCA server MUST send the DOCA-Report-Answer indicating an error 620 and set the Result-Code to the DIAMETER_NO_COMMON_ALGORITHM value. 622 4.6. OC-Level AVP 624 The OC-Level (AVP Code TBD8) is of type OctetString and size of one 625 octet. The octet has the following five possible values: 627 Normal (1) 629 Everything is in control. Meaningful only when the OC-Action is 630 set to 'Interim' since when the overload condition level is 631 considered normal, the overload condition SHOULD be stopped. This 632 is the default value. 634 Raising (2) 636 There is a sign of increasing load. 638 Alarming (3) 640 The overload condition is reaching the level where quick measures 641 SHOULD be done to mitigate the overload condition. 643 Panic (4) 645 The overload condition is severe. Apply any measure to mitigate 646 the overload condition but still allowed to send messages. 648 Hold (5) 650 Do not send any messages, please. When this level is signaled, 651 the OC-Best-Before time SHOULD NOT be respected but an explicit 652 overload condition stop has to be received (with an exception the 653 Diameter node realizes its other end has rebooted or otherwise 654 lost its state). 656 Switch servers (6) 658 Do not talk to me again. When this level is signaled, the DOCA 659 peer MUST switch to an alternative server. 661 Any other value is reserved. 663 If the receiver cannot agree on or does not understand the OC-Level 664 AVP value, the an error MUST be returned with the Result-Code AVP set 665 to the value DIAMETER_INVALID_AVP_VALUE and the Failed-AVP AVP 666 containing the OC-Level AVP. 668 4.7. OC-Utilization AVP 670 The OC-Utilization (AVP Code TBD9) is of type Float32 and tells the 671 overall utilization level percentage of the Diameter node. Values 672 between 0.0 to 100.0 are valid. 674 4.8. OC-Tocl AVP 676 The OC-Tocl (AVP Code TBD10) is of type Unsigned32 and tells the Tolc 677 timer value in milliseconds. This timer defines the interval for 678 sending periodic DOCA-Report-Request messages with the OC-Action AVP 679 set to 'Interim'. The value of zero (0) means no periodic DOCA- 680 Report-Request messages are sent or desired. The default value is 681 120000. 683 During the initialization state both a DOCA client and server express 684 their preferred Tolc value for receiving periodic updates. As a 685 result both ends will have their own Tolc values. 687 If a DOCA server find the Tocl value proposed by a DOCA client either 688 too small (i.e. too frequent periodic messages) or too big (i.e. too 689 seldom periodic messages), then the DOCA server MUST send the DOCA- 690 Report-Answer indicating an error and set the Result-Code either to 691 the DIAMETER_TOCL_TOO_SMALL or DIAMETER_TOCL_TOO_BIG value. 693 In the case of 'stateless' DOCA usage, the OC-Tocl AVP can be 694 considered as a hint for a desired sending rate of subsequent 695 messages. 697 4.9. OC-Sending-Rate AVP 699 The OC-Sending-Rate (AVP Code TBD11) is of type Float32 and tells the 700 the maximum Diameter message sending rate per second the sender of 701 this information wishes to receive Diameter messages. Only positive 702 values are valid. A value of zero (0.0) of the absence of this AVP 703 means the information sender has no specific rate preference. 705 If a DOCA server finds the sending rate value proposed by a DOCA 706 client too big (i.e. too frequent periodic messages), then the DOCA 707 server MUST send the DOCA-Report-Answer indicating an error and set 708 the Result-Code to the DIAMETER_RATE_TOO_BIG value. 710 4.10. OC-Best-Before AVP 712 The OC-Best-Before (AVP Code TBD12) is of type Time and tells the 713 expiration time/date for the information received in the OC- 714 Information. For example, when the overload condition is on, the 715 expiration of the 'best before' timer causes the same as receiving a 716 DOCA-Report-Request/Answer with the OC-Action set to 'Stop'. 718 [Editor's node: to be decided whether a duration timer is a better 719 measure. Using Time has the assumptions nodes have actually 720 clocks that a running approximately same time.] 722 4.11. OC-Origin AVP 724 The OC-Origin (AVP Code TBD13) is of type DiameterIdentity and tells 725 the identity of the Diameter node that originated included the 726 overload control information. Both host and realm information MUST 727 be included in the OC-Origin AVP. Note, if the OC-Scope AVP 728 indicates only a realm wide scope for the overload information, then 729 the realm part of the OC-Origin AVP is meaningful and the host 730 information only serves as an additional information of the 731 representative for the realm wide information. 733 4.12. OC-Priority AVP 735 The OC-Priority (AVP Code TBD14) is of type Unsigned32 and defines 736 the priority level. The value of 0x00000000 is the highest priority 737 and the value of 0xffffffff is the lowest priority. The absence of 738 the OC-Priority AVP means there is not specific priority level 739 defined and the priority SHOULD be considered as the lowest possible. 741 When used within the OC-Information grouped AVP, the OC-Priority AVP 742 defines the priority for the listed applications within the OC- 743 Applications AVP. 745 4.13. Attribute Value Pair flag rules 747 +---------+ 748 |AVP flag | 749 |rules | 750 +----+----+ 751 AVP Section | |MUST| 752 Attribute Name Code Defined Value Type |MUST| NOT| 753 +---------------------------------------------------+----+----+ 754 |OC-Information TBD3 x.x Grouped | M | V | 755 +---------------------------------------------------+----+----+ 756 |OC-Scope TBD4 x.x Unsigned32 | M | V | 757 +---------------------------------------------------+----+----+ 758 |OC-Application TBD5 x.x Grouped | M | V | 759 +---------------------------------------------------+----+----+ 760 |OC-Action TBD6 x.x OctetString | M | V | 761 +---------------------------------------------------+----+----+ 762 |OC-Algorithm TBD7 x.x Unsigned32 | M | V | 763 +---------------------------------------------------+----+----+ 764 |OC-Level TBD8 x.x OctetString | M | V | 765 +---------------------------------------------------+----+----+ 766 |OC-Utilization TBD9 x.x Float32 | M | V | 767 +---------------------------------------------------+----+----+ 768 |OC-Tocl TBD10 x.x Unsigned32 | M | V | 769 +---------------------------------------------------+----+----+ 770 |OC-Sending-Rate TBD11 x.x Float32 | M | V | 771 +---------------------------------------------------+----+----+ 772 |OC-Best-Before TBD12 x.x Time | M | V | 773 +---------------------------------------------------+----+----+ 774 |OC-Origin TBD13 x.x DiameterIdentity | M | V | 775 +---------------------------------------------------+----+----+ 776 |OC-Priority TBD14 x.x Unsigned32 | M | V | 777 +---------------------------------------------------+----+----+ 779 5. Transport considerations 781 In case of Stream Control Transmission Protocol (SCTP) transport, the 782 DOCA application is RECOMMENDED to mark its Diameter packets using 783 the DOCA defined SCTP Payload Protocol Identifier (PPID) TBD1. The 784 PPID MAY be used by intermediating network nodes or agents to peek 785 into SCTP message and find out that this is about overload control. 786 Such information can be used for prioritizing SCTP packet handling as 787 an example. 789 6. Deployment considerations 791 6.1. Overload information propagation with STATE_MAINTAINED 793 The following example shows how a DOCA session is created and the 794 vital capabilities are negotiated. The OC-Scope AVP has no "Only 795 origin realm" set, which allows for any node of the path add their 796 overload information into the DOCA messages. The proxy on the edge 797 of the example.org makes use of this. Note that if an intermediate 798 node from other realm than the originating realm (example.net) adds 799 additional information that is for informational purposes only. The 800 reason is that only the message originator can set the OC-Action AVP 801 value. 803 TBD. 805 DOCA Proxy Proxy DOCA 806 Client (pool) example.net example.org Server 807 | | | | 808 : : : : 809 | | | | 810 | | | | 812 6.2. Overload information propagation with NO_STATE_MAINTAINED 814 The following example shows how a 'stateless' DOCA usage could be 815 done. Note that both client and server are within the same realm. 817 TBD. 819 DOCA Proxy Proxy DOCA 820 Client (pool) example.net example.net Server 821 | | | | 822 : : : : 823 | | | | 824 | | | | 826 7. IANA Considerations 828 7.1. Application Identifiers 830 This specification reserves a new Diameter Application-ID TBD14 for 831 the Diameter Overload Control Application (DOCA) from the 832 'Authentication, Authorization, and Accounting (AAA) Parameters' 833 Application IDs registry. 835 7.2. SCTP Payload Protocol Identifier 837 Section 5 reserves a new SCTP Payload Protocol Identifier for the 838 DOCA application usage. The value is reserved from the existing SCTP 839 Payload Protocol Identifiers registry. 841 7.3. Command codes 843 One Diameter command is defined in Section Section 3. The DOCA- 844 Report-Request/Answer Command Code is TBD2. Both are allocated from 845 the 'Authentication, Authorization, and Accounting (AAA) Parameters' 846 Command Codes registry. 848 7.4. AVP codes 850 New AVPs defined by this specification are listed in Section 4. All 851 AVP codes allocated from the 'Authentication, Authorization, and 852 Accounting (AAA) Parameters' AVP Codes registry. 854 7.5. Result-Code values 856 This specification adds several Diameter Overload Control Application 857 specific Permanent Failure codes from the 'Authentication, 858 Authorization, and Accounting (AAA) Parameters' Result-Code AVP 859 Values (code 268) - Permanent Failure registry: 861 AVP Values | Attribute Name | Reference 862 -----------+-------------------------------+---------- 863 5xxx | DIAMETER_NO_COMMON_SCOPE | RFCxxxx 864 5xxx | DIAMETER_NO_COMMON_ALGORITHM | RFCxxxx 865 5xxx | DIAMETER_TOCL_TOO_SMALL | RFCxxxx 866 5xxx | DIAMETER_TOCL_TOO_BIG | RFCxxxx 867 5xxx | DIAMETER_RATE_TOO_BIG | RFCxxxx 869 7.6. New registries 871 Four new registries are needed under the 'Authentication, 872 Authorization, and Accounting (AAA) Parameters' registry: 874 o OC-Scope AVP Values: the policy for this registry is Specification 875 Required. 876 o OC-Action AVP Values: the policy for this registry is Standards 877 Action. 878 o OC-Level AVP Values: the policy for this registry is Standards 879 Action. 880 o OC-Algorithm AVP Values: the policy for this registry is 881 Specification Required. 883 8. Security Considerations 885 The security properties of the Diameter Overload Control Application 886 (DOCA) follow the general [I-D.ietf-dime-rfc3588bis] security model. 887 This implies there is no proper means to verify the message and AVP 888 content correctness if multiple intermediate Diameter agents are 889 present on the path between the DOCA client and server. As a result 890 a malicious intermediate could feed incorrect overload control 891 information to DOCA clients and peers, and thus affect negatively to 892 the overload condition recovery. Possible ways to overcome the 893 obvious security vulnerability are mandating only end to end 894 transport connections between DOCA clients and servers, or some 895 future specification defining an end to end security for the DOCA. 897 9. Acknowledgements 899 The author thanks Annett Seefeldt for her constructive comments on 900 the technical aspects on this document. 902 10. References 904 10.1. Normative References 906 [I-D.ietf-dime-rfc3588bis] 907 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 908 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 909 (work in progress), June 2012. 911 [I-D.mcmurry-dime-overload-reqs] 912 McMurry, E. and B. Campbell, "Diameter Overload Control 913 Requirements", draft-mcmurry-dime-overload-reqs-01 (work 914 in progress), June 2012. 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, March 1997. 919 10.2. Informative References 921 [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter 922 Straightforward-Naming Authority Pointer (S-NAPTR) Usage", 923 RFC 6408, November 2011. 925 Author's Address 927 Jouni Korhonen (editor) 928 Nokia Siemens Networks 929 Linnoitustie 6 930 Espoo FIN-02600 931 Finland 933 Email: jouni.nospam@gmail.com