draft-ietf-dime-load-08.txt   draft-ietf-dime-load-09.txt 
Internet Engineering Task Force B. Campbell Internet Engineering Task Force B. Campbell
Internet-Draft S. Donovan, Ed. Internet-Draft S. Donovan, Ed.
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: September 8, 2017 JJ. Trottin Expires: September 23, 2017 JJ. Trottin
Nokia Nokia
March 7, 2017 March 22, 2017
Diameter Load Information Conveyance Diameter Load Information Conveyance
draft-ietf-dime-load-08 draft-ietf-dime-load-09
Abstract Abstract
RFC7068 describes requirements for Overload Control in Diameter. RFC7068 describes requirements for Overload Control in Diameter.
This includes a requirement to allow Diameter nodes to send "load" This includes a requirement to allow Diameter nodes to send "load"
information, even when the node is not overloaded. RFC7683 (Diameter information, even when the node is not overloaded. RFC7683 (Diameter
Overload Information Conveyance (DOIC)) solution describes a Overload Information Conveyance (DOIC)) solution describes a
mechanism meeting most of the requirements, but does not currently mechanism meeting most of the requirements, but does not currently
include the ability to send load information. This document defines include the ability to send load information. This document defines
a mechanism for conveying of Diameter load information. a mechanism for conveying of Diameter load information.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2017. This Internet-Draft will expire on September 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
REQ 24: The solution MUST provide a mechanism for indicating load REQ 24: The solution MUST provide a mechanism for indicating load
levels, even when not in an overload condition, to assist nodes in levels, even when not in an overload condition, to assist nodes in
making decisions to prevent overload conditions from occurring. making decisions to prevent overload conditions from occurring.
There are several other requirements in [RFC7068] that mention both There are several other requirements in [RFC7068] that mention both
overload and load information that are only partially fulfilled by overload and load information that are only partially fulfilled by
DOIC. DOIC.
The DIME working group explicitly chose not to fulfill these The DIME working group explicitly chose not to fulfill these
requirements in DOIC due to several reasons. A principal reason was requirements when publishing DOIC [RFC7683] due to several reasons.
that the working group did not agree on a general approach for A principal reason was that the working group did not agree on a
conveying load information. It chose to progress the rest of DOIC, general approach for conveying load information. It chose to
and deferred load information conveyance to a DOIC extension or a progress the rest of DOIC, and deferred load information conveyance
separate mechanism. to a DOIC extension or a separate mechanism.
This document defines a mechanism that addresses the load-related This document defines a mechanism that addresses the load-related
requirements from RFC 7068. requirements from RFC 7068.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
AVP AVP
Attribute Value Pair Attribute Value Pair
skipping to change at page 6, line 24 skipping to change at page 6, line 24
information received from these hosts to make the selection. information received from these hosts to make the selection.
Just as load information can be used as part of server selection, it 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 can also be used as input to the selection of the next-hop peer to
which a request is to be routed. which a request is to be routed.
It should be noted that a Diameter node will need to process both It should be noted that a Diameter node will need to process both
Load reports and Overload reports from the same Diameter node. The Load reports and Overload reports from the same Diameter node. The
reacting node for the Overload report always has the responsibility reacting node for the Overload report always has the responsibility
to reduce the amount of Diameter traffic sent to the overloaded node. to reduce the amount of Diameter traffic sent to the overloaded node.
If, or how, the reacting node uses Load information to achieve this If, or how, the reacting node uses load information to achieve this
is left as an implementation decision. is left as an implementation decision.
5. Solution Overview 5. Solution Overview
The mechanism defined here for the conveyance of load information is The mechanism defined here for the conveyance of load information is
similar in some ways to the mechanism defined for DOIC and is similar in some ways to the mechanism defined for DOIC and is
different in other ways. different in other ways.
As with DOIC, load information is conveyed by piggy-backing the load As with DOIC, load information is conveyed by piggy-backing the Load
AVPs on existing Diameter applications. AVPs on existing Diameter applications.
There are two primary differences. First, there is no capability There are two primary differences. First, there is no capability
negotiation process for load. The sender of the load information is negotiation process for load. The sender of the load information is
sending it with the expectation that any supporting nodes will use it sending it with the expectation that any supporting nodes will use it
when making routing decisions. If there are no nodes that support when making routing decisions. If there are no nodes that support
the Load mechanism 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 The second big difference between DOIC and Load is visibility of the
DOIC or Load information within a Diameter network. DOIC information 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 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 of the answer message that carries the OC-OLR AVP to act on the
information, although only one node actually comsumes and reacts to information, although only one node actually comsumes and reacts to
the report. The DOIC overload reports remain in the message all the the report. The DOIC overload reports remain in the message all the
way from the reporting node to the node that is the target for the way from the reporting node to the node that is the target for the
answer message. answer message.
For the Load mechanism there are two types of Load reports and only For the Load mechanism there are two types of Load reports and only
the first one is transmitted end-to-end. the first one is transmitted end-to-end.
The first type of load report is a HOST report which contains the The first type of Load report is a HOST report which contains the
load of the endpoint sending the answer message. This Load report is load of the endpoint sending the answer message. This Load report is
carried end-to-end to enable any nodes that make server selection 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 decisions to use the load status of the sending endpoint as part of
the server selection decision. Unlike with DOIC, more than one node the server selection decision. Unlike with DOIC, more than one node
may make use of the load information received. may make use of the load information received.
The second type of Load report is a PEER report. This report is used 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 by Diameter nodes as part of the logic to select the next-hop
Diameter node and, as such, does not have significance beyond the Diameter node and, as such, does not have significance beyond the
peer node. Load reports of type PEER are removed by the first peer node. Load reports of type PEER are removed by the first
skipping to change at page 9, line 45 skipping to change at page 9, line 45
| | | | | | | |
Figure 4: Answer Message from A4 Figure 4: Answer Message from A4
If A1 supports the Load mechanism then it processes each of the Load If A1 supports the Load mechanism then it processes each of the Load
reports it receives separately. reports it receives separately.
For the PEER Load report, A1 first determines if the source of the For the PEER Load report, A1 first determines if the source of the
report indicated in the Load report matches the DiameterIdentity of report indicated in the Load report matches the DiameterIdentity of
the Diameter node from which the request was received. If the the Diameter node from which the request was received. If the
identities do not match then the PEER load report is discarded. If identities do not match then the PEER Load report is discarded. If
the identities match then A1 saves the load information in its the identities match then A1 saves the load information in its
routing information for routing of subsequent request messages. In routing information for routing of subsequent request messages. In
both cases A1 strips the PEER Load report from the message. 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 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 for doing server selection then it stores the load information for
S[n] in its routing information for the handling of subsequent S[n] in its routing information for the handling of subsequent
request messages. In both cases A1 leaves the HOST report in the request messages. In both cases A1 leaves the HOST report in the
skipping to change at page 10, line 35 skipping to change at page 10, line 35
As with A1, C processes each Load report separately. As with A1, C processes each Load report separately.
For the PEER Load report, C follows the same procedure as A1 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 determining if the Load report was received from the peer from which
the report was sent. When finding it does, C stores the load the report was sent. When finding it does, C stores the load
information for use when making future routing decisions. 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. responsible for doing server selection.
The Load information received by all nodes is then used for routing The load information received by all nodes is then used for routing
of subsequent request messages. of subsequent request messages.
6. Load Mechanism Procedures 6. Load Mechanism Procedures
This section defines the normative behaviors for the Load mechanism. This section defines the normative behaviors for the Load mechanism.
6.1. Reporting Node Behavior 6.1. Reporting Node Behavior
This section defines the procedures of Diameter reporting nodes that This section defines the procedures of Diameter reporting nodes that
generate Load reports. generate Load reports.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
include Load reports when the load value has changed by some include Load reports when the load value has changed by some
meaningful value, as long as the agent ensures that all peers meaningful value, as long as the agent ensures that all peers
receive the report. It is also acceptable to include the Load receive the report. It is also acceptable to include the Load
report in every answer message handled by the Diameter Agent. report in every answer message handled by the Diameter Agent.
6.2. Reacting Node Behavior 6.2. Reacting Node Behavior
This section defines the behavior of Diameter nodes processing Load This section defines the behavior of Diameter nodes processing Load
reports. reports.
A Diameter node MUST be prepared to process Load reports of type HOST A Diameter node that supports the Diameter Load mechanism MUST be
and of type PEER, as indicated in the Load-Type AVP included in the prepared to process Load reports of type HOST and of type PEER, as
Load AVP received in the same answer message or from multiple answer indicated in the Load-Type AVP included in the Load AVP received in
messages. the same answer message or from multiple answer messages.
Note that the node needs to be able to handle messages with no Note that the node needs to be able to handle messages with no
load reports, messages with just a PEER Load report, messages with load reports, messages with just a PEER Load report, messages with
just an HOST Load report and messages with both types of Load just an HOST Load report and messages with both types of Load
reports. reports.
If the Diameter node is not responsible for doing server selection If the Diameter node is not responsible for doing server selection
then it SHOULD ignore Load reports of type HOST. then it SHOULD ignore Load reports of type HOST.
If the Diameter node is responsible for doing server selection then If the Diameter node is responsible for doing server selection then
skipping to change at page 15, line 47 skipping to change at page 15, line 47
Load information may be sensitive information in some cases. Load information may be sensitive information in some cases.
Depending on the mechanism, an unauthorized recipient might be able Depending on the mechanism, an unauthorized recipient might be able
to infer the topology of a Diameter network from load information. to infer the topology of a Diameter network from load information.
Load information might be useful in identifying targets for Denial of Load information might be useful in identifying targets for Denial of
Service (DoS) attacks, where a node known to be already heavily Service (DoS) attacks, where a node known to be already heavily
loaded might be a tempting target. Load information might also be loaded might be a tempting target. Load information might also be
useful as feedback about the success of an ongoing DoS attack. useful as feedback about the success of an ongoing DoS attack.
Given that routing decisions are impacted by load information, there Given that routing decisions are impacted by load information, there
is potential for negative impacts on a Diameter network caused by is potential for negative impacts on a Diameter network caused by
erroneous or malicious load reports. This includes the malicious erroneous or malicious Load reports. This includes the malicious
changing of load values by Diameter Agents. changing of load values by Diameter Agents.
Any load information conveyance mechanism will need to allow Any load information conveyance mechanism will need to allow
operators to avoid sending load information to nodes that are not operators to avoid sending load information to nodes that are not
authorized to receive it. Since Diameter currently only offers authorized to receive it. Since Diameter currently only offers
authentication of nodes at the transport level, any solution that authentication of nodes at the transport level and does not support
sends load information to non-peer nodes requires a transitive-trust end-to-end security mechanisms, any solution that sends load
model. information to non-peer nodes requires a transitive-trust model.
9. IANA Considerations 9. IANA Considerations
9.1. AVP Codes 9.1. AVP Codes
New AVPs defined by this specification are listed in New AVPs defined by this specification are listed in
Section Section 7. All AVP codes are allocated from the Section Section 7. All AVP codes are allocated from the
'Authentication, Authorization, and Accounting (AAA) Parameters' AVP 'Authentication, Authorization, and Accounting (AAA) Parameters' AVP
Codes registry. Codes registry.
 End of changes. 14 change blocks. 
23 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/