[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 Draft is active
In: Edit-wait
Internet Engineering Task Force                              B. Campbell
Internet-Draft                                           S. Donovan, Ed.
Intended status: Standards Track                                  Oracle
Expires: September 19, 2016                                  JJ. Trottin
                                                                   Nokia
                                                          March 18, 2016


                  Diameter Load Information Conveyance
                        draft-ietf-dime-load-02

Abstract

   This document defines a mechanism for sharing of Diameter load
   information.  [RFC7068] describes requirements for Overload Control
   in Diameter.  This includes a requirement to allow Diameter nodes to
   send "load" information, even when the node is not overloaded.  The
   Diameter Overload Information Conveyance (DOIC) [RFC7683] solution
   describes a mechanism meeting most of the requirements, but does not
   currently include the ability to send load information.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 19, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Campbell, et al.       Expires September 19, 2016               [Page 1]


Internet-Draft              Abbreviated Title                 March 2016


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   3
   3.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Differences between Load and Overload information . . . .   4
     4.2.  How is Load Information Used? . . . . . . . . . . . . . .   5
   5.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Theory of Operation . . . . . . . . . . . . . . . . . . .   7
   6.  Load Mechanism Procedures . . . . . . . . . . . . . . . . . .  10
     6.1.  Reporting Node Behavior . . . . . . . . . . . . . . . . .  10
       6.1.1.  Endpoint Reporting Node Behavior  . . . . . . . . . .  10
       6.1.2.  Agent Reporting Node Behavior . . . . . . . . . . . .  11
     6.2.  Receiving Node Behavior . . . . . . . . . . . . . . . . .  11
     6.3.  Extensibility . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Attribute Value Pairs . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Load AVP  . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.2.  Load-Type AVP . . . . . . . . . . . . . . . . . . . . . .  13
     7.3.  Load-Value AVP  . . . . . . . . . . . . . . . . . . . . .  13
     7.4.  SourceID AVP  . . . . . . . . . . . . . . . . . . . . . .  14
     7.5.  Attribute Value Pair flag rules . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.2.  New Registries  . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Topology Scenarios . . . . . . . . . . . . . . . . .  16
     A.1.  No Agent  . . . . . . . . . . . . . . . . . . . . . . . .  16
     A.2.  Single Agent  . . . . . . . . . . . . . . . . . . . . . .  16
     A.3.  Multiple Agents . . . . . . . . . . . . . . . . . . . . .  17
     A.4.  Linked Agents . . . . . . . . . . . . . . . . . . . . . .  18
     A.5.  Shared Server Pools . . . . . . . . . . . . . . . . . . .  19
     A.6.  Agent Chains  . . . . . . . . . . . . . . . . . . . . . .  19
     A.7.  Fully Meshed Layers . . . . . . . . . . . . . . . . . . .  20
     A.8.  Partitions  . . . . . . . . . . . . . . . . . . . . . . .  20
     A.9.  Active-Standby Nodes  . . . . . . . . . . . . . . . . . .  20
     A.10. Addition and removal of Nodes . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21





Campbell, et al.       Expires September 19, 2016               [Page 2]


Internet-Draft              Abbreviated Title                 March 2016


1.  Introduction

   [RFC7068] describes requirements for Overload Control in Diameter
   [RFC6733].  The DIME working group has finished the Diameter Overload
   Information Conveyance (DOIC) mechanism [RFC7683].  As currently
   specified, DOIC fulfills some, but not all, of the requirements.

   In particular, DOIC does not fulfill Req 24, which requires a
   mechanism where Diameter nodes can indicate their current load, even
   if they are not currently overloaded.  DOIC also does not fulfill Req
   23, which requires that nodes that divert traffic away from
   overloaded nodes be provided with sufficient information to select
   targets that are most likely to have sufficient capacity.

   There are several other requirements in [RFC7068] that mention both
   overload and load information that are only partially fulfilled by
   DOIC.

   The DIME working group explicitly chose not to fulfill these
   requirements in DOIC due to several reasons.  A principal reason was
   that the working group did not agree on a general approach for
   conveying load information.  It chose to progress the rest of DOIC,
   and deferred load information conveyance to a DOIC extension or a
   separate mechanism.

   This document defines a mechanism that addresses the load-related
   requirements from RFC 7068.

2.  Terminology and Abbreviations

   DOIC

      Diameter Overload Information Conveyance ([RFC7683])

   Load

      The relative capacity of a Diameter node.  A low load level
      indicates that the Diameter node is under utilized.  A high load
      level indicates that the node is closer to being fully utilized.

   Offered Load

      The actual traffic sent to the reporting node after overload
      abatement and routing decisions are made.

   Reporting, Reacting Node





Campbell, et al.       Expires September 19, 2016               [Page 3]


Internet-Draft              Abbreviated Title                 March 2016


      Reporting node and reacting node terminology is defined in
      [RFC7683].

   Routing Information

      Routing Information - Routing information referred to in this
      document can include the Routing and Peer tables defined in RFC
      6733.  It can also include other implementation specific tables
      used to store load information.  This document does not define the
      structure of such tables.

3.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   RFC 2119 [RFC2119] interpretation does not apply for the above listed
   words when they are not used in all-caps format.

4.  Background

4.1.  Differences between Load and Overload information

   Previous discussions of how to solve the load-related requirements in
   [RFC7068] have shown that people did not had an agreed-upon concept
   of how "load" information differs from "overload" information.  While
   the two concepts are highly interrelated, in the opinion of the
   authors, there are two primary differences.  First, a Diameter node
   always has a load.  At any given time that load maybe effectively
   zero, effectively fully loaded, or somewhere in between.  In
   contrast, overload is an exceptional condition.  A node only has
   overload information when it is in an overloaded state.  Furthermore,
   the relationship between a node's load level and overload state at
   any given time may be vague.  For example, a node may normally
   operate at a "fully loaded" level, but still not be considered
   overloaded.  Another node may declare itself to be "overloaded" even
   though it might not be fully "loaded".

   Second, Overload information, in the form of a DOIC Overload Report
   (OLR) [RFC7683] indicates an explicit request for action on the part
   of the reacting node.  That is, the OLR requests that the reacting
   node reduce the offered load -- the actual traffic sent to the
   reporting node after overload abatement and routing decisions are
   made -- by an indicated amount or to an indicated level.
   Effectively, DOIC provides a contract between the reporting node and
   the reacting node.




Campbell, et al.       Expires September 19, 2016               [Page 4]


Internet-Draft              Abbreviated Title                 March 2016


   In contrast, load is informational.  That is, load information can be
   considered a hint to the recipient node.  That node may use the load
   information for load balancing purposes, as an input to certain
   overload abatement techniques, to make inferences about the
   likelihood that the sending node becomes overloaded in the immediate
   future, or for other purposes.

   None of this prevents a Diameter node from deciding to reduce the
   offered load based on load information.  The fundamental difference
   is that an overload report requires that reduction.  It is also
   reasonable for a Diameter node to decide to increase the offered load
   based on load information.

4.2.  How is Load Information Used?

   [RFC7068] contemplates two primary uses for load information.  Req 23
   discusses how load information might be used when performing
   diversion as an overload abatement technique, as described in
   [RFC7683].  When a reacting node diverts traffic away from an
   overloaded node, it needs load information for the other candidates
   for that traffic in order to effectively load balance the diverted
   load between potential candidates.  Otherwise, diversion has a
   greater potential to drive other nodes into overload.

   Req 24 discusses how Diameter load information might be used when no
   overload condition currently exists.  Diameter nodes can use the load
   information to make decisions to try to avoid overload conditions in
   the first place.  Normal load-balancing falls into this category.  A
   node might also take other proactive steps to reduce offered load
   based on load information, so that the loaded node never goes into
   overload in the first place.

   If the loaded nodes are Diameter servers (or clients in the case of
   server-to-client transactions), both of these uses are most
   effectively accomplished by a Diameter node that performs server
   selection.  Typically, server selection is performed by a node (a
   client or an agent) that is an immediate peer of the server.
   However, there are scenarios (see Appendix A) where a client or proxy
   that is not the immediate peer to the selected servers performs
   server selection.  In this case, the client or proxy enforces the
   server selection by inserting a Destination-Host AVP.

      For example, a Diameter node (e.g. client) can use a redirect
      agent to get candidate destination host addresses.  The redirect
      agent might return several destination host addresses, from which
      the Diameter node selects one.  The Diameter node can use load
      information received from these hosts to make the selection.




Campbell, et al.       Expires September 19, 2016               [Page 5]


Internet-Draft              Abbreviated Title                 March 2016


   Just as load information can be used as part of server selection, it
   can also be used as input to the selection of the next-hop peer to
   which a request is to be routed.

   It should be noted that a Diameter node will need to process both
   Load reports and Overload reports from the same Diameter node.  The
   reacting node for the Overload report always has the responsibility
   to reduce the amount of Diameter traffic sent to the overloaded node.
   If, or how, the reacting node uses Load information to achieve this
   is left as an implementation decision.

5.  Solution Overview

   The mechanism defined here for the conveyance of load information is
   similar in some ways to the mechanism defined for DOIC and is
   different in other ways.

   As with DOIC, load information is conveyed by piggy-backing the load
   AVPs on existing Diameter applications.

   There are two primary differences.  First, there is no capability
   negotiation process for load.  The sender of the load information is
   sending it with the expectation that any supporting nodes will use it
   when making routing decisions.  If there are no nodes that support
   the Load mechanism then the load information is ignored.

   The second big difference between DOIC and Load is visibility of the
   DOIC or Load information within a Diameter network.  DOIC information
   is sent end-to-end resulting in the ability of all nodes in the path
   of the answer message that carries the OC-OLR AVP to act on the
   information.  The DOIC overload reports much remain in the message
   all the way from the reporting node to the node that is the target
   for the answer message.

   For the Load mechanism there are two types of load reports.

   The first is the load of the endpoint sending the answer message.
   This load report is carried end-to-end to enable any nodes that make
   server selection decisions to use the load status of the sending
   endpoint as part of the server selection decision.

   The second type of load report is a peer report.  This report is used
   by Diameter nodes as part of the logic to select the next hop
   Diameter node and, as such, do not have significance beyond the peer
   node.  These load reports are removed by the first supporting
   Diameter node to receive the report.





Campbell, et al.       Expires September 19, 2016               [Page 6]


Internet-Draft              Abbreviated Title                 March 2016


   Because load reports can traverse Diameter nodes that do not support
   the Load mechanism, it is necessary to include the identity of the
   node to which the load report applies as part of the load report.
   This allows for a Diameter node to verify that a load report applies
   to its peer or if it should be ignored.

   The load report includes the relative load of the sending node.  This
   relative load is specified in a manner consistent with that defined
   for DNS SRV [RFC2782].

   The goal is make it possible to use both the load values received as
   a part of the Diameter Load mechanism and weight values received as a
   result of a DNS SRV query.  As a result, the Diameter load value has
   a range of 0-65535.  This value and DNS SRV weight values are then
   used in a distribution algorithm similar to that specified in
   [RFC2782].

   The DNS SRV distribution algorithm results in more messages being
   sent to a node with a higher weight value.  As a result, a higher
   Diameter load value indicates a LOWER load on the sending node.  A
   node that is heavily loaded sends a lower Diameter load value.
   Stated another way, a node that has zero load would have a load value
   of 65535.  A node that is 100% loaded would have a load value of 0.

   The distribution algorithm used by Diameter nodes supporting the
   Diameter Load mechanism is an implementation decision but it needs to
   result in similar behavior as the algorithm specified in [RFC2782].

   The method for calculating the load value included in the load report
   is also left as an implementation decision.

   The frequency for sending of load reports is also left as an
   implementation decision.  The sending node might choose to send load
   reports in all messages or it might choose to only send load reports
   when the load value has changed by some implementation specific
   amount.  The important consideration is that all nodes needing the
   load information have a sufficiently accurate view of the nodes load.

5.1.  Theory of Operation

   This section outlines how the Diameter Load mechanism is expected to
   work.

   For this discussion, assume the following Diameter network
   configuration:






Campbell, et al.       Expires September 19, 2016               [Page 7]


Internet-Draft              Abbreviated Title                 March 2016


           ---A1---A3----S[1], S[2]...S[p]
          /   | \ /
         C    |  x
          \   | / \
           ---A2---A4----S[p+1], S[p+2] ...S[n]


                    Figure 1: Example Diameter Network

   Note that in this diagram, S[1], S[2] through S[p] are peers to A3.
   S[p+1], S[p+2] through S[n] are peers to A4.

   Also assume that the request for a Diameter transaction takes the
   following path:

         C     A1     A4     S[n]
         |      |      |      |
         |----->|----->|----->|
         xxR     xxR    xxR



                      Figure 2: Request Message Path

   When sending the answer message, an endpoint node that supports the
   Diameter Load mechanism includes it's own load information in the
   answer message.  Because it is a Diameter endpoint it includes a HOST
   load report.

         C     A1     A4     S[n]
         |      |      |      |
         |      |      |<-----|
         |      |       xxA(Load type:HOST, source:S[n])
         |      |      |      |


                    Figure 3: Answer Message from S[n]

   If Agent A4 supports the Load mechanism then it will verify that the
   load information received is valid.  For a HOST load report this is
   achieved by matching the identity included in the load information
   with the identity of the host node from which the answer message was
   received.

      Note: If A4 does not support the Load mechanism then it will relay
      the answer message without doing any processing on the load
      information.  In this case the load information AVPs will be
      relayed without change.



Campbell, et al.       Expires September 19, 2016               [Page 8]


Internet-Draft              Abbreviated Title                 March 2016


   If the identity included in the load information AVPs matches the
   identity of the host from which the load information is received then
   Agent A4 stores the load information for S[n] in its routing
   information.

   Because the load report is an HOST load report, A4 leaves the load
   report in the message it relays.

   A4 then calculates its own load information and inserts load
   information AVPs of type PEER in the message before sending the
   message to A1:

         C     A1     A4     S[n]
         |      |      |      |
         |      |<-----|      |
         |       xxA(Load type:PEER, source:A4)
         |       xxA(Load type:HOST, source:S[n])
         |      |      |      |


                     Figure 4: Answer Message from A4

   If A1 supports the Load mechanism then it processes each of the Load
   reports it receives separately.

   For the PEER load report, A1 first determines if the source of the
   report indicated in the load report matches the DiameterIdentity of
   the Diameter node from which the request was received.  If the
   identities do not match then the PEER load report is discarded.  If
   the identities match then A1 saves the load information in its
   routing information for routing of subsequent request messages.  In
   both cases A1 strips the PEER load report from the message.

   For the HOST load report, A1's actions depend on whether A1 is
   responsible for doing server selection.  If A1 is not doing server
   selection then A1 ignores the HOST load report.  If A1 is responsible
   for doing server selection then it stores the load information for
   S[n] in its routing information for the handling of subsequent
   request messages.  In both cases A1 leaves the HOST report in the
   message.

   A1 then calculates its own load information and inserts load
   information AVPs of type PEER in the message before sending the
   message to A1:







Campbell, et al.       Expires September 19, 2016               [Page 9]


Internet-Draft              Abbreviated Title                 March 2016


         C     A1     A4     S[n]
         |      |      |      |
         |<-----|      |      |
          xxA(Load type:PEER, source:A1)
          xxA(Load type:HOST, source:S[n])


                     Figure 5: Answer Message from A1

   As with A1, C processes each load report separately.

   For the PEER load report, C follows the same procedure as A1 for
   determining if the Load report was received from the peer from which
   the report was sent and, when finding it does, stores the load
   information for use when making future routing decisions.

   For the HOST load report, C saves the load information only if it is
   responsible for doing server selection.

   The Load information received by all nodes is then used for routing
   of subsequent request messages.

6.  Load Mechanism Procedures

   This section defines the normative behaviors for the Load mechanism.

6.1.  Reporting Node Behavior

   This section defines the procedures of Diameter reporting nodes that
   generate load reports.

6.1.1.  Endpoint Reporting Node Behavior

   A Diameter endpoint that supports the Diameter Load mechanism MUST
   include a load report of type HOST in sufficient answer messages to
   ensure that all consumers of the load information receive timely
   updates.

   The Diameter endpoint MUST include it's own DiameterIdentity in the
   Source-ID AVP included in the Load AVP.

   The Diameter endpoint MUST include a Load-Type AVP of type HOST in
   the Load AVP.

   The Diameter endpoint MUST include its load value in the Value AVP in
   the load AVP.





Campbell, et al.       Expires September 19, 2016              [Page 10]


Internet-Draft              Abbreviated Title                 March 2016


   The method for determining the load value included in the load report
   is an implementation decision.

   The frequency of sending load reports is an implementation decision.

      For instance, if the only consumer of the load reports is the
      endpoints peer then the endpoint can choose to only include a load
      report when the load of the endpoint has changed by a meaningful
      percentage.  If there are consumers of the endpoint load report
      other then the endpoints peer (this will be the case if other
      nodes are responsible for server selection) then the endpoint
      might choose to include load reports in all answer messages as a
      way of ensuring that all nodes doing server selection get accurate
      load information.

6.1.2.  Agent Reporting Node Behavior

   A Diameter agent that supports the Diameter Load mechanism MUST
   include a PEER load report in sufficient answer messages to ensure
   that all users of the load information receive timely updates.

   The Diameter agent MUST include it's own DiameterIdentity in the
   Source-ID AVP included in the Load AVP.

   The Diameter agent MUST include a Load-Type AVP of type PEER in the
   Load AVP.

   The Diameter agent MUST include its load value in the Value AVP in
   the load AVP.

   The method for determining the load value included in the load report
   is an implementation decision.

   The frequency of sending load reports is an implementation decision.

      Note: In the case of peer load reports it is only necessary to
      include load reports when the load value has changed by some
      meaningful value, as long as the agent insures that all peers
      receive the report.  It is also acceptable to include the load
      report in every answer message handled by the Diameter agent.

6.2.  Receiving Node Behavior

   This section defines the behavior of Diameter nodes processing load
   reports.

   A Diameter node MUST be prepared to process load reports of type HOST
   and of type PEER, as indicated in the Load-Type AVP included in the



Campbell, et al.       Expires September 19, 2016              [Page 11]


Internet-Draft              Abbreviated Title                 March 2016


   Load AVP received in the same answer message or from multiple answer
   messages.

      Note that the node needs to be able to handle messages with no
      load reports, messages with just a PEER load report, messages with
      just an HOST load report and messages with both types of load
      reports.

   If the Diameter node is not responsible for doing server selection
   then it SHOULD ignore load reports of type HOST.

   If the Diameter node is responsible for doing server selection then
   it SHOULD save the load value included in the Value AVP included in
   the Load AVP of type HOST in its routing information.

   If the Diameter node receives a Load report of type PEER then the
   Diameter node MUST determine if the Load report was inserted into the
   answer message by the peer from which the message was received.  This
   is achieved by comparing the DiameterIdentity associated with the
   connection from which the message was received with the
   DiameterIdentity included in the Source-ID AVP in the Load report.

   If the Diameter node determines that the Load report of type PEER was
   not received from the peer that sent or relayed the answer message
   then the node MUST ignore the Load report.

   If the Diameter node determines that the Load report of type PEER was
   received from the peer that sent or relayed the answer message then
   the node SHOULD save the load information in its routing information.

   How a Diameter node uses load information for making routing
   decisions is an implementation decision.  However, the distribution
   algorithm MUST result in similar behavior as the algorithm described
   for the use of weigth values in [RFC2782].

6.3.  Extensibility

   The Load mechanism can be extended to include additional information
   in the load reports.

   Any extension may define new AVPs for use in Load reports.  These new
   AVPs SHOULD be defined to be extensions to the Load AVPs defined in
   this document.

   [RFC6733] defined Grouped AVP extension mechanisms apply.  This
   allows, for example, defining a new feature that is mandatory to be
   understood even when piggybacked on an existing application.




Campbell, et al.       Expires September 19, 2016              [Page 12]


Internet-Draft              Abbreviated Title                 March 2016


   As with any Diameter specification, [RFC6733] requires all new AVPs
   to be registered with IANA.  See Section 9 for the required
   procedures.

7.  Attribute Value Pairs

   The section defines the AVPs required for the Load mechanism.

7.1.  Load AVP

   The Load AVP (AVP code TBD1) is of type Grouped and is used to convey
   load information between Diameter nodes.

    Load ::= < AVP Header: TBD1 >
             [ Load-Type ]
             [ Load-Value ]
             [ SourceID ]
           * [ AVP ]


7.2.  Load-Type AVP

   The Load-Type AVP (AVP code TBD2) is of type Enumerated.  It is used
   to convey the type of Diameter node that sent the load information.
   The following values are defined:

   HOST 0  The load report is for a host.

   PEER 1  The load report is for a peer.

7.3.  Load-Value AVP

   The Load-Value AVP (AVP code TBD3) is of type Unsigned64.  It is used
   to convey relative load information about the sender of the load
   report.

   The Load-Value AVP is specified in a manner similar to the weight
   value in DNS SRV ([RFC2782]).

   The Load-Value has a range of 0-65535.

   A higher value indicates a lower load on the sending node.  A lower
   value indicates that the sending node is heavily loaded.

      Stated another way, a node that has zero load would have a load
      value of 65535.  A node that is 100% loaded would have a load
      value of 0.




Campbell, et al.       Expires September 19, 2016              [Page 13]


Internet-Draft              Abbreviated Title                 March 2016


7.4.  SourceID AVP

   The SourceID AVP is defined in [I-D.ietf-dime-agent-overload].  It is
   used to identify the Diameter node that sent the Load report.

7.5.  Attribute Value Pair flag rules

                                                             +---------+
                                                             |AVP flag |
                                                             |rules    |
                                                             +----+----+
                            AVP   Section                    |    |MUST|
     Attribute Name         Code  Defined  Value Type        |MUST| NOT|
    +--------------------------------------------------------+----+----+
    |Load                   TBD1  x.1      Grouped           |    | V  |
    +--------------------------------------------------------+----+----+
    |Load-Type              TBD2  x.2      Enumerated        |    | V  |
    +--------------------------------------------------------+----+----+
    |Load-Value             TBD3  x.3      Unsigned64        |    | V  |
    +------------------------------------------------------ -+----+----+
    |SourceID               TBD4  x.4      DiameterIdentity  |    | V  |
    +--------------------------------------------------------+----+----+


   As described in the Diameter base protocol [RFC6733], the M-bit usage
   for a given AVP in a given command may be defined by the application.

8.  Security Considerations

   Load information may be sensitive information in some cases.
   Depending on the mechanism, an unauthorized recipient might be able
   to infer the topology of a Diameter network from load information.
   Load information might be useful in identifying targets for Denial of
   Service (DoS) attacks, where a node known to be already heavily
   loaded might be a tempting target.  Load information might also be
   useful as feedback about the success of an ongoing DoS attack.

   Any load information conveyance mechanism will need to allow
   operators to avoid sending load information to nodes that are not
   authorized to receive it.  Since Diameter currently only offers
   authentication of nodes at the transport level, any solution that
   sends load information to non-peer nodes might require a transitive-
   trust model.








Campbell, et al.       Expires September 19, 2016              [Page 14]


Internet-Draft              Abbreviated Title                 March 2016


9.  IANA Considerations

9.1.  AVP Codes

   New AVPs defined by this specification are listed in
   Section Section 7.  All AVP codes are allocated from the
   'Authentication, Authorization, and Accounting (AAA) Parameters' AVP
   Codes registry.

9.2.  New Registries

   This document makes no new registry requests of IANA.

10.  References

10.1.  Normative References

   [I-D.ietf-dime-agent-overload]
              Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
              agent-overload-02 (work in progress), August 2015.

   [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>.

   [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>.

   [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>.

   [RFC7683]  Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
              Morand, "Diameter Overload Indication Conveyance",
              RFC 7683, DOI 10.17487/RFC7683, October 2015,
              <http://www.rfc-editor.org/info/rfc7683>.

10.2.  Informative References

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <http://www.rfc-editor.org/info/rfc2782>.





Campbell, et al.       Expires September 19, 2016              [Page 15]


Internet-Draft              Abbreviated Title                 March 2016


Appendix A.  Topology Scenarios

   This section presents a number of Diameter topology scenarios, and
   discusses how load information might be used in each scenario.
   Nothing in this section should be construed to mean that a given
   scenario is in scope for this effort, or even a good idea.  Some
   scenarios might be considered as not relevant in practice and
   subsequently discarded.

A.1.  No Agent

   Figure 6 shows a simple client-server scenario, where a client picks
   from a set of candidate servers available for a particular realm and
   application.  The client selects the server for a given transaction
   using the load information received from each server.

       ------S1
      /
     C
      \
       ------S2


                  Figure 6: Basic Client Server Scenario

      If a node supports dynamic discovery, it will not obtain load
      information from the nodes with which it has no Diameter
      connection established.  Nevertheless it might take into account
      the load information from the other nodes to decide to add
      connections to new nodes with the dynamic discovery mechanism.

      Note: The use of dynamic connections needs to be considered.

A.2.  Single Agent

   Figure 7 shows a client that sends requests to an agent.  The agent
   selects the request destination from a set of candidate servers,
   using load information received from each server.  The client does
   not need to receive load information, since it does not select
   between multiple agents.











Campbell, et al.       Expires September 19, 2016              [Page 16]


Internet-Draft              Abbreviated Title                 March 2016


            ------S1
           /
     C----A
           \
            ------S2


                      Figure 7: Simple Agent Scenario

A.3.  Multiple Agents

   Figure 8 shows a client selecting between multiple agents, and each
   agent selecting from multiple servers.  The client selects an agent
   based on the load information received from each agent.  Each agent
   selects a server based on the load information received from its
   servers.

   This scenario adds a complication that one set of servers may be more
   loaded than the other set.  If, for example, S4 was the least loaded
   server, C would need to know to select agent A2 to reach S4.  This
   might require C to receive load information from the servers as well
   as the agents.  Alternatively, each agent might use the load of its
   servers as an input into calculating its own load, in effect
   aggregating upstream load.

   Similarly, if C sends a host-routed request [RFC7683], it needs to
   know which agent can deliver requests to the selected server.
   Without some special, potentially proprietary, knowledge of the
   topology upstream of A1 and A2, C would select the agent based on the
   normal peer selection procedures for the realm and application, and
   perhaps consider the load information from A1 and A2.  If C sends a
   request to A1 that contains a Destination-Host AVP with a value of
   S4, A1 will not be able to deliver the request.

             -----S3
            /
       ---A1------S1
      /
     C
      \
       ---A2------S2
            \
             ---- S4


                   Figure 8: Multiple Agents and Servers





Campbell, et al.       Expires September 19, 2016              [Page 17]


Internet-Draft              Abbreviated Title                 March 2016


A.4.  Linked Agents

   Figure 9 shows a scenario similar to that of Figure 8, except that
   the agents are linked, so that A1 can forward a request to A2, and
   vice-versa.  Each agent could receive load information from the
   linked agent, as well as its connected servers.

   This somewhat simplifies the complication from Figure 8, due to the
   fact that C does not necessarily need to choose a particular agent to
   reach a particular server.  But it creates a similar question of how,
   for example, A1 might know that S4 was less loaded than S1 or S3.
   Additionally, it creates the opportunity for sub-optimal request
   paths.  For example [C,A1,A2,S4] vs. [C,A2,S4].

   A likely application for linked agents is when each agent prefers to
   route only to directly connected servers and only forwards requests
   to another agent under exceptional circumstances.  For example, A1
   might not forward requests to A2 unless both S1 and S3 are
   overloaded.  In this case, A1 might use the load information from S1
   and S3 to select between those, and only consider the load
   information from A2 (and other connected agents) if it needs to
   divert requests to different agents.

              -----S3
             /
        ---A1------S1
      /    |
     C     |
      \    |
        ---A2------S2
             \
              ---- S4


                          Figure 9: Linked Agents

   Figure 10 is a variant of Figure 9.  In this case, C1 sends all
   traffic through A1 and C2 sends all traffic through A2.  By default,
   A1 will load balance traffic between S1 and S3 and A2 will load
   balance traffic between S2 and S4.

   Now, if S1 S3 are significantly more loaded than S2 S4, A1 may route
   some C1 traffic to A2.  This is non optimal path but allows a better
   load balancing between the servers.  To achieve this, A1 needs to
   receive some load info from A2 about S2/S4 load.






Campbell, et al.       Expires September 19, 2016              [Page 18]


Internet-Draft              Abbreviated Title                 March 2016


              -----S3
             /
     C1----A1------S1
           |
           |
           |
     C2----A2------S2
             \
              ---- S4


                         Figure 10: Linked Agents

A.5.  Shared Server Pools

   Figure 11 is similar to Figure 9, except that instead of a link
   between agents, each agent is linked to all servers.  (The links to
   each set of servers should be interpreted as a link to each server.
   The links are not shown separately due to the limitations of ASCII
   art.)

   In this scenario, each agent can select among all of the servers,
   based on the load information from the servers.  The client need only
   be concerned with the load information of the agents.


       ---A1---S[1], S[2]...S[p]
      /     \ /
     C       x
      \     / \
       ---A2---S[p+1], S[p+2] ...S[n]


                      Figure 11: Shared Server Pools

A.6.  Agent Chains

   The scenario in Figure 12 is similar to that of Figure 8, except
   that, instead of the client possibly needing to select an agent that
   can route requests to the least loaded server, in this case A1 and A2
   need to make similar decisions when selecting between A3 or A4.  As
   the former scenario, this could be mitigated if A3 and A4 aggregate
   upstream loads into the load information they report downstream.








Campbell, et al.       Expires September 19, 2016              [Page 19]


Internet-Draft              Abbreviated Title                 March 2016


       ---A1---A3----S[1], S[2]...S[p]
      /   | \ /
     C    |  x
      \   | / \
       ---A2---A4----S[p+1], S[p+2] ...S[n]


                          Figure 12: Agent Chains

A.7.  Fully Meshed Layers

   Figure 13 extends the scenario in Figure 11 by adding an extra layer
   of agents.  But since each layer of nodes can reach any node in the
   next layer, each node only needs to consider the load of its next-hop
   peer.

       ---A1---A3---S[1], S[2]...S[p]
      /   | \ / |\ /
     C    |  x  | x
      \   | / \ |/ \
       ---A2---A4---S[p+1], S[p+2] ...S[n]


                           Figure 13: Full Mesh

A.8.  Partitions

   A Diameter network with multiple servers is said to be "partitioned"
   when only a subset of available servers can serve a particular realm-
   routed request.  For example, one group of servers may handle users
   whose names start with "A" through "M", and another group may handle
   "N" through "Z".

   In such a partitioned network, nodes cannot load-balance requests
   across partitions, since not all servers can handle the request.  A
   client, or an intermediate agent, may still be able to load-balance
   between servers inside a partition.

A.9.  Active-Standby Nodes

   The previous scenarios assume that traffic can be load balanced among
   all peers that are eligible to handle a request.  That is, the peers
   operate in an "active-active" configuration.  In an "active-standby"
   configuration, traffic would be load-balanced among active peers.
   Requests would only be sent to peers in a "standby" state if the
   active peers became unavailable.  For example, requests might be
   diverted to a stand-by peer if one or more active peers becomes
   overloaded.



Campbell, et al.       Expires September 19, 2016              [Page 20]


Internet-Draft              Abbreviated Title                 March 2016


A.10.  Addition and removal of Nodes

   When a Diameter node is added, the new node will start by advertising
   its load.  Downstream nodes will need to factor the new load
   information into load balancing decisions.  The downstream nodes
   should attempt to ensure a smooth increase of the traffic to the new
   node, avoiding an immediate spike of traffic to the new node.  The
   handling of such a smooth increase is implementation specific but it
   can rely on the evolution of load information received from the new
   node and from the other nodes.

   When removing a node in a controlled way (e.g. for maintenance
   purpose, so outside a failure case), it might be appropriate to
   progressively reduce the traffic to this node by routing traffic to
   other nodes.  Simple load information (load percentage) would be not
   sufficient.  The handling of the node removal is implementation
   specific but it can rely on the evolution of the load information
   received from the node to be removed

Authors' Addresses

   Ben Campbell
   Oracle
   7460 Warren Parkway # 300
   Frisco, Texas  75034
   USA

   Email: ben@nostrum.com


   Steve Donovan (editor)
   Oracle
   7460 Warren Parkway # 300
   Frisco, Texas  75034
   United States

   Email: srdonovan@usdonovans.com


   Jean-Jacques Trottin
   Nokia
   Route de Villejust
   91620 Nozay
   France

   Email: jean-jacques.trottin@nokia.com





Campbell, et al.       Expires September 19, 2016              [Page 21]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/