Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview

["dime issue tracker" <[e-mail]>]

#41: Need better overview

Changes (by [e-mail]):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The following wording for section 3.0 was added.  A new issue will be
 opened to reflect that the remainder of section 3 needs to be made
 consistent with the current state of the DIOC solution.

 -----

    The Diameter Overload Information Conveyance (DOIC) mechanism allows
    Diameter nodes to request other nodes to perform overload abatement
    actions, that is, actions to reduce the load offered to the
    overloaded node.

    A Diameter node that supports DOIC is known as a "DOIC endpoint".
    Any Diameter node can act as a DOIC endpoint, including clients,
    servers, and agents.  DOIC endpoints are further divided into
    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
    overload abatement by sending an Overload Report (OLR) to one or more
    reacting nodes.

    A reacting node consumes OLRs, and performs whatever actions are
    needed to fulfill the requests.  A Reporting node may report overload
    on its own behalf, or on behalf of other (typically upstream) nodes.
    Likewise, a reacting node may perform overload abatement on its own
    behalf, or on behalf of other (typically downstream) nodes.

    A node's role as a DOIC endpoint is independent of its Diameter role.
    For example, Diameter relay and proxy agents may act as DOIC
    endpoints, even though they are not endpoints in the Diameter sense.
    Since Diameter enables bi-directional applications, where Diameter
    servers can send requests towards Diameter clients, a given Diameter
    node can simultaneously act as a reporting node and reacting node.

    Likewise, an relay or proxy agent may act as a reacting node from the
    perspective of upstream nodes, and a reporting node from the
    perspective of downstream nodes.

    DOIC endpoints do not generate new messages to carry DOIC related
    information.  Rather, they "piggyback" DOIC information over existing
    Diameter messages by inserting new AVPs into existing Diameter
    requests and responses.  Nodes indicate support for DOIC, and any
    needed DOIC parameters by inserting an OC_Supported_Features AVP
    (Section 4.1) into existing requests and responses.  Reporting nodes
    send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

    A given OLR applies to the Diameter realm and application of the
    Diameter message that carries it.  If a reporting node supports more
    than one realm and/or application, it reports independently for each
    combination of realm and application.  Similarly, OC-Feature-Vector
    AVPs apply to the realm and application of the enclosing message.
    This implies that a node may support DOIC for one application and/or
    realm, but not another, and may indicate different DOIC parameters
    for each application and realm for which it supports DOIC.

    Reacting nodes perform overload abatement according to an agreed-upon
    abatement algorithm.  An abatement algorithm defines the meaning of
    the parameters of an OLR, and the procedures required for overload
    abatement.  This document specifies a single must-support algorithm,
    namely the "loss" algorithm [ref?].  Future specifications may
    introduce new algorithms.

    Overload conditions may vary in scope.  For example, a single
    Diameter node may be overloaded, in which case reacting nodes may
    reasonably attempt to send throttled requests to other destinations
    or via other agents.  On the other hand, an entire Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an entire realm.

    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of reporting and reacting nodes, as long as those agents pass
    unknown AVPs through unmolested.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.  Documents
    that introduce new report types MUST describe any limitations on
    their use across non-supporting agents.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  [e-mail]        |  [e-mail]
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/41#comment:1>
dime <http://tools.ietf.org/wg/dime/>