Architectural Considerations for Diameter Load Information
draft-campbell-dime-load-considerations-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2014-10-25
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Additional URLs
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                              B. Campbell
Internet-Draft                                                    Oracle
Intended status: Informational                          October 25, 2014
Expires: April 28, 2015

       Architectural Considerations for Diameter Load Information
               draft-campbell-dime-load-considerations-00

Abstract

   RFC 7068 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) solution describes a mechanism
   meeting most of the requirements, but does not currently include the
   ability to send load.  This document explores some architectural
   considerations for a mechanism 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 April 28, 2015.

Copyright Notice

   Copyright (c) 2014 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
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Campbell                 Expires April 28, 2015                 [Page 1]
Internet-Draft              Abbreviated Title               October 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Differences between Load and Overload information . . . . . .   3
   3.  How is Load Information Used? . . . . . . . . . . . . . . . .   4
   4.  Piggy-Backing vs a Dedicated Application. . . . . . . . . . .   4
   5.  Which Nodes Exchange Load Information?  . . . . . . . . . . .   5
   6.  Scope of Load Information . . . . . . . . . . . . . . . . . .   6
   7.  Load Information Semantics  . . . . . . . . . . . . . . . . .   7
   8.  Is Negotiation of Support Needed? . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [RFC7068] describes requirements for Overload Control in Diameter
   [RFC6733].  At the time of this writing, the DIME working group is
   working on the Diameter Overload Information Conveyance (DOIC)
   mechanism.  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 diverts 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 RFC 7068 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 defer load information conveyance to a DOIC extension or a
   separate mechanism.

Campbell                 Expires April 28, 2015                 [Page 2]
Internet-Draft              Abbreviated Title               October 2014

   This document describes some high level architectural decisions that
   the working group will need to consider in order to solve the load-
Show full document text