idnits 2.17.00 (12 Aug 2021) /tmp/idnits37261/draft-tschofenig-dime-dlba-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 == Line 180 has weird spacing: '... Code in ...' -- 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 -- No information found for draft-tschofenig-dime-overload-arch - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track July 16, 2013 5 Expires: January 17, 2014 7 The Diameter Load Balancing Application (DLBA) 8 draft-tschofenig-dime-dlba-00.txt 10 Abstract 12 This specification documents a Diameter Load Balancing Application 13 (DLBA), which uses the normal Diameter application approach for the 14 capability negotiation, propagation and management of Diameter load 15 information between Diameter nodes to enable load balancing of 16 Diameter requests. 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 January 17, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Attribute Value Pair Flag Rules . . . . . . . . . . . . . . . 4 56 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Transport Considerations . . . . . . . . . . . . . . . . . . 5 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Application Identifiers . . . . . . . . . . . . . . . . . 5 60 7.2. SCTP Payload Protocol Identifier . . . . . . . . . . . . 6 61 7.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 6 62 7.4. Result-Code Values . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 10.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The problem statement for Diameter overload control can be found in 73 [I-D.ietf-dime-overload-reqs]. It describes the lack of support of 74 conveying load information to enable load balancing of Diameter 75 requests in case Diameter servers become overload and the inability 76 of Diameter servers to communicate with Diameter clients to reject 77 requests when they become severely overloaded. 78 [I-D.tschofenig-dime-overload-arch] goes a step further in providing 79 an outline of architectural principles and an information model. 81 This document specifies Diameter Load Balancing Application (DLBA), 82 which uses the AVPs defined in [I-D.tschofenig-dime-overload-arch]. 83 As the name indicates, this document focuses on load balancing. 85 The Diameter Load Balancing Application (DLBA) typically runs between 86 a load balancer and a Diameter server. The load balancer may act as 87 a DLBA client and the Diameter server as a DLBA server but the roles 88 may also be reversed without loss in protocol functionality since 89 Diameter is flexible as a protocol. There may be zero or more 90 intermediate Diameter agents on the path between the DLBA client and 91 the DLBA server. Understanding the DLBA functionality is not 92 expected from relays and redirect agents. 94 The main usage for this application is within a single realm, as 95 shown in Figure 2 of [I-D.tschofenig-dime-overload-arch], where a 96 load balancer distributes incoming Diameter requests to different 97 Diameter servers. Designing the load balancing functionality as a 98 stand-alone application prevents Diameter servers and load balancers 99 to adjust their information exchange frequency to meet the needs of 100 the network administrator regardless of remaining Diameter 101 application traffic. 103 2. Requirements 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Commands 111 The DLBA-Report-Request message is used to request load information. 113 ::= < Diameter Header: TBD2, REQ, PXY > 114 < Session-Id > 115 { Auth-Application-Id } 116 { Origin-Host } 117 { Origin-Realm } 118 { Destination-Realm } 119 { Auth-Request-Type } 120 { Destination-Host } 121 [ Auth-Session-State ] 122 * [ Class ] 123 [ Origin-State-Id ] 124 * [ Proxy-Info ] 125 * [ Route-Record ] 127 [ Supported-Features ] 128 [ Sending-Rate ] 129 [ Load-Info ] 130 * [ AVP ] 132 The DLBA-Report-Answer message is used as a response to the DLBA- 133 Report-Request. The message MAY piggyback load information in order 134 to avoid unnecessary DLBA-Report-Request messages in the reverse 135 direction. 137 ::= < Diameter Header: TBD2, PXY > 138 < Session-Id > 139 { Result-Code } 140 { Origin-Host } 141 { Origin-Realm } 142 [ Auth-Session-State ] 143 * [ Class ] 144 [ Error-Message ] 146 [ Error-Reporting-Host ] 147 [ Failed-AVP ] 148 [ Origin-State-Id ] 149 * [ Redirect-Host ] 150 [ Redirect-Host-Usage ] 151 [ Redirect-Max-Cache-Time ] 152 * [ Proxy-Info ] 154 [ Supported-Features ] 155 [ Sending-Rate ] 156 [ Load-Info ] 157 * [ AVP ] 159 Diameter is flexible from a message handling point of view. 160 Therefore, any the DLBA capable Diameter node, such as a load 161 balancer or a Diameter server, MAY initiate a DLBA-Report-Request at 162 any given time. The receiver of the DLBA-Report-Request responds 163 with a DLBA-Report-Answer and includes the Result-Code AVP indicating 164 whether it could honor the action/report in the request. The DLBA- 165 Report-Answer SHOULD also piggyback load information. 167 A DLBA client MUST set the Auth-Session-State AVP to the value 168 NO_STATE_MAINTAINED and SHOULD include load information into the 169 DLBA-Report-Request message, if available. The DLBA-Report-Response 170 message MUST contain the Auth-Session-State AVP set to value 171 NO_STATE_MAINTAINED. 173 4. Attribute Value Pair Flag Rules 175 +---------+ 176 |AVP flag | 177 |rules | 178 +----+----+ 179 AVP Defined | |MUST| 180 Attribute Name Code in Value Type |MUST| NOT| 181 +-----------------------------------------------------+----+----+ 182 |Load-Info TBD RFC XYZ Grouped | M | V | 183 +-----------------------------------------------------+----+----+ 184 |Load TBD RFC XYZ Unsigned32 | M | V | 185 +-----------------------------------------------------+----+----+ 186 |Supported-Features TBD RFC XYZ Uint64 | M | V | 187 +-----------------------------------------------------+----+----+ 188 |Sending-Rate TBD RFC XYZ Unsigned32 | M | V | 189 +-----------------------------------------------------+----+----+ 191 All AVPs are defined in [I-D.tschofenig-dime-overload-arch]. 193 5. Example 195 This example shows the simplicity of the DLBA application. Here the 196 load balancer initiates the DLBA exchange and solicits load 197 information from a Diameter server. The rate at which these messages 198 are exchange depend on the Sending-Rate AVP. The Diameter server 199 may, however, at any time send an unsolicited DLBA-Report-Request 200 message in case the load situation changes unexpectedly. 202 Diameter-based Diameter 203 Load Balancer Server 204 | | 205 | DLBA-Report-Request Command | 206 | Supported-Features AVP | 207 | Sending-Rate AVP | 208 |------------------------------>| 209 | | 210 | | 211 | DLBA-Report-Answer Command | 212 | Load AVP | 213 |<------------------------------| 214 | | 215 : : 216 : : 217 | | 218 |...more load info exchanges... | 219 | | 220 | | 222 6. Transport Considerations 224 In case of Stream Control Transmission Protocol (SCTP) transport, it 225 is RECOMMENDED to mark Diameter packets using the DLBA defined SCTP 226 Payload Protocol Identifier (PPID) TBD1. The PPID MAY be used by 227 intermediating network nodes or agents to peek into SCTP message and 228 find out that this is about overload control. Such information can 229 be used for prioritizing SCTP packet handling as an example. 231 7. IANA Considerations 233 7.1. Application Identifiers 235 This specification reserves a new Diameter Application-ID TBD14 for 236 the Diameter Load Balancing Application (DLBA) from the 237 'Authentication, Authorization, and Accounting (AAA) Parameters' 238 Application IDs registry. 240 7.2. SCTP Payload Protocol Identifier 242 Section 6 reserves a new SCTP Payload Protocol Identifier for the 243 DLBA application usage. The value is reserved from the existing SCTP 244 Payload Protocol Identifiers registry. 246 7.3. Command Codes 248 Two command codes are defined in Section 3. The DLBA-Report-Request 249 Command Code is TBD and the DLBA-Report-Answer Command Code is TBD. 250 Both are allocated from the 'Authentication, Authorization, and 251 Accounting (AAA) Parameters' Command Codes registry. 253 7.4. Result-Code Values 255 This specification adds Diameter Overload Control Application 256 specific Permanent Failure codes from the 'Authentication, 257 Authorization, and Accounting (AAA) Parameters' Result-Code AVP 258 Values (code 268) - Permanent Failure registry: 260 AVP Values | Attribute Name | Reference 261 -----------+-------------------------------+---------- 262 5xxx | DIAMETER_RATE_TOO_BIG | RFCxxxx 263 5xxx | DIAMETER_NO_COMMON-FEATURES | RFCxxxx 265 8. Security Considerations 267 This Diameter application uses the Diameter [RFC6733] security 268 mechanisms and, what is more important, is primarily used within a 269 single realm to allow a load balancer to obtain load information from 270 Diameter servers for distributing Diameter requests depending on the 271 utilization of these servers. Passing load information beyond an 272 administrative domain is possible with Diameter but not advisable to 273 avoid leaking valuable information to potentially untrustworthy 274 parties. 276 9. Acknowledgements 278 This document re-uses the design from the Diameter-OVL application. 280 10. References 281 10.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 287 "Diameter Base Protocol", RFC 6733, October 2012. 289 10.2. Informative References 291 [I-D.ietf-dime-overload-reqs] 292 McMurry, E. and B. Campbell, "Diameter Overload Control 293 Requirements", draft-ietf-dime-overload-reqs-07 (work in 294 progress), June 2013. 296 [I-D.tschofenig-dime-overload-arch] 297 Tschofenig, Hannes., "Diameter Overload Architecture and 298 Information Model", July 2013. 300 Author's Address 302 Hannes Tschofenig 303 Nokia Siemens Networks 304 Linnoitustie 6 305 Espoo 02600 306 Finland 308 Phone: +358 (50) 4871445 309 Email: Hannes.Tschofenig@gmx.net 310 URI: http://www.tschofenig.priv.at