idnits 2.17.1 draft-tschofenig-dime-overload-piggybacking-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 3936 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-07 == Outdated reference: A later version (-03) exists of draft-korhonen-dime-e2e-security-02 Summary: 0 errors (**), 0 flaws (~~), 4 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 Piggybacking 8 draft-tschofenig-dime-overload-piggybacking-00.txt 10 Abstract 12 This document describes how to piggyback Diameter overload 13 information between Diameter servers and Diameter clients. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 17, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Information Exchanges . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Capability Indication . . . . . . . . . . . . . . . . . . 3 53 3.2. Overload Information . . . . . . . . . . . . . . . . . . 3 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 7.2. Informative References . . . . . . . . . . . . . . . . . 4 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 The problem statement for Diameter overload control can be found in 65 [3]. It describes the lack of support of conveying load information 66 to enable load balancing of Diameter requests in case Diameter 67 servers become overload and the inability of Diameter servers to 68 communicate with Diameter clients to reject requests when they become 69 severely overloaded. [5] goes a step further in providing an outline 70 of architectural principles and an information model. 72 This document is an extension to [5] and defines how Diameter servers 73 interact with Diameter clients to report about overload situations. 74 This is accomplished by piggybacking overload information from the 75 Diameter server to the Diameter client within existing Diameter 76 applications, as long as extension points allow adding new AVPs. 78 Communication overload information to Diameter clients is the last 79 resource when load balancing is either not available, when all 80 available servers are already overloaded, or when a critical failure 81 occurred since this will lead to the Diameter client rejecting 82 requests and returning appropriate error messages to end devices via 83 the front-end protocols (such as SIP). 85 2. Terminology 87 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 88 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 89 specification are to be interpreted as described in [1]. 91 This document re-uses terminology from the Diameter base 92 specification [2]. 94 3. Information Exchanges 96 3.1. Capability Indication 98 The Diameter protocol interaction starts with a Diameter client using 99 some Diameter application. The Diameter client MUST add the 100 Supported-Features AVP to indicate support for the functionality 101 supported for overload control. The Supported-Features AVP MUST NOT 102 have the M-bit set since this would require a Diameter application to 103 be defined. 105 A Diameter server receiving the Supported-Features AVP from a client 106 is therefore able to know that this client supports the Diameter 107 overload information exchange capability. Otherwise only the 108 Diameter Base protocol functionality [2] with DIAMETER_TOO_BUSY error 109 message is available. This enables feature discovery and a graceful 110 fall-back to the functionality available with the Diameter Base 111 protocol 113 3.2. Overload Information 115 In the rare and unlikely event of an overload situation the Diameter 116 server (or a proxy, such as a load balancer, acting on behalf of 117 several Diameter servers) may decide to communicate to the Diameter 118 client to reject some or even all Diameter requests. The Diameter 119 server does so by adding the Overload-Info AVP, which contains the 120 Overload and the Period-Of-Validity AVP. The semantic of the 121 Overload and the Period-Of-Validity AVP is described in [5]. To 122 inform the Diameter client to reject requests the value of the 123 Overload AVP is set to 'INCREASING_OVERLOAD' or to 'OVERLOADED'. The 124 Diameter server may instruct the client to gradually reduce the 125 number of requests by using the Overload='INCREASING_OVERLOAD' 126 marking on several subsequent messages. The Period-Of-Validity AVP 127 allows the Diameter server to give the "rejection policy" a soft- 128 state nature, i.e., it will automatically expire without leaving 129 orphan state at the Diameter client in case of a Diameter server 130 failure or other error situations. 132 A Diameter client that has received information to reduce the number 133 of Diameter requests has to evaluate the requests based on their 134 destination and their applications. 136 In case the Diameter server recovers and is able to accept more 137 Diameter requests it can signal this changed state to the client with 138 the 'DECREASING_OVERLOAD' or the 'NO_OVERLOAD' directive. Waiting 139 for the expiry of the state is another option at the disposal of the 140 Diameter server. 142 4. Security Considerations 144 This document utilizes the AVP defined in [5]. The ability to use 145 end-to-end signaling allows the Diameter AVP level security 146 mechanisms, described in [4], to be re-used. Since the communicated 147 rejection policies are bound to the application and the realm from an 148 earlier request the ability to inject fake message is less likely. 150 5. IANA Considerations 152 This document does not require actions by IANA. 154 6. Acknowledgments 156 Add your name here. 158 7. References 160 7.1. Normative References 162 [1] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, March 1997. 165 [2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 166 "Diameter Base Protocol", RFC 6733, October 2012. 168 7.2. Informative References 170 [3] McMurry, E. and B. Campbell, "Diameter Overload Control 171 Requirements", draft-ietf-dime-overload-reqs-07 (work in 172 progress), June 2013. 174 [4] Korhonen, J. and H. Tschofenig, "Diameter AVP Level 175 Security: Keyed Message Digests, Digital Signatures, and 176 Encryption", draft-korhonen-dime-e2e-security-02 (work in 177 progress), July 2013. 179 [5] Tschofenig, Hannes., "Diameter Overload Architecture and 180 Information Model", July 2013. 182 Author's Address 183 Hannes Tschofenig 184 Nokia Siemens Networks 185 Linnoitustie 6 186 Espoo 02600 187 Finland 189 Phone: +358 (50) 4871445 190 Email: Hannes.Tschofenig@gmx.net 191 URI: http://www.tschofenig.priv.at