--- 1/draft-ietf-dime-load-01.txt 2016-03-18 08:20:32.480266851 -0700 +++ 2/draft-ietf-dime-load-02.txt 2016-03-18 08:20:33.052281021 -0700 @@ -1,51 +1,51 @@ Internet Engineering Task Force B. Campbell Internet-Draft S. Donovan, Ed. -Intended status: Informational Oracle -Expires: April 14, 2016 JJ. Trottin - Alcatel-Lucent - October 12, 2015 +Intended status: Standards Track Oracle +Expires: September 19, 2016 JJ. Trottin + Nokia + March 18, 2016 Diameter Load Information Conveyance - draft-ietf-dime-load-01 + draft-ietf-dime-load-02 Abstract This document defines a mechanism for sharing of Diameter load - information. RFC 7068 describes requirements for Overload Control in - Diameter. This includes a requirement to allow Diameter nodes to + information. [RFC7068] describes requirements for Overload Control + in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The - Diameter Overload Information Conveyance (DOIC) solution describes a - mechanism meeting most of the requirements, but does not currently - include the ability to send load information. + Diameter Overload Information Conveyance (DOIC) [RFC7683] solution + describes a mechanism meeting most of the requirements, but does not + currently include the ability to send load information. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 14, 2016. + This Internet-Draft will expire on September 19, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -54,131 +54,142 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Differences between Load and Overload information . . . . 4 4.2. How is Load Information Used? . . . . . . . . . . . . . . 5 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 7 - 6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 9 - 6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 9 - 6.1.1. End-point Reporting Node Behavior . . . . . . . . . . 10 - 6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 10 + 6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10 + 6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10 + 6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10 + 6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11 6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11 6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 - 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12 - 7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13 - 7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 13 - 7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 13 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . 14 - Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 15 - A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 15 - A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 15 - A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 16 - A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 17 - A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 18 - A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 18 - A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 19 - A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 19 - A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 19 - A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14 + 7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . 15 + Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 16 + A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 16 + A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 16 + A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 17 + A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 18 + A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 19 + A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 19 + A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 20 + A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 20 + A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 20 + A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction [RFC7068] describes requirements for Overload Control in Diameter - [RFC6733]. At the time of this writing, the DIME working group is - working on the Diameter Overload Information Conveyance (DOIC) - mechanism [I-D.ietf-dime-ovli] . As currently specified, DOIC - fulfills some, but not all, of the requirements. + [RFC6733]. The DIME working group has finished the Diameter Overload + Information Conveyance (DOIC) mechanism [RFC7683]. As currently + specified, DOIC fulfills some, but not all, of the requirements. In particular, DOIC does not fulfill Req 24, which requires a mechanism where Diameter nodes can indicate their current load, even if they are not currently overloaded. DOIC also does not fulfill Req 23, which requires that nodes that divert traffic away from overloaded nodes be provided with sufficient information to select targets that are most likely to have sufficient capacity. - There are several other requirements in RFC 7068 that mention both + There are several other requirements in [RFC7068] that mention both overload and load information that are only partially fulfilled by DOIC. The DIME working group explicitly chose not to fulfill these requirements in DOIC due to several reasons. A principal reason was that the working group did not agree on a general approach for conveying load information. It chose to progress the rest of DOIC, - and defer load information conveyance to a DOIC extension or a + and deferred load information conveyance to a DOIC extension or a separate mechanism. This document defines a mechanism that addresses the load-related requirements from RFC 7068. 2. Terminology and Abbreviations DOIC - Diameter Overload Information Conveyance + Diameter Overload Information Conveyance ([RFC7683]) Load - The relative capacity of a Diameter node. A low value indicates - that the Diameter node is under utilized. A high value indicated - that the node is closer to being fully utilized. + The relative capacity of a Diameter node. A low load level + indicates that the Diameter node is under utilized. A high load + level indicates that the node is closer to being fully utilized. Offered Load The actual traffic sent to the reporting node after overload abatement and routing decisions are made. + Reporting, Reacting Node + Reporting node and reacting node terminology is defined in + [RFC7683]. + + Routing Information + + Routing Information - Routing information referred to in this + document can include the Routing and Peer tables defined in RFC + 6733. It can also include other implementation specific tables + used to store load information. This document does not define the + structure of such tables. + 3. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. RFC 2119 [RFC2119] interpretation does not apply for the above listed words when they are not used in all-caps format. 4. Background 4.1. Differences between Load and Overload information Previous discussions of how to solve the load-related requirements in - [RFC7068] have shown that people have not had an agreed-upon concept + [RFC7068] have shown that people did not had an agreed-upon concept of how "load" information differs from "overload" information. While the two concepts are highly interrelated, in the opinion of the authors, there are two primary differences. First, a Diameter node always has a load. At any given time that load maybe effectively zero, effectively fully loaded, or somewhere in between. In contrast, overload is an exceptional condition. A node only has overload information when it is in an overloaded state. Furthermore, the relationship between a node's load level and overload state at any given time may be vague. For example, a node may normally operate at a "fully loaded" level, but still not be considered overloaded. Another node may declare itself to be "overloaded" even though it might not be fully "loaded". Second, Overload information, in the form of a DOIC Overload Report - (OLR) [I-D.ietf-dime-ovli] indicates an explicit request for action - on the part of the reacting node. That is, the OLR requests that the - reacting node reduce the offered load -- the actual traffic sent to - the reporting node after overload abatement and routing decisions are + (OLR) [RFC7683] indicates an explicit request for action on the part + of the reacting node. That is, the OLR requests that the reacting + node reduce the offered load -- the actual traffic sent to the + reporting node after overload abatement and routing decisions are made -- by an indicated amount or to an indicated level. Effectively, DOIC provides a contract between the reporting node and the reacting node. In contrast, load is informational. That is, load information can be considered a hint to the recipient node. That node may use the load information for load balancing purposes, as an input to certain overload abatement techniques, to make inferences about the likelihood that the sending node becomes overloaded in the immediate future, or for other purposes. @@ -187,25 +198,25 @@ offered load based on load information. The fundamental difference is that an overload report requires that reduction. It is also reasonable for a Diameter node to decide to increase the offered load based on load information. 4.2. How is Load Information Used? [RFC7068] contemplates two primary uses for load information. Req 23 discusses how load information might be used when performing diversion as an overload abatement technique, as described in - [I-D.ietf-dime-ovli]. When a reacting node diverts traffic away from - an overloaded node, it needs load information for the other - candidates for that traffic in order to effectively load balance the - diverted load between potential candidates. Otherwise, diversion has - a greater potential to drive other nodes into overload. + [RFC7683]. When a reacting node diverts traffic away from an + overloaded node, it needs load information for the other candidates + for that traffic in order to effectively load balance the diverted + load between potential candidates. Otherwise, diversion has a + greater potential to drive other nodes into overload. Req 24 discusses how Diameter load information might be used when no overload condition currently exists. Diameter nodes can use the load information to make decisions to try to avoid overload conditions in the first place. Normal load-balancing falls into this category. A node might also take other proactive steps to reduce offered load based on load information, so that the loaded node never goes into overload in the first place. If the loaded nodes are Diameter servers (or clients in the case of @@ -221,322 +232,343 @@ For example, a Diameter node (e.g. client) can use a redirect agent to get candidate destination host addresses. The redirect agent might return several destination host addresses, from which the Diameter node selects one. The Diameter node can use load information received from these hosts to make the selection. Just as load information can be used as part of server selection, it can also be used as input to the selection of the next-hop peer to which a request is to be routed. - Editor's Note: One area that requires thought is how load - information is used, if at all, in the presence of an overload - report from the same Diameter node. It might be that the load - information from that Diameter node is ignored for the duration of - the time that the overload report is in effect. It might also be - possible that the load information can aid in the diverting of - non-abated requests targeted for the overloaded Diameter node. + It should be noted that a Diameter node will need to process both + Load reports and Overload reports from the same Diameter node. The + reacting node for the Overload report always has the responsibility + to reduce the amount of Diameter traffic sent to the overloaded node. + If, or how, the reacting node uses Load information to achieve this + is left as an implementation decision. 5. Solution Overview The mechanism defined here for the conveyance of load information is - similar in some says to the mechanism defined for DOIC and is + similar in some ways to the mechanism defined for DOIC and is different in other ways. As with DOIC, load information is conveyed by piggy-backing the load AVPs on existing Diameter applications. There are two primary differences. First, there is no capability negotiation process for load. The sender of the load information is sending it with the expectation that any supporting nodes will use it when making routing decisions. If there are no nodes that support - the load extension then the load information is ignored. + the Load mechanism then the load information is ignored. The second big difference between DOIC and Load is visibility of the DOIC or Load information within a Diameter network. DOIC information is sent end-to-end resulting in the ability of all nodes in the path of the answer message that carries the OC-OLR AVP to act on the information. The DOIC overload reports much remain in the message all the way from the reporting node to the node that is the target for the answer message. For the Load mechanism there are two types of load reports. - The first is the load of the end-point sending the answering the - message. This load report is carried end-to-end to enable any nodes - that make server selection decisions to use the load status of the - sending end-point as part of the server selection decision. + The first is the load of the endpoint sending the answer message. + This load report is carried end-to-end to enable any nodes that make + server selection decisions to use the load status of the sending + endpoint as part of the server selection decision. The second type of load report is a peer report. This report is used by Diameter nodes as part of the logic to select the next hop Diameter node and, as such, do not have significance beyond the peer node. These load reports are removed by the first supporting - Diameter node. + Diameter node to receive the report. Because load reports can traverse Diameter nodes that do not support - the load mechanism, it is necessary to include the identity of the + the Load mechanism, it is necessary to include the identity of the node to which the load report applies as part of the load report. - This allows for a Diameter node to verify that the load report - applies to its peer or if it should be ignored. + This allows for a Diameter node to verify that a load report applies + to its peer or if it should be ignored. The load report includes the relative load of the sending node. This relative load is specified in a manner consistent with that defined for DNS SRV [RFC2782]. + The goal is make it possible to use both the load values received as + a part of the Diameter Load mechanism and weight values received as a + result of a DNS SRV query. As a result, the Diameter load value has + a range of 0-65535. This value and DNS SRV weight values are then + used in a distribution algorithm similar to that specified in + [RFC2782]. + + The DNS SRV distribution algorithm results in more messages being + sent to a node with a higher weight value. As a result, a higher + Diameter load value indicates a LOWER load on the sending node. A + node that is heavily loaded sends a lower Diameter load value. + Stated another way, a node that has zero load would have a load value + of 65535. A node that is 100% loaded would have a load value of 0. + + The distribution algorithm used by Diameter nodes supporting the + Diameter Load mechanism is an implementation decision but it needs to + result in similar behavior as the algorithm specified in [RFC2782]. + The method for calculating the load value included in the load report - is left as an implementation decision. + is also left as an implementation decision. The frequency for sending of load reports is also left as an implementation decision. The sending node might choose to send load reports in all messages or it might choose to only send load reports when the load value has changed by some implementation specific - value. The important consideration is that all nodes needing the + amount. The important consideration is that all nodes needing the load information have a sufficiently accurate view of the nodes load. 5.1. Theory of Operation - This section outlines how the Diameter load mechanism is expected to + This section outlines how the Diameter Load mechanism is expected to work. For this discussion, assume the following Diameter network configuration: ---A1---A3----S[1], S[2]...S[p] / | \ / C | x \ | / \ ---A2---A4----S[p+1], S[p+2] ...S[n] Figure 1: Example Diameter Network + Note that in this diagram, S[1], S[2] through S[p] are peers to A3. + S[p+1], S[p+2] through S[n] are peers to A4. + Also assume that the request for a Diameter transaction takes the following path: C A1 A4 S[n] | | | | |----->|----->|----->| xxR xxR xxR Figure 2: Request Message Path - When sending the answer message, an end-point node that supports the + When sending the answer message, an endpoint node that supports the Diameter Load mechanism includes it's own load information in the - answer message. Because it is a Diameter end-point it includes an - end-point load report. + answer message. Because it is a Diameter endpoint it includes a HOST + load report. C A1 A4 S[n] | | | | | | |<-----| - | | xxA(Load type:host, source:S[n]) + | | xxA(Load type:HOST, source:S[n]) | | | | Figure 3: Answer Message from S[n] If Agent A4 supports the Load mechanism then it will verify that the - load information received is valid. For a host load report this is + load information received is valid. For a HOST load report this is achieved by matching the identity included in the load information with the identity of the host node from which the answer message was received. - Note: If A4 does not support the load mechanism then it will relay + Note: If A4 does not support the Load mechanism then it will relay the answer message without doing any processing on the load - information. In this case the load AVPs will be relayed without - change. + information. In this case the load information AVPs will be + relayed without change. If the identity included in the load information AVPs matches the identity of the host from which the load information is received then - Agent A4 stores the load information for S[n] in its routing tables. + Agent A4 stores the load information for S[n] in its routing + information. - Because the load report is an host load report, A4 leaves the load + Because the load report is an HOST load report, A4 leaves the load report in the message it relays. A4 then calculates its own load information and inserts load - information AVPs in the message before sending the message to A1: + information AVPs of type PEER in the message before sending the + message to A1: C A1 A4 S[n] | | | | | |<-----| | - | xxA(Load type:peer, source:A4) - | xxA(Load type:host, source:S[n]) + | xxA(Load type:PEER, source:A4) + | xxA(Load type:HOST, source:S[n]) | | | | Figure 4: Answer Message from A4 If A1 supports the Load mechanism then it processes each of the Load reports it receives separately. - For the peer load report, A1 first determines if the source of the - report indicated in the load report matches the DiameterID of the - Diameter node from which the request was received. If the identities - do not match then the peer load report is discarded. If the - identities match then A1 saves the load information in its routing - tables for routing of subsequent request messages. In both cases A1 - strips the peer load report from the message. + For the PEER load report, A1 first determines if the source of the + report indicated in the load report matches the DiameterIdentity of + the Diameter node from which the request was received. If the + identities do not match then the PEER load report is discarded. If + the identities match then A1 saves the load information in its + routing information for routing of subsequent request messages. In + both cases A1 strips the PEER load report from the message. - For the host load report, A1's actions depend on whether A1 is + For the HOST load report, A1's actions depend on whether A1 is responsible for doing server selection. If A1 is not doing server - selection then A1 ignores the host load report. If A1 is responsible + selection then A1 ignores the HOST load report. If A1 is responsible for doing server selection then it stores the load information for - S[n] in its routing tables for the handling of subsequent request - messages. In both cases A1 leaves the host report in the message. + S[n] in its routing information for the handling of subsequent + request messages. In both cases A1 leaves the HOST report in the + message. A1 then calculates its own load information and inserts load - information AVPs in the message before sending the message to A1: + information AVPs of type PEER in the message before sending the + message to A1: C A1 A4 S[n] | | | | |<-----| | | - xxA(Load type:peer, source:A1) - xxA(Load type:host, source:S[n]) + xxA(Load type:PEER, source:A1) + xxA(Load type:HOST, source:S[n]) Figure 5: Answer Message from A1 As with A1, C processes each load report separately. - For the peer load report, C follows the same procedure for + For the PEER load report, C follows the same procedure as A1 for determining if the Load report was received from the peer from which the report was sent and, when finding it does, stores the load information for use when making future routing decisions. - For the host load report, C saves the load information only if it is + For the HOST load report, C saves the load information only if it is responsible for doing server selection. The Load information received by all nodes is then used for routing of subsequent request messages. 6. Load Mechanism Procedures This section defines the normative behaviors for the Load mechanism. 6.1. Reporting Node Behavior - This section defines the procedures of Diameter nodes that generate - load reports. + This section defines the procedures of Diameter reporting nodes that + generate load reports. -6.1.1. End-point Reporting Node Behavior +6.1.1. Endpoint Reporting Node Behavior - A Diameter end-point that supports the Diameter Load mechanism MUST + A Diameter endpoint that supports the Diameter Load mechanism MUST include a load report of type HOST in sufficient answer messages to ensure that all consumers of the load information receive timely updates. - The Diameter end-point MUST include it's own DiameterID in the + The Diameter endpoint MUST include it's own DiameterIdentity in the Source-ID AVP included in the Load AVP. - The Diameter end-point MUST include a Load-Type AVP of type HOST in + The Diameter endpoint MUST include a Load-Type AVP of type HOST in the Load AVP. - The Diameter end-point MUST include its load value in the Value AVP - in the load AVP. + The Diameter endpoint MUST include its load value in the Value AVP in + the load AVP. The method for determining the load value included in the load report is an implementation decision. - The value included MUST be consistant with DNS SRV.... - - Editor's note: We need to elaborate on this. - The frequency of sending load reports is an implementation decision. - For instance, if the only consumer of the load reports is the end- - points peer then the end-point can choose to only include a load - report when the load of the end-point has changed by a significant - percentage. If there are consumers of the end-point load report - other then the end-points peer (this will be the case if other - nodes are responsible for server selection) then the end-point + For instance, if the only consumer of the load reports is the + endpoints peer then the endpoint can choose to only include a load + report when the load of the endpoint has changed by a meaningful + percentage. If there are consumers of the endpoint load report + other then the endpoints peer (this will be the case if other + nodes are responsible for server selection) then the endpoint might choose to include load reports in all answer messages as a way of ensuring that all nodes doing server selection get accurate load information. 6.1.2. Agent Reporting Node Behavior A Diameter agent that supports the Diameter Load mechanism MUST include a PEER load report in sufficient answer messages to ensure that all users of the load information receive timely updates. - The Diameter agent MUST include it's own DiameterID in the Source-ID - AVP included in the Load AVP. + The Diameter agent MUST include it's own DiameterIdentity in the + Source-ID AVP included in the Load AVP. The Diameter agent MUST include a Load-Type AVP of type PEER in the Load AVP. The Diameter agent MUST include its load value in the Value AVP in the load AVP. The method for determining the load value included in the load report is an implementation decision. - The value included MUST be consistant with DNS SRV.... - - Editor's note: We need to elaborate on this. - The frequency of sending load reports is an implementation decision. Note: In the case of peer load reports it is only necessary to include load reports when the load value has changed by some - significant value. It is also acceptable to include the load + meaningful value, as long as the agent insures that all peers + receive the report. It is also acceptable to include the load report in every answer message handled by the Diameter agent. 6.2. Receiving Node Behavior This section defines the behavior of Diameter nodes processing load reports. - A Diameter node MUST be prepared to process both load reports of type - HOST and of type PEER, as indicated in the Load-Type AVP included in - the Load AVP. + A Diameter node MUST be prepared to process load reports of type HOST + and of type PEER, as indicated in the Load-Type AVP included in the + Load AVP received in the same answer message or from multiple answer + messages. Note that the node needs to be able to handle messages with no load reports, messages with just a PEER load report, messages with just an HOST load report and messages with both types of load reports. If the Diameter node is not responsible for doing server selection then it SHOULD ignore load reports of type HOST. If the Diameter node is responsible for doing server selection then it SHOULD save the load value included in the Value AVP included in - the Load AVP of type HOST in its routing tables. + the Load AVP of type HOST in its routing information. If the Diameter node receives a Load report of type PEER then the Diameter node MUST determine if the Load report was inserted into the answer message by the peer from which the message was received. This - is achieved by comparing the DiameterID associated with the - connection from which the message was received with the DiameterID - included in the Source-ID AVP in the Load report. + is achieved by comparing the DiameterIdentity associated with the + connection from which the message was received with the + DiameterIdentity included in the Source-ID AVP in the Load report. If the Diameter node determines that the Load report of type PEER was not received from the peer that sent or relayed the answer message then the node MUST ignore the Load report. If the Diameter node determines that the Load report of type PEER was received from the peer that sent or relayed the answer message then - the node SHOULD save the load information in its routing table. + the node SHOULD save the load information in its routing information. How a Diameter node uses load information for making routing - decisions is an implememtation decision. + decisions is an implementation decision. However, the distribution + algorithm MUST result in similar behavior as the algorithm described + for the use of weigth values in [RFC2782]. 6.3. Extensibility The Load mechanism can be extended to include additional information in the load reports. Any extension may define new AVPs for use in Load reports. These new AVPs SHOULD be defined to be extensions to the Load AVPs defined in this document. [RFC6733] defined Grouped AVP extension mechanisms apply. This allows, for example, defining a new feature that is mandatory to be understood even when piggybacked on an existing application. - As with any Diameter specification, RFC6733 requires all new AVPs to - be registered with IANA. See Section 9 for the required procedures. + As with any Diameter specification, [RFC6733] requires all new AVPs + to be registered with IANA. See Section 9 for the required + procedures. 7. Attribute Value Pairs The section defines the AVPs required for the Load mechanism. 7.1. Load AVP The Load AVP (AVP code TBD1) is of type Grouped and is used to convey load information between Diameter nodes. @@ -555,42 +587,54 @@ HOST 0 The load report is for a host. PEER 1 The load report is for a peer. 7.3. Load-Value AVP The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used to convey relative load information about the sender of the load report. + The Load-Value AVP is specified in a manner similar to the weight + value in DNS SRV ([RFC2782]). + + The Load-Value has a range of 0-65535. + + A higher value indicates a lower load on the sending node. A lower + value indicates that the sending node is heavily loaded. + + Stated another way, a node that has zero load would have a load + value of 65535. A node that is 100% loaded would have a load + value of 0. + 7.4. SourceID AVP The SourceID AVP is defined in [I-D.ietf-dime-agent-overload]. It is used to identify the Diameter node that sent the Load report. 7.5. Attribute Value Pair flag rules +---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| - +--------------------------------------------------+----+----+ + +--------------------------------------------------------+----+----+ |Load TBD1 x.1 Grouped | | V | - +--------------------------------------------------+----+----+ + +--------------------------------------------------------+----+----+ |Load-Type TBD2 x.2 Enumerated | | V | - +--------------------------------------------------+----+----+ + +--------------------------------------------------------+----+----+ |Load-Value TBD3 x.3 Unsigned64 | | V | - +--------------------------------------------------+----+----+ - |SourceID TBD4 x.4 DiameterID | | V | - +--------------------------------------------------+----+----+ + +------------------------------------------------------ -+----+----+ + |SourceID TBD4 x.4 DiameterIdentity | | V | + +--------------------------------------------------------+----+----+ As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application. 8. Security Considerations Load information may be sensitive information in some cases. Depending on the mechanism, an unauthorized recipient might be able to infer the topology of a Diameter network from load information. Load information might be useful in identifying targets for Denial of @@ -619,39 +663,39 @@ This document makes no new registry requests of IANA. 10. References 10.1. Normative References [I-D.ietf-dime-agent-overload] Donovan, S., "Diameter Agent Overload", draft-ietf-dime- agent-overload-02 (work in progress), August 2015. - [I-D.ietf-dime-ovli] - Korhonen, J., Donovan, S., Campbell, B., and L. Morand, - "Diameter Overload Indication Conveyance", draft-ietf- - dime-ovli-03 (work in progress), July 2014. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, DOI 10.17487/RFC7068, November 2013, . + [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. + Morand, "Diameter Overload Indication Conveyance", + RFC 7683, DOI 10.17487/RFC7683, October 2015, + . + 10.2. Informative References [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . Appendix A. Topology Scenarios This section presents a number of Diameter topology scenarios, and @@ -669,24 +713,25 @@ using the load information received from each server. ------S1 / C \ ------S2 Figure 6: Basic Client Server Scenario - Open Issue: Will a Diameter node include potential peers that it - is not currently connected to as part of the candidate set? It is - unlikely the client would have load information from peers that it - is not currently connected to. + If a node supports dynamic discovery, it will not obtain load + information from the nodes with which it has no Diameter + connection established. Nevertheless it might take into account + the load information from the other nodes to decide to add + connections to new nodes with the dynamic discovery mechanism. Note: The use of dynamic connections needs to be considered. A.2. Single Agent Figure 7 shows a client that sends requests to an agent. The agent selects the request destination from a set of candidate servers, using load information received from each server. The client does not need to receive load information, since it does not select between multiple agents. @@ -708,27 +753,27 @@ servers. This scenario adds a complication that one set of servers may be more loaded than the other set. If, for example, S4 was the least loaded server, C would need to know to select agent A2 to reach S4. This might require C to receive load information from the servers as well as the agents. Alternatively, each agent might use the load of its servers as an input into calculating its own load, in effect aggregating upstream load. - Similarly, if C sends a host-routed request [I-D.ietf-dime-ovli], it - needs to know which agent can deliver requests to the selected - server. Without some special, potentially proprietary, knowledge of - the topology upstream of A1 and A2, C would select the agent based on - the normal peer selection procedures for the realm and application, - and perhaps consider the load information from A1 and A2. If C sends - a request to A1 that contains a Destination-Host AVP with a value of + Similarly, if C sends a host-routed request [RFC7683], it needs to + know which agent can deliver requests to the selected server. + Without some special, potentially proprietary, knowledge of the + topology upstream of A1 and A2, C would select the agent based on the + normal peer selection procedures for the realm and application, and + perhaps consider the load information from A1 and A2. If C sends a + request to A1 that contains a Destination-Host AVP with a value of S4, A1 will not be able to deliver the request. -----S3 / ---A1------S1 / C \ ---A2------S2 \ @@ -840,22 +885,22 @@ ---A1---A3---S[1], S[2]...S[p] / | \ / |\ / C | x | x \ | / \ |/ \ ---A2---A4---S[p+1], S[p+2] ...S[n] Figure 13: Full Mesh A.8. Partitions - A Diameter network with multiple is said to be "partitioned" when - only a subset of available servers can server a particular realm- + A Diameter network with multiple servers is said to be "partitioned" + when only a subset of available servers can serve a particular realm- routed request. For example, one group of servers may handle users whose names start with "A" through "M", and another group may handle "N" through "Z". In such a partitioned network, nodes cannot load-balance requests across partitions, since not all servers can handle the request. A client, or an intermediate agent, may still be able to load-balance between servers inside a partition. A.9. Active-Standby Nodes @@ -868,46 +913,48 @@ active peers became unavailable. For example, requests might be diverted to a stand-by peer if one or more active peers becomes overloaded. A.10. Addition and removal of Nodes When a Diameter node is added, the new node will start by advertising its load. Downstream nodes will need to factor the new load information into load balancing decisions. The downstream nodes should attempt to ensure a smooth increase of the traffic to the new - node, avoiding an immediate spike of traffic to the new node. It - should be determined if this use case is in the scope of the load - control mechanism. + node, avoiding an immediate spike of traffic to the new node. The + handling of such a smooth increase is implementation specific but it + can rely on the evolution of load information received from the new + node and from the other nodes. When removing a node in a controlled way (e.g. for maintenance purpose, so outside a failure case), it might be appropriate to progressively reduce the traffic to this node by routing traffic to other nodes. Simple load information (load percentage) would be not - sufficient. It should be determined if this use case is in the scope - of the load control mechanism. + sufficient. The handling of the node removal is implementation + specific but it can rely on the evolution of the load information + received from the node to be removed Authors' Addresses Ben Campbell Oracle 7460 Warren Parkway # 300 Frisco, Texas 75034 USA Email: ben@nostrum.com Steve Donovan (editor) Oracle 7460 Warren Parkway # 300 Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Jean-Jacques Trottin - Alcatel-Lucent + Nokia Route de Villejust 91620 Nozay France - Email: jean-jacques.trottin@alcatel-lucent.com + Email: jean-jacques.trottin@nokia.com