RFC 7683
Diameter Overload Indication Conveyance
6. Loss Algorithm
This section documents the Diameter overload loss abatement algorithm.6.1. Overview
The DOIC specification supports the ability for multiple overload abatement algorithms to be specified. The abatement algorithm used for any instance of overload is determined by the DOIC Capability Announcement process documented in Section 5.1. The loss algorithm described in this section is the default algorithm that must be supported by all Diameter nodes that support DOIC. The loss algorithm is designed to be a straightforward and stateless overload abatement algorithm. It is used by reporting nodes to request a percentage reduction in the amount of traffic sent. The traffic impacted by the requested reduction depends on the type of overload report. Reporting nodes request the stateless reduction of the number of requests by an indicated percentage. This percentage reduction is in comparison to the number of messages the node otherwise would send, regardless of how many requests the node might have sent in the past. From a conceptual level, the logic at the reacting node could be outlined as follows. 1. An overload report is received, and the associated OCS is either saved or updated (if required) by the reacting node. 2. A new Diameter request is generated by the application running on the reacting node. 3. The reacting node determines that an active overload report applies to the request, as indicated by the corresponding OCS entry. 4. The reacting node determines if overload abatement treatment should be applied to the request. One approach that could be taken for each request is to select a uniformly selected random number between 1 and 100. If the random number is less than or
equal to the indicated reduction percentage, then the request is
given abatement treatment; otherwise, the request is given normal
routing treatment.
6.2. Reporting Node Behavior
The method a reporting node uses to determine the amount of traffic
reduction required to address an overload condition is an
implementation decision.
When a reporting node that has selected the loss abatement algorithm
determines the need to request a reduction in traffic, it includes an
OC-OLR AVP in answer messages as described in Section 5.2.3.
When sending the OC-OLR AVP, the reporting node MUST indicate a
percentage reduction in the OC-Reduction-Percentage AVP.
The reporting node MAY change the reduction percentage in subsequent
overload reports. When doing so, the reporting node must conform to
overload report handling specified in Section 5.2.3.
6.3. Reacting Node Behavior
The method a reacting node uses to determine which request messages
are given abatement treatment is an implementation decision.
When receiving an OC-OLR in an answer message where the algorithm
indicated in the OC-Supported-Features AVP is the loss algorithm, the
reacting node MUST apply abatement treatment to the requested
percentage of request messages sent.
Note: The loss algorithm is a stateless algorithm. As a result,
the reacting node does not guarantee that there will be an
absolute reduction in traffic sent. Rather, it guarantees that
the requested percentage of new requests will be given abatement
treatment.
If the reacting node comes out of the 100% traffic reduction
(meaning, it has received an OLR indicating that no traffic should be
sent, as a result of the overload report timing out), the reacting
node sending the traffic SHOULD be conservative and, for example,
first send "probe" messages to learn the overload condition of the
overloaded node before converging to any traffic amount/rate decided
by the sender. Similar concerns apply in all cases when the overload
report times out, unless the previous overload report stated 0%
reduction.
Note: The goal of this behavior is to reduce the probability of
overload condition thrashing where an immediate transition from
100% reduction to 0% reduction results in the reporting node
moving quickly back into an overload condition.
7. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this
document.
Refer to Section 4 of [RFC6733] for more information on AVPs and AVP
data types.
7.1. OC-Supported-Features AVP
The OC-Supported-Features AVP (AVP Code 621) is of type Grouped and
serves two purposes. First, it announces a node's support for the
DOIC solution in general. Second, it contains the description of the
supported DOIC features of the sending node. The OC-Supported-
Features AVP MUST be included in every Diameter request message a
DOIC supporting node sends.
OC-Supported-Features ::= < AVP Header: 621 >
[ OC-Feature-Vector ]
* [ AVP ]
7.2. OC-Feature-Vector AVP
The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
contains a 64-bit flags field of announced capabilities of a DOIC
node. The value of zero (0) is reserved.
The OC-Feature-Vector sub-AVP is used to announce the DOIC features
supported by the DOIC node, in the form of a flag-bits field in which
each bit announces one feature or capability supported by the node.
The absence of the OC-Feature-Vector AVP in request messages
indicates that only the default traffic abatement algorithm described
in this specification is supported. The absence of the OC-Feature-
Vector AVP in answer messages indicates that the default traffic
abatement algorithm described in this specification is selected
(while other traffic abatement algorithms may be supported), and no
features other than abatement algorithms are supported.
The following capability is defined in this document:
OLR_DEFAULT_ALGO (0x0000000000000001)
When this flag is set by the a DOIC reacting node, it means that
the default traffic abatement (loss) algorithm is supported. When
this flag is set by a DOIC reporting node, it means that the loss
algorithm will be used for requested overload abatement.
7.3. OC-OLR AVP
The OC-OLR AVP (AVP Code 623) is of type Grouped and contains the
information necessary to convey an overload report on an overload
condition at the reporting node. The application the OC-OLR AVP
applies to is identified by the Application-ID found in the Diameter
message header. The host or realm the OC-OLR AVP concerns is
determined from the Origin-Host AVP and/or Origin-Realm AVP found in
the encapsulating Diameter command. The OC-OLR AVP is intended to be
sent only by a reporting node.
OC-OLR ::= < AVP Header: 623 >
< OC-Sequence-Number >
< OC-Report-Type >
[ OC-Reduction-Percentage ]
[ OC-Validity-Duration ]
* [ AVP ]
7.4. OC-Sequence-Number AVP
The OC-Sequence-Number AVP (AVP Code 624) is of type Unsigned64. Its
usage in the context of overload control is described in Section 5.2.
From the functionality point of view, the OC-Sequence-Number AVP is
used as a nonvolatile increasing counter for a sequence of overload
reports between two DOIC nodes for the same overload occurrence.
Sequence numbers are treated in a unidirectional manner, i.e., two
sequence numbers in each direction between two DOIC nodes are not
related or correlated.
7.5. OC-Validity-Duration AVP
The OC-Validity-Duration AVP (AVP Code 625) is of type Unsigned32 and
indicates in seconds the validity time of the overload report. The
number of seconds is measured after reception of the first OC-OLR AVP
with a given value of OC-Sequence-Number AVP. The default value for
the OC-Validity-Duration AVP is 30 seconds. When the OC-Validity-
Duration AVP is not present in the OC-OLR AVP, the default value
applies. The maximum value for the OC-Validity-Duration AVP is
86,400 seconds (24 hours). If the value received in the OC-Validity- Duration is greater than the maximum value, then the default value applies.7.6. OC-Report-Type AVP
The OC-Report-Type AVP (AVP Code 626) is of type Enumerated. The value of the AVP describes what the overload report concerns. The following values are initially defined: HOST_REPORT 0 The overload report is for a host. Overload abatement treatment applies to host-routed requests. REALM_REPORT 1 The overload report is for a realm. Overload abatement treatment applies to realm-routed requests. The values 2-4294967295 are unassigned.7.7. OC-Reduction-Percentage AVP
The OC-Reduction-Percentage AVP (AVP Code 627) is of type Unsigned32 and describes the percentage of the traffic that the sender is requested to reduce, compared to what it otherwise would send. The OC-Reduction-Percentage AVP applies to the default (loss) algorithm specified in this specification. However, the AVP can be reused for future abatement algorithms, if its semantics fit into the new algorithm. The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are ignored. The value of 100 means that all traffic is to be throttled, i.e., the reporting node is under a severe load and ceases to process any new messages. The value of 0 means that the reporting node is in a stable state and has no need for the reacting node to apply any traffic abatement.
7.8. AVP Flag Rules
+---------+ |AVP flag | |rules | +----+----+ AVP Section | |MUST| Attribute Name Code Defined Value Type |MUST| NOT| +--------------------------------------------------+----+----+ |OC-Supported-Features 621 7.1 Grouped | | V | +--------------------------------------------------+----+----+ |OC-Feature-Vector 622 7.2 Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-OLR 623 7.3 Grouped | | V | +--------------------------------------------------+----+----+ |OC-Sequence-Number 624 7.4 Unsigned64 | | V | +--------------------------------------------------+----+----+ |OC-Validity-Duration 625 7.5 Unsigned32 | | V | +--------------------------------------------------+----+----+ |OC-Report-Type 626 7.6 Enumerated | | V | +--------------------------------------------------+----+----+ |OC-Reduction | | | | -Percentage 627 7.7 Unsigned32 | | 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. Error Response Codes
When a DOIC node rejects a Diameter request due to overload, the DOIC node MUST select an appropriate error response code. This determination is made based on the probability of the request succeeding if retried on a different path. Note: This only applies for DOIC nodes that are not the originator of the request. A reporting node rejecting a Diameter request due to an overload condition SHOULD send a DIAMETER_TOO_BUSY error response, if it can assume that the same request may succeed on a different path. If a reporting node knows or assumes that the same request will not succeed on a different path, the DIAMETER_UNABLE_TO_COMPLY error response SHOULD be used. Retrying would consume valuable resources during an occurrence of overload.
For instance, if the request arrived at the reporting node without
a Destination-Host AVP, then the reporting node might determine
that there is an alternative Diameter node that could successfully
process the request and that retrying the transaction would not
negatively impact the reporting node. DIAMETER_TOO_BUSY would be
sent in this case.
If the request arrived at the reporting node with a Destination-
Host AVP populated with its own Diameter identity, then the
reporting node can assume that retrying the request would result
in it coming to the same reporting node.
DIAMETER_UNABLE_TO_COMPLY would be sent in this case.
A second example is when an agent that supports the DOIC solution
is performing the role of a reacting node for a non-supporting
client. Requests that are rejected as a result of DOIC throttling
by the agent in this scenario would generally be rejected with a
DIAMETER_UNABLE_TO_COMPLY response code.
9. IANA Considerations
9.1. AVP Codes
New AVPs defined by this specification are listed in Section 7. All
AVP codes are allocated from the "AVP Codes" sub-registry under the
"Authentication, Authorization, and Accounting (AAA) Parameters"
registry.
9.2. New Registries
Two new registries have been created in the "AVP Specific Values"
sub-registry under the "Authentication, Authorization, and Accounting
(AAA) Parameters" registry.
A new "OC-Feature-Vector AVP Values (code 622)" registry has been
created. This registry contains the following:
Feature Vector Value Name
Feature Vector Value
Specification defining the new value
See Section 7.2 for the initial Feature Vector Value in the registry.
This specification defines the value. New values can be added to the
registry using the Specification Required policy [RFC5226].
A new "OC-Report-Type AVP Values (code 626)" registry has been
created. This registry contains the following:
Report Type Value Name
Report Type Value
Specification defining the new value
See Section 7.6 for the initial assignment in the registry. New
types can be added using the Specification Required policy [RFC5226].
10. Security Considerations
DOIC gives Diameter nodes the ability to request that downstream
nodes send fewer Diameter requests. Nodes do this by exchanging
overload reports that directly effect this reduction. This exchange
is potentially subject to multiple methods of attack and has the
potential to be used as a denial-of-service (DoS) attack vector. For
instance, a series of injected realm OLRs with a requested reduction
percentage of 100% could be used to completely eliminate any traffic
from being sent to that realm.
Overload reports may contain information about the topology and
current status of a Diameter network. This information is
potentially sensitive. Network operators may wish to control
disclosure of overload reports to unauthorized parties to avoid their
use for competitive intelligence or to target attacks.
Diameter does not include features to provide end-to-end
authentication, integrity protection, or confidentiality. This may
cause complications when sending overload reports between non-
adjacent nodes.
10.1. Potential Threat Modes
The Diameter protocol involves transactions in the form of requests
and answers exchanged between clients and servers. These clients and
servers may be peers, that is, they may share a direct transport
(e.g., TCP or SCTP) connection, or the messages may traverse one or
more intermediaries, known as Diameter Agents. Diameter nodes use
TLS, DTLS, or IPsec to authenticate peers and to provide
confidentiality and integrity protection of traffic between peers.
Nodes can make authorization decisions based on the peer identities
authenticated at the transport layer.
When agents are involved, this presents an effectively transitive
trust model. That is, a Diameter client or server can authorize an
agent for certain actions, but it must trust that agent to make
appropriate authorization decisions about its peers, and so on.
Since confidentiality and integrity protection occur at the transport
layer, agents can read, and perhaps modify, any part of a Diameter
message, including an overload report.
There are several ways an attacker might attempt to exploit the
overload control mechanism. An unauthorized third party might inject
an overload report into the network. If this third party is upstream
of an agent, and that agent fails to apply proper authorization
policies, downstream nodes may mistakenly trust the report. This
attack is at least partially mitigated by the assumption that nodes
include overload reports in Diameter answers but not in requests.
This requires an attacker to have knowledge of the original request
in order to construct an answer. Such an answer would also need to
arrive at a Diameter node via a protected transport connection.
Therefore, implementations MUST validate that an answer containing an
overload report is a properly constructed response to a pending
request prior to acting on the overload report, and that the answer
was received via an appropriate transport connection.
A similar attack involves a compromised but otherwise authorized node
that sends an inappropriate overload report. For example, a server
for the realm "example.com" might send an overload report indicating
that a competitor's realm "example.net" is overloaded. If other
nodes act on the report, they may falsely believe that "example.net"
is overloaded, effectively reducing that realm's capacity.
Therefore, it's critical that nodes validate that an overload report
received from a peer actually falls within that peer's responsibility
before acting on the report or forwarding the report to other peers.
For example, an overload report from a peer that applies to a realm
not handled by that peer is suspect. This may require out-of-band,
non-Diameter agreements and/or mechanisms.
This attack is partially mitigated by the fact that the
application, as well as host and realm, for a given OLR is
determined implicitly by respective AVPs in the enclosing answer.
If a reporting node modifies any of those AVPs, the enclosing
transaction will also be affected.
10.2. Denial-of-Service Attacks
Diameter overload reports, especially realm reports, can cause a node
to cease sending some or all Diameter requests for an extended
period. This makes them a tempting vector for DoS attacks.
Furthermore, since Diameter is almost always used in support of other
protocols, a DoS attack on Diameter is likely to impact those protocols as well. In the worst case, where the Diameter application is being used for access control into an IP network, a coordinated DoS attack could result in the blockage of all traffic into that network. Therefore, Diameter nodes MUST NOT honor or forward OLRs received from peers that are not trusted to send them. An attacker might use the information in an OLR to assist in DoS attacks. For example, an attacker could use information about current overload conditions to time an attack for maximum effect, or use subsequent overload reports as a feedback mechanism to learn the results of a previous or ongoing attack. Operators need the ability to ensure that OLRs are not leaked to untrusted parties.10.3. Noncompliant Nodes
In the absence of an overload control mechanism, Diameter nodes need to implement strategies to protect themselves from floods of requests, and to make sure that a disproportionate load from one source does not prevent other sources from receiving service. For example, a Diameter server might throttle a certain percentage of requests from sources that exceed certain limits. Overload control can be thought of as an optimization for such strategies, where downstream nodes never send the excess requests in the first place. However, the presence of an overload control mechanism does not remove the need for these other protection strategies. When a Diameter node sends an overload report, it cannot assume that all nodes will comply, even if they indicate support for DOIC. A noncompliant node might continue to send requests with no reduction in load. Such noncompliance could be done accidentally or maliciously to gain an unfair advantage over compliant nodes. Requirement 28 in [RFC7068] indicates that the overload control solution cannot assume that all Diameter nodes in a network are trusted. It also requires that malicious nodes not be allowed to take advantage of the overload control mechanism to get more than their fair share of service.10.4. End-to-End Security Issues
The lack of end-to-end integrity features makes it difficult to establish trust in overload reports received from non-adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive- trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter
overload control MUST give operators the ability to select which
peers are trusted to deliver overload reports and whether they are
trusted to forward overload reports from non-adjacent nodes. DOIC
nodes MUST strip DOIC AVPs from messages received from peers that are
not trusted for DOIC purposes.
The lack of end-to-end confidentiality protection means that any
Diameter Agent in the path of an overload report can view the
contents of that report. In addition to the requirement to select
which peers are trusted to send overload reports, operators MUST be
able to select which peers are authorized to receive reports. A node
MUST NOT send an overload report to a peer not authorized to receive
it. Furthermore, an agent MUST remove any overload reports that
might have been inserted by other nodes before forwarding a Diameter
message to a peer that is not authorized to receive overload reports.
A DOIC node cannot always automatically detect that a peer also
supports DOIC. For example, a node might have a peer that is a
non-supporting agent. If nodes on the other side of that agent
send OC-Supported-Features AVPs, the agent is likely to forward
them as unknown AVPs. Messages received across the non-supporting
agent may be indistinguishable from messages received across a
DOIC supporting agent, giving the false impression that the non-
supporting agent actually supports DOIC. This complicates the
transitive-trust nature of DOIC. Operators need to be careful to
avoid situations where a non-supporting agent is mistakenly
trusted to enforce DOIC-related authorization policies.
It is expected that work on end-to-end Diameter security might make
it easier to establish trust in non-adjacent nodes for overload
control purposes. Readers should be reminded, however, that the
overload control mechanism allows Diameter Agents to modify AVPs in,
or insert additional AVPs into, existing messages that are originated
by other nodes. If end-to-end security is enabled, there is a risk
that such modification could violate integrity protection. The
details of using any future Diameter end-to-end security mechanism
with overload control will require careful consideration, and are
beyond the scope of this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.11.2. Informative References
[Cx] 3GPP, "Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 12.7.0, September 2015. [PCC] 3GPP, "Policy and charging control architecture", 3GPP TS 23.203 12.10.0, September 2015. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005, <http://www.rfc-editor.org/info/rfc4006>. [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control Requirements", RFC 7068, DOI 10.17487/RFC7068, November 2013, <http://www.rfc-editor.org/info/rfc7068>. [S13] 3GPP, "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol", 3GPP TS 29.272 12.8.0, September 2015.
Appendix A. Issues Left for Future Specifications
The base solution for overload control does not cover all possible use cases. A number of solution aspects were intentionally left for future specification and protocol work. The following subsections define some of the potential extensions to the DOIC solution.A.1. Additional Traffic Abatement Algorithms
This specification describes only means for a simple loss-based algorithm. Future algorithms can be added using the designed solution extension mechanism. The new algorithms need to be registered with IANA. See Sections 7.2 and 9 for the required IANA steps.A.2. Agent Overload
This specification focuses on Diameter endpoint (server or client) overload. A separate extension will be required to outline the handling of the case of agent overload.A.3. New Error Diagnostic AVP
This specification indicates the use of existing error messages when nodes reject requests due to overload. There is an expectation that additional error codes or AVPs will be defined in a separate specification to indicate that overload was the reason for the rejection of the message.Appendix B. Deployment Considerations
Non-supporting Agents Due to the way that realm-routed requests are handled in Diameter networks with the server selection for the request done by an agent, network operators should enable DOIC at agents that perform server selection first. Topology-Hiding Interactions There exist proxies that implement what is referred to as Topology Hiding. This can include cases where the agent modifies the Origin-Host in answer messages. The behavior of the DOIC solution is not well understood when this happens. As such, the DOIC solution does not address this scenario.
Inter-Realm/Administrative Domain Considerations
There are likely to be special considerations for handling DOIC
signaling across administrative boundaries. This includes
considerations for whether or not information included in the DOIC
signaling should be sent across those boundaries. In addition,
consideration should be taken as to whether or not a reacting node
in one realm can be trusted to implement the requested overload
abatement handling for overload reports received from a separately
administered realm.
Appendix C. Considerations for Applications Integrating the DOIC
Solution
This section outlines considerations to be taken into account when
integrating the DOIC solution into Diameter applications.
C.1. Application Classification
The following is a classification of Diameter applications and
request types. This discussion is meant to document factors that
play into decisions made by the Diameter entity responsible for
handling overload reports.
Section 8.1 of [RFC6733] defines two state machines that imply two
types of applications, session-less and session-based applications.
The primary difference between these types of applications is the
lifetime of Session-Ids.
For session-based applications, the Session-Id is used to tie
multiple requests into a single session.
The Credit-Control application defined in [RFC4006] is an example of
a Diameter session-based application.
In session-less applications, the lifetime of the Session-Id is a
single Diameter transaction, i.e., the session is implicitly
terminated after a single Diameter transaction and a new Session-Id
is generated for each Diameter request.
For the purposes of this discussion, session-less applications are
further divided into two types of applications:
Stateless Applications:
Requests within a stateless application have no relationship to
each other. The 3GPP-defined S13 application is an example of a
stateless application [S13], where only a Diameter command is
defined between a client and a server and no state is maintained
between two consecutive transactions.
Pseudo-Session Applications:
Applications that do not rely on the Session-Id AVP for
correlation of application messages related to the same session
but use other session-related information in the Diameter requests
for this purpose. The 3GPP-defined Cx application [Cx] is an
example of a pseudo-session application.
The handling of overload reports must take the type of application
into consideration, as discussed in Appendix C.2.
C.2. Implications of Application Type Overload
This section discusses considerations for mitigating overload
reported by a Diameter entity. This discussion focuses on the type
of application. Appendix C.3 discusses considerations for handling
various request types when the target server is known to be in an
overloaded state.
These discussions assume that the strategy for mitigating the
reported overload is to reduce the overall workload sent to the
overloaded entity. The concept of applying overload treatment to
requests targeted for an overloaded Diameter entity is inherent to
this discussion. The method used to reduce offered load is not
specified here, but it could include routing requests to another
Diameter entity known to be able to handle them, or it could mean
rejecting certain requests. For a Diameter Agent, rejecting requests
will usually mean generating appropriate Diameter error responses.
For a Diameter client, rejecting requests will depend upon the
application. For example, it could mean giving an indication to the
entity requesting the Diameter service that the network is busy and
to try again later.
Stateless Applications:
By definition, there is no relationship between individual
requests in a stateless application. As a result, when a request
is sent or relayed to an overloaded Diameter entity -- either a
Diameter Server or a Diameter Agent -- the sending or relaying
entity can choose to apply the overload treatment to any request
targeted for the overloaded entity.
Pseudo-session Applications:
For pseudo-session applications, there is an implied ordering of
requests. As a result, decisions about which requests towards an
overloaded entity to reject could take the command code of the
request into consideration. This generally means that
transactions later in the sequence of transactions should be given
more favorable treatment than messages earlier in the sequence.
This is because more work has already been done by the Diameter
network for those transactions that occur later in the sequence.
Rejecting them could result in increasing the load on the network
as the transactions earlier in the sequence might also need to be
repeated.
Session-Based Applications:
Overload handling for session-based applications must take into
consideration the work load associated with setting up and
maintaining a session. As such, the entity sending requests
towards an overloaded Diameter entity for a session-based
application might tend to reject new session requests prior to
rejecting intra-session requests. In addition, session-ending
requests might be given a lower probability of being rejected, as
rejecting session-ending requests could result in session status
being out of sync between the Diameter clients and servers.
Application designers that would decide to reject mid-session
requests will need to consider whether the rejection invalidates
the session and any resulting session cleanup procedures.
C.3. Request Transaction Classification
Independent Request:
An independent request is not correlated to any other requests,
and, as such, the lifetime of the Session-Id is constrained to an
individual transaction.
Session-Initiating Request:
A session-initiating request is the initial message that
establishes a Diameter session. The ACR message defined in
[RFC6733] is an example of a session-initiating request.
Correlated Session-Initiating Request:
There are cases when multiple session-initiated requests must be
correlated and managed by the same Diameter server. It is notably
the case in the 3GPP Policy and Charging Control (PCC)
architecture [PCC], where multiple apparently independent Diameter
application sessions are actually correlated and must be handled
by the same Diameter server.
Intra-session Request:
An intra-session request is a request that uses the same Session-
Id as the one used in a previous request. An intra-session
request generally needs to be delivered to the server that handled
the session-creating request for the session. The STR message
defined in [RFC6733] is an example of an intra-session request.
Pseudo-session Requests:
Pseudo-session requests are independent requests and do not use
the same Session-Id but are correlated by other session-related
information contained in the request. There exist Diameter
applications that define an expected ordering of transactions.
This sequencing of independent transactions results in a pseudo-
session. The AIR, MAR, and SAR requests in the 3GPP-defined Cx
[Cx] application are examples of pseudo-session requests.
C.4. Request Type Overload Implications
The request classes identified in Appendix C.3 have implications on
decisions about which requests should be throttled first. The
following list of request treatments regarding throttling is provided
as guidelines for application designers when implementing the
Diameter overload control mechanism described in this document. The
exact behavior regarding throttling is a matter of local policy,
unless specifically defined for the application.
Independent Requests:
Independent requests can generally be given equal treatment when
making throttling decisions, unless otherwise indicated by
application requirements or local policy.
Session-Initiating Requests:
Session-initiating requests often represent more work than
independent or intra-session requests. Moreover, session-
initiating requests are typically followed by other session-
related requests. Since the main objective of overload control is
to reduce the total number of requests sent to the overloaded
entity, throttling decisions might favor allowing intra-session
requests over session-initiating requests. In the absence of
local policies or application-specific requirements to the
contrary, individual session-initiating requests can be given
equal treatment when making throttling decisions.
Correlated Session-Initiating Requests:
A request that results in a new binding; where the binding is used
for routing of subsequent session-initiating requests to the same
server, it represents more work load than other requests. As
such, these requests might be throttled more frequently than other
request types.
Pseudo-session Requests:
Throttling decisions for pseudo-session requests can take into
consideration where individual requests fit into the overall
sequence of requests within the pseudo-session. Requests that are
earlier in the sequence might be throttled more aggressively than
requests that occur later in the sequence.
Intra-session Requests:
There are two types of intra-sessions requests, requests that
terminate a session and the remainder of intra-session requests.
Implementers and operators may choose to throttle session-
terminating requests less aggressively in order to gracefully
terminate sessions, allow cleanup of the related resources (e.g.,
session state), and avoid the need for additional intra-session
requests. Favoring session termination requests may reduce the
session management impact on the overloaded entity. The default
handling of other intra-session requests might be to treat them
equally when making throttling decisions. There might also be
application-level considerations whether some request types are
favored over others.
Contributors
The following people contributed substantial ideas, feedback, and discussion to this document: o Eric McMurry o Hannes Tschofenig o Ulrich Wiehe o Jean-Jacques Trottin o Maria Cruz Bartolome o Martin Dolly o Nirav Salot o Susan Shishufeng
Authors' Addresses
Jouni Korhonen (editor) Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 United States Email: jouni.nospam@gmail.com Steve Donovan (editor) Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: srdonovan@usdonovans.com Ben Campbell Oracle 7460 Warren Parkway Frisco, Texas 75034 United States Email: ben@nostrum.com Lionel Morand Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France Phone: +33145296257 Email: lionel.morand@orange.com