tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7683

 
 
 

Diameter Overload Indication Conveyance

Part 2 of 2, p. 23 to 42
Prev RFC Part

 


prevText      Top      Up      ToC       Page 23 
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

Top      Up      ToC       Page 24 
       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.

Top      Up      ToC       Page 25 
      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.

Top      Up      ToC       Page 26 
   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

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
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.

Top      Up      ToC       Page 29 
      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].

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
   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

Top      Up      ToC       Page 32 
   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

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
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.

Top      Up      ToC       Page 35 
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.

Top      Up      ToC       Page 36 
   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.

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
   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.

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
   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.

Top      Up      ToC       Page 41 
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

Top      Up      ToC       Page 42 
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