Internet DRAFT - draft-donovan-doic-agent-cases
draft-donovan-doic-agent-cases
Internet Engineering Task Force S. Donovan
Internet-Draft B. Campbell
Intended status: Informational Oracle
Expires: January 4, 2015 July 3, 2014
Analysis of Agent Use Cases for Diameter Overload Information Conveyance
(DOIC)
draft-donovan-doic-agent-cases-00
Abstract
The Diameter Overload Information Conveyance (DOIC) solution
describes a mechanism for exchanging information about Diameter
Overload among Diameter nodes. A DOIC node is a Diameter node that
acts as either a reporting node are a reacting node. A reporting
node originates overload reports, requesting reacting nodes to reduce
the amount of traffic sent. DOIC allows Diameter agents to act as
reporting nodes, reacting nodes, or both, but does not describe agent
behavior. This document explores several use cases for agents to
participate in overload control, and makes recommendations for
certain agent behaviors to be added to DOIC.
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 January 4, 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
Donovan & Campbell Expires January 4, 2015 [Page 1]
Internet-Draft Abbreviated Title July 2014
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 3
2. Deployment Architectures . . . . . . . . . . . . . . . . . . 4
3. Diameter Routing . . . . . . . . . . . . . . . . . . . . . . 5
4. Overload Abatement Methods . . . . . . . . . . . . . . . . . 6
5. DOIC Use Cases . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Simple Agent . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Capability Announcement . . . . . . . . . . . . . . . 9
5.1.2. Overload Report Handling . . . . . . . . . . . . . . 11
5.1.3. DOIC Specification Impacts . . . . . . . . . . . . . 17
5.2. Mixed Capabilities . . . . . . . . . . . . . . . . . . . 17
5.2.1. Capability Announcement . . . . . . . . . . . . . . . 17
5.2.2. Mixed Abatement Algorithms . . . . . . . . . . . . . 18
5.2.3. DOIC Specification Impacts . . . . . . . . . . . . . 20
5.3. Non-Supporting Nodes . . . . . . . . . . . . . . . . . . 20
5.3.1. Non-Supporting Transaction Client . . . . . . . . . . 20
5.3.2. Non-supporting Transaction Server . . . . . . . . . . 24
5.3.3. Non-Supporting Agent . . . . . . . . . . . . . . . . 26
5.3.4. DOIC Specification Impacts . . . . . . . . . . . . . 27
5.4. Inter Domain Authentication . . . . . . . . . . . . . . . 27
5.4.1. DOIC Specification Impacts . . . . . . . . . . . . . 29
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. General Recommendations . . . . . . . . . . . . . . . . . 30
6.2. Agent Behavior Recommendations . . . . . . . . . . . . . 30
6.2.1. Capabilites Exchange Behaviors . . . . . . . . . . . 30
6.2.2. Overload Report Behaviors . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
The Diameter Overload Information Conveyance (DOIC)
[I-D.ietf-dime-ovli] solution describes a mechanism for exchanging
diameter overload information among Diameter nodes. DOIC defines the
concept of a DOIC endpoint (referred to as a "DOIC node" in this
document.) A DOIC node is a Diameter node that acts as either a
Donovan & Campbell Expires January 4, 2015 [Page 2]
Internet-Draft Abbreviated Title July 2014
reporting node or a reacting node. A reporting node originates
overload reports, requesting reacting nodes to reduce the offered
load. An overload report has a "type". The type of overload report
determines the scope of the request for traffic reduction, and
possibly other semantics.
DOIC nodes do not necessarily correspond to Diameter clients and
servers. Any Diameter node that supports DOIC is a DOIC node. This
includes Diameter agents, as well as Diameter clients and servers.
However, DOIC does not currently describe how agents should behave as
part of an overload control solution. This document explores several
use cases for agents to participate in overload control, and makes
recommendations for certain agent behaviors to be added to DOIC.
1.1. Terminology and Abbreviations
Diameter Node: A Diameter client, agent or server.
DOIC node: A Diameter node that supports DOIC. A DOIC node can
simultaneously be both a reacting node and a reporting node.
Reacting node: A DOIC node that can receive overload reports from a
reporting node and ensures that the overload reports are honored.
Reporting node: A DOIC node that can send overload reports,
requesting overload abatement.
Abating node: A reacting node that directly performs overload
abatement.
Transaction Client (TC) A diameter node that originates a Diameter
request. This is distinct from "Diameter Client" as used in RFC
6733. Note that a Diameter Server acts as a TC if and when it
originates a request towards a Diameter Client.
TransactionServer (TS) A diameter node that consumes a Diameter
request, and responds with a Diameter answer. This is distinct
from "Diameter Server" as used in RFC 6733. Note that a Diameter
Client acts as a TS if and when it answers a request sent by a
Diameter Server.
Client Application The application that uses Diameter for various
Authentication, Authorization, and/or Accounting (AAA) functions.
For example, a Network Access Server (NAS) performs certain
network attachment services, detachment services, packet
forwarding, etc. These are collectively the NAS client
application, which depends on Diameter for AAA services.
Donovan & Campbell Expires January 4, 2015 [Page 3]
Internet-Draft Abbreviated Title July 2014
Overload Abatement: Actions taken by a reacting node to reduce the
load offered to an overloaded Diameter node. The specific actions
required to perform overload abatement are described by the DOIC
algorithm. Overload abatement actions may involve local traffic
reduction, or delegation of actions towards the client. Local
traffic reduction can be achieved by either throttling a request
or routing a request to a different destination.
Throttling Overload abatement through the rejection of some number
of requests. Throttling at an agent requires the agent to reject
requests with appropriate error codes. Throttling at a
transaction client requires the client to indicate appropriate
errors to the client application
Diversion Overload abatement through the routing of some number of
requests away from an overloaded node towards one or more
appropriate nodes that are less-overloaded.
2. Deployment Architectures
This section outlines the deployment architectures used to determine
agent related Diameter DOIC requirements.
These deployment architectures include the use of Diameter agents to
route Diameter requests between Diameter clients and Diameter
servers.
In all cases, a small number of client and server nodes are shown for
simplicity. Adding additional clients and/or servers does not change
the fundamental characteristics of the deployments.
Figure 1 shows an architecture with a single agent sitting between
Diameter clients and Diameter servers.
+--+ +--+
|C1|----- -----|S1|
+--+ \+--+/ +--+
|A1|
+--+ /+--+\ +--+
|C2|----- -----|S2|
+--+ +--+
Figure 1
Donovan & Campbell Expires January 4, 2015 [Page 4]
Internet-Draft Abbreviated Title July 2014
Figure 2 shows an architecture with multiple agents sitting between
Diameter clients and Diameter servers.
+--+ +--+
|C1|----- -----|S1|
+--+ \+--+ +--+/ +--+
|A1|------|A2|
+--+ /+--+ +--+\ +--+
|C2|----- -----|S2|
+--+ +--+
Figure 2
This document focuses on use cases that involve agents, and does not
therefore include scenarios with no agent(s) between the transaction
client and transaction server. It is, however, important that any
changes to the DOIC solution introduced to support networks that
contain agents also work when there is no agent sitting between
Diameter clients and servers.
3. Diameter Routing
Diameter supports two primary methods [RFC6733] for nodes to select
the next hop for a request . Normally, Diameter nodes base peer-
selection on the Destination-Realm and Application-Id AVP values.
That is, they select a next hop from their Diameter peer table entry
that matches the realm and application of the request. For the sake
of this analysis, we refer to requests routed by this method as
"realm-routed requests"
A Diameter TC may also control the final destination of a request by
inserting a Destination-Host AVP. When a node forwards a request
that includes Destination-Host, it checks to see if it has a matching
Diameter identity in its peer table. If so, it forwards the request
to that peer. Otherwise, it follows the normal peer-selection for
the realm and application. We refer to requests routed this way as
"host-routed requests".
In general, throttling (Section 4) is the the only abatement
technique that works for host-routed requests. Diversion (Section 4)
is typically not possible, since only a single TS can handle any
given request.
There may be some exceptions to this rule. For example, a node
might have multiple peer table entries that share the same
Donovan & Campbell Expires January 4, 2015 [Page 5]
Internet-Draft Abbreviated Title July 2014
Diameter Identity. A node might map Diameter identities in a way
that results in multiple next-hop destinations for a given
Destination-Host value.
On the other hand, diversion is often useful for abating realm-routed
traffic. Since realm-routed requests are not bound to a particular
TS, it is often be possible to divert a number of them to other
servers that are less overloaded.
4. Overload Abatement Methods
When a Diameter node becomes overloaded, there often must be a
reduction of the number of both realm-routed and host-routed
requests, in order to have the desired reduction of the overall
offered-load. We refer to this reductions as "Overload Abatement".
There are two ways to perform overload abatement. The first is to
reject some number of Diameter requests, also known as "throttling".
When a TC throttles traffic, it rejects or defers certain client
application requests, as appropriate for the client application.
When an agent or TS throttles traffic, it rejects Diameter requests
with an appropriate error code, so that the TC can behave correctly
at the client application layer.
The second way to abate overload is to move some number of requests
from an overloaded node to one or more eligible nodes that are less
overloaded. For the purposes of this draft, we refer to this
abatement method as "Diversion".
Either method, separately or in combination, continue over the
duration of the overload condition.
There are a few architectural principles that should be considered
when building Diameter networks to be resilient to overload, or when
deploying DOIC into existing Diameter network.
All things being equal, diversion is better than throttling.
Diversion potentially allows more requests to succeed, which will
almost always have less negative impact on the client application.
However, there are situations where diversion is not possible. For
example, diversion is usually not possible for host-routed requests
(see Section 3). Diversion may not be helpful if all potential
destinations are overloaded. If proprietary load balancing
mechanisms are in use, diversion for DOIC purposes may be redundant
with those mechanisms.
If diversion is performed, the diversion should occur as close as
possible to the TS, but not at the TS itself (since this would defeat
Donovan & Campbell Expires January 4, 2015 [Page 6]
Internet-Draft Abbreviated Title July 2014
the point of overload abatement.) Diversion should optimally occur
at an immediate peer to the TS; that is, a node that shares a direct
transport connection with the TS. A directly connected peer will
have the most knowledge of alternative destinations and their current
loads. If nodes further from the TS attempt to diversion, topology
knowledge and overload state knowledge must be pushed further down
the chain. Even then, a node usually cannot control how a realm-
routed request might be routed upstream of the immediate peer.
Throttling should occur at, or as close as possible, to the TC. The
TC has the best knowledge of the client application and its current
state. The TC can choose to reject requests that have the lease
impact on the client application, or provide the most effect for
traffic reduction over time. Furthermore, throttling at the TC
completely avoids Diameter overhead for rejected requests. Each
additional hop traversed by requests that will eventually be rejected
increases the impact of those requests.
5. DOIC Use Cases
This section outlines example use cases involving agents. Each of
these use cases is evaluated with the goal of identifying any
required changes to [I-D.ietf-dime-ovli] needed to support the use
case.
The following is the list of use cases considered. This is not an
exhaustive list of DOIC use cases but is rather a list of use cases
identified by the authors as being impacted by the presence of agents
in the deployment.
o Simple Agent - Overload capability announcement and overload
report handling in a deployment with a single agent as illustrated
in Figure 1. In this case all Diameter nodes are assumed to
support DOIC. This use case is discussed in Section 5.1.
This use case includes four sub-cases:
1. OC Capability Announcement where the TC and Agent support the
same OC capabilities.
2. Host overload report handling for host-routed requests. This
case illustrates throttling of host-routed requests at the
transaction client and throttling of realm-routed reqeusts at
the agent.
3. Host overload report handling realm-routed requests when there
is a second TS to which requests can be diverted when one of
the servers is in an overload state.
Donovan & Campbell Expires January 4, 2015 [Page 7]
Internet-Draft Abbreviated Title July 2014
4. Multiple host overload reports resulting in a realm overload
report.
o Mixed Capabilities - Overload capability announcement and overload
report handling in deployments where agents support capabilities
that are not included in the set of capabilities advertised by
reacting nodes. This use case is discussed in Section 5.2.
This use case illustrates one scenario where an agent consumes an
overload report and replaces it with a new overload report of a
different type.
o Non-supporting DOIC nodes - Agent behavior in the face of Diameter
nodes that do not support the DOIC solution. These use cases are
addressed in Section 5.3. There are four sub-use cases that are
addressed:
* Non-supporting TC. In this case a DOIC supporting agent
handles overload abatement on behalf of the non-supporting TC.
An agent or a reporting node can detect if there is a reacting
node in the path of a request by the presence of the OC-
Supported-Features AVP in the request message. This use case
is discussed in Section 5.3.1.
* Non-supporting TS. In this case a DOIC supporting agent may
act as the reporting node on behalf of the TS. In this case a
DOIC supporting agent can detect if there is a reporting node
in the path of the transaction by the presence of the OC-
Supported-Features AVP in the answer message for the
transaction. This use case is discussed in Section 5.3.2.
* Non-supporting agent between the TC and a supporting agent.
* Non-supporting agent between a supporting agent and the TS. In
this case, the agent that supports DOIC cannot reliably divert
requests as a result of a host report. This use case is
discussed in Section 5.3.3.
This use case illustrates when this deployment scenario is not
recommended.
o Inter domain or untrusted node authorization.
This use case illustrates one case where a node needs to know if
an OC-S-F AVP came from a supported peer, or was forwarded by a
non-supporting peer. This use case is discussed in Section 5.4.
Donovan & Campbell Expires January 4, 2015 [Page 8]
Internet-Draft Abbreviated Title July 2014
5.1. Simple Agent
This section addresses overload capability announcement and overload
report handling in a deployment with a single agent as illustrated in
Figure 1.
This use case assumes that all nodes support DOIC and that all nodes
support the same set of overload features.
This use case includes four sub-cases:
1. OC Capability Announcement where the TC and Agent support the
same OC capabilities.
2. Host overload report handling for host-routed requests. This
case illustrates throttling of host-routed requests at the
transaction client and throttling of realm-routed reqeusts at the
agent.
3. Host overload report handling realm-routed requests when there is
a second TS to which requests can be diverted when one of the
servers is in an overload state.
4. Multiple host overload reports resulting in a realm overload
report.
5.1.1. Capability Announcement
This section explores capability announcement for the simple agent
use case.
This use case assumes that the capabilities supported by the TC and
those supported by the agent are the same. (A scenario with
differing capabilities is supported in discussed in Section 5.2.)
Figure 3 shows the message flow for this use case.
The nomenclature OC-S-F:x is short for OC-Supported-Feature with the
":x" indicating the Diameter node that inserted the AVP into the
message.
Donovan & Campbell Expires January 4, 2015 [Page 9]
Internet-Draft Abbreviated Title July 2014
+--+ +-+ +--+
|TC| |A| |TS|
+--+ +-+ +--+
| | |
1> |-- xxR OC-S-F:C---------->| |
| | |
2> | |-- xxR OC-S-F:C---------->|
| | |
3> | |<---------- xxA OC-S-F:S--|
| | |
4> |<-------- xxA OC-S-F:S----| |
| | |
Figure 3
1. The transaction client (TC) originates a request. The TC
supports DOIC and, as such, includes the OC-Supported-Features
AVP in all requests. The OC-S-F AVP contains the clients
capabilities.
2. The agent inspects the OC-S-F AVP and determines that the agent
supports the same set of OC features. The agent relays the
request unchanged to the server.
Note: It is an open question whether the agent needs to
include an indication that it also supports DOIC or if
attribution of the OC-S-F is needed. One could also question
whether the agent forwarded OC-S-F:C unchanged, rather than
consuming the OC-S-F, and inserted another identical one.
This is likely a purely philosophical difference, but might
impact the inter-domain authorization use case (Section 5.4).
3. The transaction server (TS), acting as the reporting node,
inspects the OC-S-F AVP in the request and generates an OC-S-F to
be included in the answer message. This is done according to the
behavior defined in the DOIC specification [I-D.ietf-dime-ovli].
4. The agent relays the answer message unchanged.
The presence of the OC-S-F header in the answer message indicates
to the TC that it needs to be prepared for overload reports in
subsequent requests of the same type.
With the loss algorithm defined in [I-D.ietf-dime-ovli] there
is no explicit action required of the TC. Stateful abatement
algorithms will likely require action to be taken by the TC to
be able to handle subsequent overload reports.
Donovan & Campbell Expires January 4, 2015 [Page 10]
Internet-Draft Abbreviated Title July 2014
5.1.2. Overload Report Handling
This section addresses overload report handling in a deployment with
a single agent as illustrated in Figure 1.
The following three scenarios are illustrated:
o Figure 4 shows a message flow illustrating handling of host
reports for host-routed requests and realm-routed requests when
there is a single TS.
o Figure 5 shows the handling of realm-routed requests when there is
a second TS to which requests can be diverted when one of the
servers is in an overload state.
o Figure 6 illustrates the agents behavior when it has received a
host report from all servers. In this case the agent generates a
Realm report. This is only possible when the agent knows the
overload state of all TSs for the given realm and application.
In these message flows, "xxR" indicates a Diameter request, and "xxA"
indicates an answer. "HR" under a request indicates that the request
is host-routed. "RR" indicates the request is realm-routed. If
neither is present for a request, then it can be either host or realm
routed. "OLR:Host" indicates an overload report of type Host.
"OLR:Realm" indicates an overload report of type Realm.
+-+ +-+ +-+
|C| |A| |S|
+-+ +-+ +-+
| | |
1> |-- xxR OC-S-F:C----->| |
| | |
2> | |-- xxR OC-S-F:C----->|
| | |
3> | |<----- xxA OC-S-F:S--|
| | OLR:Host |
4> |<--- xxA OC-S-F:S----| |
| OLR:Host | |
| | |
5> |-- xxR OC-S-F:C---X | |
| HR | |
| | |
6> |-- xxR OC-S-F:C----->| |
| HR | |
| | |
7> | |-- xxR OC-S-F:C----->|
Donovan & Campbell Expires January 4, 2015 [Page 11]
Internet-Draft Abbreviated Title July 2014
| | |
| | |
8> | |<----- xxA OC-S-F:S--|
| | OLR:Host |
| | |
9> |<--- xxA OC-S-F:S----| |
| OLR:Host | |
| | |
10>|-- xxR OC-S-F:C----->| |
| RR | |
11>| |-- xxR OC-S-F:C---X |
| | RR |
| | |
12>|<--- xxA Throttled---| |
| | |
| | |
13>|-- xxR OC-S-F:C----->| |
| RR | |
| | |
14>| |-- xxR OC-S-F:C----->|
| | RR |
| | |
15>| |<----- xxA OC-S-F:S--|
| | OLR:Host |
| | |
16>|<--- xxA OC-S-F:S----| |
| OLR:Host | |
| | |
Figure 4
1. Same as in Figure 3.
2. Same as in Figure 3.
3. S, acting as a reporting node, has determined that it needs to
request a reduction in traffic. S includes the OC-S-F AVP per
[I-D.ietf-dime-ovli], and selects the loss algorithm for the
included report. S also includes the OC-OLR AVP to indicate the
requested reduction in traffic.
4. A saves the overload state of S based on the OC-OLR AVP. A will
use this overload state for handling of future realm routed
requests.
This behavior is not yet specified in the DOIC specification.
It is based on the principle that only nodes with a direct
Donovan & Campbell Expires January 4, 2015 [Page 12]
Internet-Draft Abbreviated Title July 2014
transport connection to an overloaded host should throttle
those requests as other nodes earlier in the requests path do
not have the topology knowledge to know if diversion of the
request would have been successful.
A relays the answer message without change to OC-S-F or OC-OLR.
Upon receipt of the answer, C saves overload state based on the
overload report.
5. C invokes the "loss" algorithm on host-routed requests. This
step illustrates a host-routed request that is rejected locally
by C due to throttling. C gives application appropriate
feedback to the client application.
6. This step represents a Host-routed requests that survived
abatement. Such requests are handled the same as if there where
no overload report for the host to which the request is routed.
7. A relays the request based on the included Destination-Host AVP.
8. A generates an answer which includes the OC-S-F AVP and OC-OLR
AVP.
9. If the OC-OLR is new, then A updates the overload state
associated with the report. A relays the answer without change
to OC-S-F or OC-OLR.
C determines if the OC-OLR is new. If so, C updates its locally
stored overload state for S.
10. C originates a realm-routed request. C does not apply abatement
to this request since it does not match any locally stored
overload state (in this scenario, a realm overload report has
not yet been sent.)
11. A determines that there is overload state associated with this
request (the host report received from S). A uses this overload
state as input to routing decisions for the request. In this
case it is assumed that there is no alternative route to divert
request toward and, as such, A applies throttling, and rejects
the request.
12. A generates an error response indicating that the request was
throttled and should not be retried.
13. C originates another realm-routed request.
Donovan & Campbell Expires January 4, 2015 [Page 13]
Internet-Draft Abbreviated Title July 2014
14. A determines that there is overload state associated with this
request (the host report received from S). A uses this overload
state as input to routing decisions for the request. This
request survives abatement and is routed to S.
15. S generates an answer message.
16. A relays the answer.
The following shows the case of host overload report handling of
realm-routed requests when there is a second TS to which requests can
be diverted when one of the servers is in an overload state.
+-+ +-+ +--+ +--+
|C| |A| |S1| |S2|
+-+ +-+ +--+ +--+
| | | |
1> |-- xxR OC-S-F:C----->| | |
| | | |
2> | |-- xxR OC-S-F:C----->| |
| | | |
3> | |<----- xxA OC-S-F:S--| |
| | OLR:Host | |
4> |<--- xxA OC-S-F:S----| | |
| OLR:Host | | |
| | | |
5> |-- xxR OC-S-F:C----->| | |
| RR | | |
6> | |-- xxR OC-S-F:C--------------------------->|
| | RR | |
| | | |
7> | |<--------------------------- xxA OC-S-F:S--|
| | | |
8> |<--- xxA OC-S-F:S----| | |
| | | |
Figure 5
1. Same as in Figure 3.
2. Same as in Figure 3.
3. Same as in Figure 4.
4. Same as in Figure 4.
Donovan & Campbell Expires January 4, 2015 [Page 14]
Internet-Draft Abbreviated Title July 2014
5. C originates a realm-routed request. C does not apply overload
abatement to this request as it does not match any locally stored
overload state (the assumption for this scenario is that a realm
overload report has not yet been sent.)
6. A determines that there is overload state associated with this
request (the host report received from S1). A uses this overload
state as input to routing decisions for the request. In this
case, it is assumed that the request would have been normally
routed to S1 but is instead routed to S2 as a result of the
overload report.
7. S2 generates an answer message.
8. A relays the answer.
The following illustrates the agents behavior when it has received a
host report from all servers. In this case the agent generates a
Realm report. This is only possible when the agent knows the
overload state of all TSs for the given realm and application.
Donovan & Campbell Expires January 4, 2015 [Page 15]
Internet-Draft Abbreviated Title July 2014
+-+ +-+ +--+ +--+
|C| |A| |S1| |S2|
+-+ +-+ +--+ +--+
| | | |
1> |-- xxR OC-S-F:C----->| | |
| | | |
2> | |-- xxR OC-S-F:C----->| |
| | | |
| | | |
3> | |<----- xxA OC-S-F:S--| |
| | OLR:Host | |
4> |<--- xxA OC-S-F:S----| | |
| OLR:Host | | |
| | | |
5> |-- xxR OC-S-F:C----->| | |
| RR | | |
| | | |
6> | |-- xxR OC-S-F:C--------------------------->|
| | | |
7> | |<--------------------------- xxA OC-S-F:S--|
| | | OLR:Host |
8> |<--- xxA OC-S-F:S----| | |
| OLR:Host | | |
| OLR:Realm | | |
| | | |
Figure 6
1. Same as in Figure 4.
2. Same as in Figure 4.
3. Same as in Figure 4.
4. Same as in Figure 4.
5. Same as in Figure 4.
6. Same as in Figure 4.
7. Same as in Figure 4, with the addition that S2 also includes an
overload report in the answer message.
8. A determines that the available capacity of all servers in the
realm has been reduced to the degree that it must generate a
realm report. A adds this report to the answer message, in
Donovan & Campbell Expires January 4, 2015 [Page 16]
Internet-Draft Abbreviated Title July 2014
addition to the existing host report from S2 . C saves overload
state associated with the new Realm overload report. For the
duration of the realm report the client performs the requested
abatement on realm-routed requests.
5.1.3. DOIC Specification Impacts
The following is a list of behavior that needs to be reflected in the
DOIC specification.
o There can be multiple abating nodes for a single overload report.
In this use case, A TC handles abatement of host-routed requests.
An agent with a direct transport connection to an overloaded node
handles abatement of realm-routed requests that would normally be
routed to that node.
o
Note: It is also possible that an agent will handle abatement
of host-routed requests, as illustrated in Section 5.3.1.
o Syntax for the OC-OLR AVP must support multiple OC-OLR AVPs in
answer messages.
o The working group must define a Diameter-Throttled error response
that indicates that the request was rejected due to overload and
that the request should not be retried.
5.2. Mixed Capabilities
This use case explores the impact of having a different set of DOIC
capabilities supported by the TC and one or more agents in the path
of the request.
5.2.1. Capability Announcement
Figure 7 illustrates the case. In this figure, "OC-S-F:C" indicates
it carries the set of capabilities supported by C. "OC-S-FC:AC"
indicates the set of capabilities that A declares to S. "OC-S-FC:S"
indicates S's response to the AC set of capabilities. OC-S-FC:AS
indicates A's modification to the capabilities selected by S. This
is needed in the case where S's capabilities are not compatible with
C's.
"OC-S-FC:AC" could indicate the merged capabilities of C and A,
based on local policies at A. For example, A could indicate a
union or intersection of the its local capabilities with those of
C. Alternately, it A could declare an entirely different set of
Donovan & Campbell Expires January 4, 2015 [Page 17]
Internet-Draft Abbreviated Title July 2014
capabilities towards S. If the capabilites selected between A and
S differ from those selected between C and A, A becomes
responsible for mapping any overload information it receives from
S to fit the capabilities it negotiated with C.
+-+ +-+ +-+
|C| |A| |S|
+-+ +-+ +-+
| | |
1> |-- xxR OC-S-F:C---------->| |
| | |
2> | |-- xxR OC-S-F:AC--------->|
| | |
3> | |<---------- xxA OC-S-F:S--|
| | |
4> |<-------- xxA OC-S-F:AS---| |
| | |
Figure 7
1. C originates a request including OC-S-F:C, indicating the DOIC
features supported by C.
2. A inspects OC-S-F:C and determines that A supports features not
included. A relays the request, replacing OC-S-F:C APV with an
OC-S-F:AC.
3. S responds to the set of advertised features with the OC-S-F:S
AVP. There is no change in S's behavior beyond what is specified
in [I-D.ietf-dime-ovli] and any other extensions documenting the
features in the received OC-S-F AVP.
4. A inspects OC-S-F:S. If necessary A replaces OC-S-F:S with OC-
S-F:AS'.
Section 5.2.2 illustrates one example were A needs to OC-S-F:S
with OC-S-F:AS'.
5.2.2. Mixed Abatement Algorithms
Figure 8 illustrates one specific type of mixed capabilities. In
this case, C only supports the loss abatement algorithm, A supports
both loss and rate and S selects rate.
Donovan & Campbell Expires January 4, 2015 [Page 18]
Internet-Draft Abbreviated Title July 2014
+-+ +-+ +-+
|C| |A| |S|
+-+ +-+ +-+
| | |
1> |-- xxR OC-S-F:C---------->| |
| loss | |
| | |
2> | |-- xxR OC-S-F:AC--------->|
| | loss, rate |
| | |
3> | |<---------- xxA OC-S-F:S--|
| | rate |
| | OC-OLR:S |
| | rate |
| | |
4> |<-------- xxA OC-S-F:AS---| |
| loss | |
| OC-OLR:A | |
| loss | |
Figure 8
1. C originates a request with OC-S-F:C, indicating support for only
the "loss" algorithm.
2. A inspects OC-S-F:C and determines it needs to advertise support
for additional capabilities. A removes OC-S-F:C and inserts OC-
S-F:AC, indicating support for both the "loss" and "rate"
algorithms. A stores the state from OC-S-F:C to be referenced
when it receives the associated answer.
3. S responds with OC-S-F:S, indicating that the rate algorithm will
be used for overload reports, and OC-OLR:rate, indicating an
overload condition with a specific requested rate-limit.
4. A recalls that C did not indicate support the rate algorithm and
replaces OC-S-F:S with OC-S-F:AS, which indicates that the loss
abatement algorithm will be used for overload reports sent to C.
A must enforce the rate limit locally, so it removes OC-OLR:rate.
If C's offered load exceeds what A can handle without violating
the requested rate-limit, it inserts OC-OLR:A, requesting a
traffic reduction using the "loss" algorithm.
This flow assumes that A is able to handle rate-based overload
reports, even though the TC cannot. How this is done in practice is
implementation specific. In this example, A applies local rate-
Donovan & Campbell Expires January 4, 2015 [Page 19]
Internet-Draft Abbreviated Title July 2014
limiting, but send loss-based OLRs to C if A cannot handle C's
offered load without violating the rate-limit.
If A chose to apply local throttling to enforce the rate limit,
instead of sending load-based OLRs back to the TC, the scenario would
be closer to that for a TC that did not support DOIC (Section 5.3.1).
5.2.3. DOIC Specification Impacts
An agent must have the ability to replace the OC-S-F AVP in request
messages.
An agent must have the ability to remove or replace the OC-S-F AVP in
answer messages.
An agent must have the ability to remove or replace the OC-OLR AVP in
answer messages.
5.3. Non-Supporting Nodes
This section outlines the impact of agent based scenarios where there
is a node that does not support DOIC in the path of a request. There
are five variations of this use case:
1. Non-supporting TC.
2. Non-supporting TS.
3. Non-supporting agent between the TC and a DOIC agent.
4. Non-supporting agent between a DOIC agent and the TS.
5. Non-supporting agent between DOIC agents.
5.3.1. Non-Supporting Transaction Client
This section outlines the handling of non-supporting transaction
client.
This use case is illustrated in Figure 9. In this case assume that
C1 supports DOIC and C2 does not.
Donovan & Campbell Expires January 4, 2015 [Page 20]
Internet-Draft Abbreviated Title July 2014
+--+ +--+
|C1|----- -----|S1|
+--+ \+--+/ +--+
|A1|
**** /+--+\ +--+
*C2*----- -----|S2|
**** +--+
Figure 9
Figure 10 illustrates capability announcement for both the supporting
and non-supporting client. This scenario assumes that the
capabilities supported by C1 and A are the same.
There is no change from the simple agent use case for transactions
originated by C1.
For transactions originated by the non-supporting reacting node C2,
A1 determines that C2 does not support DOIC by the absence of an OC-
S-F AVP and inserts an OC-S-F AVP indicating the OC features
supported by A1.
+--+ **** +-+ +-+
|C1| *C2* |A| |S|
+--+ **** +-+ +-+
| | | |
1> |-- xxR OC-S-F:C--------------------------->|-- xxR OC-S-F:C----->|
| | | |
2> |<---------------------------xxA OC-S-F:S---|<-----xxA OC-S-F:S---|
| | | |
3> | |-- xxR ------------->| |
| | | |
4> | | |-- xxR OC-S-F:A----->|
| | | |
5> | | |<-----xxA OC-S-F:S---|
| | | |
6> | |<------------- xxA---| |
| | | |
Figure 10
Donovan & Campbell Expires January 4, 2015 [Page 21]
Internet-Draft Abbreviated Title July 2014
1. C1 supports DOIC and, as such, includes the OC-S-F AVP in all
request messages sent. A relays the request to S based on normal
request handling.
2. S supports DOIC and, as such, includes the OC-S-F AVP in all
response messages sent. A relays the answer to C1 based on
normal answer handling.
3. C2 does not support DOIC and, as such, does not insert the OC-S-F
AVP into request messages.
4. A recognizes that C2 does not support DOIC, since the request
does not contain the OC-S-F AVP. A inserts an OC-S-F AVP that
reflects the OC capabilities of A.
5. S does normal DOIC capability announcement handling, inserting
the OC-S-F AVP in the answer.
6. A removes the OC-S-F AVP from the answer given that C2 does not
support DOIC.
Figure 11 illustrates overload report handling for this scenario.
There is no change in overload handling for requests originated by
C1. C1 is responsible for abatement of host routed requests and A is
responsible for abatement of realm-routed requests.
For requests originated by C2, it becomes the responsibility of A to
handle overload abatement requested by S. In this case A is
responsible for abatement of both host-routed and realm-routed
requests, as A has a direct transport connection to S. The way an
agent handles this in practice is implementation specific. Depending
on the algorithm, an agent might be able to treat requests from all
non-supporting clients as a pool. More complex implementations might
maintain (and certain algorithms might require) the agent to maintain
an overload control state machine for each known non-supporting
client.
If there were an upstream DOIC agent between A and S then A would
no longer have a direct transport connection and would not be able
to do abatement of realm-routed requests. It would become the
responsibility of the upstream DOIC agent with the transport
connection to handle abatement of realm-routed requests.
Donovan & Campbell Expires January 4, 2015 [Page 22]
Internet-Draft Abbreviated Title July 2014
+--+ **** +-+ +-+
|C1| *C2* |A| |S|
+--+ **** +-+ +-+
| | | |
1> |-- xxR OC-S-F:C--------------------------->|-- xxR OC-S-F:C----->|
| | | |
2> |<---------------------------xxA OC-S-F:S---|<-----xxA OC-S-F:S---|
| | OLR | OLR |
| | | |
|HR abatement handled by C1 |RR abatement handled by A
| | | |
3> | |-- xxR ------------->|-- xxR OC-S-F:A----->|
| | | |
4> | |<------------- xxA---|<-----xxA OC-S-F:S---|
| | | OLR |
| | | |
| | | HR and RR abatement |
| | | handled by A |
| | | |
5> | |-- xxR ------------->|-- xxR OC-S-F:A----->|
| | | |
6> | |<------------- xxA---|<-----xxA OC-S-F:S---|
| | | OLR |
| | | |
7> | |-- xxR ------------->| |
| | | |
8> | |<------------- xxA---| |
| | Diameter-Throttled |
| | | |
Figure 11
1. Request from C1, a supporting TC.
2. Response indicating S is requesting a reduction in traffic sent
due to an overload condition. C1 becomes responsible for
abatement of host-routed requests and A becomes responsible for
abatement of realm-routed requests.
3. Request from C2, a non-supporting TC. A inserts an OC-S-F AVP.
4. Response indicating that S is overloaded. A stores overload
state based on the content of the overload report. A also
removed the OC-S-F and OC-OLR AVPs from the answer message. A
becomes responsible for abatement handling of all requests
originated by C2.
Donovan & Campbell Expires January 4, 2015 [Page 23]
Internet-Draft Abbreviated Title July 2014
5. Request from non-supporting node originated after the overload
report is received. This request survives abatement by A.
6. Response for message that survived abatement by A.
7. Request from non-supporting node originated after the overload
report is received. This request does not survive abatement and
is rejected by A.
8. Response for request that did not survive abatement by A, with an
appropriate error code to indicate the request was throttled and
should not be retried.
5.3.2. Non-supporting Transaction Server
This section shows the case where there is a mix of transaction
servers that support DOIC and those that do not support DOIC.
In this case, it becomes the responsibility of a DOIC agent to become
the reporting node for the non-supporting transaction server. The
method the agent uses to determine if abatement of traffic is
required for the non-supporting node is implementation specific.
(For example, an agent may infer that a TS is overloaded by observing
Diameter or transport errors, or it may have some proprietary, out-
of-band mechanism for learning about TS overload.)
+--+ +--+
|C1|----- -----|S1|
+--+ \+--+/ +--+
|A1|
+--+ /+--+\ ****
|C2|----- -----*S2*
+--+ ****
Figure 12
Donovan & Campbell Expires January 4, 2015 [Page 24]
Internet-Draft Abbreviated Title July 2014
+-+ --- +--+ ****
|C| |A| |S1| *S2*
+-+ --- +--+ ****
| | | |
1> |-- xxR OC-S-F:C----->|-- xxR OC-S-F:C----->| |
| | | |
2> |<-----xxA OC-S-F:S---|<-----xxA OC-S-F:S---| |
| | OLR | |
| | | |
3> |-- xxR OC-S-F:C----->| | |
| | | |
4> | |-- xxR OC-S-F:C--------------------------->|
| | | |
5> | |<-----------------------------------xxA ---|
| | | |
6> |<-----xxA OC-S-F:A---| | |
| OLR | | |
| | | |
Figure 13
1. Normal DOIC processing resulting in the request being routed to
S1.
2. Normal DOIC processing.
3. Normal DOIC processing
4. Normal DOIC processing resulting in the request being routed to
S2. The agent doesn't know yet that S2 doesn't support DOIC.
5. S2 does not support DOIC and, as a result, does not insert the
OC-S-F AVP in the answer message.
6. A takes on responsibility for becoming the reporting node for S2,
and inserts an OC-S-F AVP. In this case A has determined that S2
is in an overload condition and inserts an OC-OLR AVP in the
answer message.
C handles the OC-OLR overload report in the same way it handles
all OC-OLR reports.
Donovan & Campbell Expires January 4, 2015 [Page 25]
Internet-Draft Abbreviated Title July 2014
5.3.3. Non-Supporting Agent
There are two sub-cases for non-supporting agents.
Figure 14 illustrates the first non-supporting agent case, where the
first agent in a chain of agents does not support DOIC.
In this case, A2 picks up the responsibility of handling overload
abatement in the case that either C1 or C2 do not support DOIC.
A2 is also responsible for abating realm-routed requests for host
reports received from S1 or S2.
+--+ +--+
|C1|----- -----|S1|
+--+ \**** +--+/ +--+
*A1*------|A2|
+--+ /**** +--+\ +--+
|C2|----- -----|S2|
+--+ +--+
Figure 14
Figure 15 illustrates the second non-supporting agent case, where the
last agent in the chain does not support DOIC.
In this scenario, there is no DOIC node that has a direct transport
connection with S1 and S2. As a result, there is no DOIC node that
can correctly handle abatement of realm-routed requests resulting.
In the example, A1 cannot perform diversion, because it cannot
control whether any given request goes to S1 or S2. And it cannot
correctly determine how much to throttle unless it has advance
knowledge of the topology behind A2, which is currently out of scope
for DOIC.
As a result, this deployment scenario should be avoided.
Donovan & Campbell Expires January 4, 2015 [Page 26]
Internet-Draft Abbreviated Title July 2014
+--+ +--+
|C1|----- -----|S1|
+--+ \+--+ ****/ +--+
|A1|------*A2*
+--+ /+--+ ****\ +--+
|C2|----- -----|S2|
+--+ +--+
Figure 15
5.3.4. DOIC Specification Impacts
o Agents must be allowed to insert OC-S-F AVPs into request and
answer messages.
o Agents must be allowed to remove OC-S-F AVPs from request and
answer messages.
o Agents must be able to insert OC-OLR AVPs of type "Host Report"
into answer messages. (The ability to insert OC-ORL AVPs of type
"Realm Report" is already assumed.)
o Agents must be allowed to remove OC-OLR AVPs from answer messages.
o Agents must be allowed to abate host-routed requests.
5.4. Inter Domain Authentication
Figure 16 shows three administrative domains, Dom 1, Dom 2, and Dom
3. Dom 3 does not wish information about the condition of it's
network to be shared with Dom 1, but is willing to share overload
information with Dom 2 in order to optimize inter-domain traffic.
Donovan & Campbell Expires January 4, 2015 [Page 27]
Internet-Draft Abbreviated Title July 2014
+--------------------+ +-----------+ +--------------------+
| Dom 1 | | Dom 2 | | Dom 3 |
| +--+ | | | | +--+ |
| |C1|----- | | +---+ | | -----|S1| |
| +--+ \+--+--------|A2A|---------+--+/ +--+ |
| |A1| | | +---+ | | |A3| |
| +--+ /| | | | ***** | | | |\ +--+ |
| |C2|----- +--+--------*A2B*---------+--+ -----|S2| |
| +--+ | | ***** | | +--+ |
| | | | | |
+--------------------+ +-----------+ +--------------------+
Figure 16
Dom 2 in in the process of incremental deployment of DOIC. Agent A2A
supports DOIC, but A2B does not. A1 and A3 are configured so that
Diameter requests between them may traverse either A2A or A2B.
Figure 17 shows a Diameter message exchange for each potential route.
The originating TC and selected TS are not relevant for the example,
so they are omitted from the diagram.
+--+ +---+ ***** +--+
|A1| |A2A| *A2B* |A3|
+--+ +---+ ***** +--+
| | | |
1> |-- xxR OC-S-F:A1---->|------xxR OC-S-F:A1----------------------->|
| | | |
2> |<---------------xxA--|<---------------------------xxA OC-S-F:A3--|
| | | |
3> |---xxR OC-S-F:A1-------------------------->|-xxR OC-S-F:A1------>|
| | | |
4> |<---------------------------xxA OC-S-F:A3--|<-----xxA OC-S-F:A3--|
| | | |
Figure 17
1. A1 sends a request that contains OC-S-F:A1 to A2A. A2A supports
the same DOIC capabilities, so it forwards the request with OC-
S-F:A1 unchanged.
2. A3 receives the answer from the TC. It forwards the response to
A2A, including it's capabilities in OC-S-F:A3. A2A is configured
to enforce Dom 3's wishes that it's overload information not be
Donovan & Campbell Expires January 4, 2015 [Page 28]
Internet-Draft Abbreviated Title July 2014
sent to Dom 1, so it strips the AVP before forwarding the
response back to A1.
3. A1 again sends a request including OC-S-F:A1, but this one
traverses A2B. Since A2B does not support DOIC at all, it treats
the AVP as an unknown AVP and forwards it unchanged to A3. Note
that the OC-S-F AVP observed by A3 is identical to that from step
1.
4. A3 receives the answer from the TC. It mistakenly believes A2B
supports DOIC, and therefore forwards the response with it's DOIC
capabilities in OC-S-F:A3. Since A2B does not recognize the AVP,
it forwards it back to A1 without change.
This is a somewhat contrived example, but it shows a case where Dom 3
leaked information to an untrusted domain, because it could not tell
the difference between an OC-S-F AVP received from a trusted peer
that supports DOIC, or one forwarded from downstream by a non-
supporting peer.
5.4.1. DOIC Specification Impacts
A DOIC supporting node must be able to distinguish between an OC-S-F
AVP sent by a peer that supports DOIC, and one sent by a non-adjacent
node and forwarded by a non-supporting peer. That is not possible in
DOIC at the time of this writing.
The ability to limit overload information to nodes that are
authorized to receive it may require the ability to fully
attribute a given OC-S-F AVP to the node that included the AVP.
Whether this is required, and how an AVP that is forwarded by a
DOIC supporting relay is for further study.
6. Recommendations
This section summarizes the recommendations made in previous
sections. These recommendations are presented without normative
language, but the authors expect that some of the recommendations
will require new normative language in [I-D.ietf-dime-ovli]. Others
may result in non-normative guidance.
As noted earlier, nothing in this draft should imply that relays are
required to deploy DOIC. The majority of these recommendations
should be interpreted to allow certain relay behaviors, but not to
require them, and to offer architectural guidance on how an operator
can best utilize relays in a DOIC deployment if they choose to do so.
Donovan & Campbell Expires January 4, 2015 [Page 29]
Internet-Draft Abbreviated Title July 2014
6.1. General Recommendations
This section describes recommendations that apply to the DOIC
mechanism in general:
The working group should define a "Diameter-Throttled" error code,
that indicates a request has failed due to overload, and should not
be retried.[Section 5.1.3] TCs need to recognize the Diameter-
Throttled error code, and interpret it as a final failure for the
transaction.
The OC-OLR AVP syntax must allow multiple occurrences in the same
Diameter answer message. [Section 5.1.3]
6.2. Agent Behavior Recommendations
The discussion in Section 4, Section 3, and Section 5 suggest certain
recommendations for DOIC supporting Diameter relay behavior. The
authors recommend that language be added to [I-D.ietf-dime-ovli] to
the general effect of the following sections:
6.2.1. Capabilites Exchange Behaviors
This section describes recommended Agent behaviors with respect to
the OC-Supported-Features AVP.
A DOIC supporting agent may act as a reporting-node, a reacting-node,
or both.
An agent may act as a reporting node on behalf of a non-supporting
TS, an abating node on behalf of a non-supporting TC.[Section 5.3]
An agent that acts as a reacting node must include an OC-Supported-
Features in each Diameter request that it forwards in that role. If
the inbound request included an OC-Supported-Features AVP, the relay
may copy its content to the one in the outbound request, or may
replace the contents if it wishes to indicate different DOIC
capabilities to upstream nodes. If an inbound request does not
contain an OC-Supported-Features AVP, the agent must insert one into
the outbound request, indicating the DOIC capabilities of the agent
itself.
An agent that acts as a reporting node must include an OC-Supported-
Features AVP in each Diameter answer that it forwards in that role.
If the agent modified the OC-Supported-Features AVP in the associated
request, it must perform a reciprocal modification of the OC-
Supported-Features AVP in the response.
Donovan & Campbell Expires January 4, 2015 [Page 30]
Internet-Draft Abbreviated Title July 2014
An agent that does not support the DOIC mechanism is likely to
forward an OC-Supported-Features AVP without modification. A DOIC
node must be able to tell between an OC-Supported-Features AVP that
was forwarded by such a non-supporting agent, and one inserted or
copied by a DOIC-supporting node.[Section 5.4]
6.2.2. Overload Report Behaviors
When a DOIC-supporting relay inserts an OC-Supported-Features AVP (or
passes through one received from downstream), it becomes responsible
for ensuring that any OLRs it receives from upstream nodes are
honored. It can honor an OLR by locally performing overload
abatement, delegating abatement to downstream nodes, or a combination
of both.
If a relay can honor the OLR by locally diverting traffic, it should
do so before resorting to throttling. For example, if a relay
receives a realm report from its upstream peer, and has other less-
overloaded peers that are valid for the realm and application, it
diverts traffic to the less overloaded peers as needed. The relay
should apply any knowledge it has of the peers' relative load and
capacity in determining how to divert traffic. Note that only a
relay that has a direct peer relationship with the servers in
question can effectively perform diversion, since a Diameter node
cannot directly control how upstream relays will route
requests.[Section 5.1]
When an overload condition requires throttling of traffic, an agent
should delegate that throttling to downstream nodes if at all
possible. Depending on local policy and the nature of the overload
condition, this means the agent either originates a new OLR to send
downstream, or forwards an OLR received from upstream. For example,
if a relay receives a host report (which usually requires traffic
throttling), the relay typically forwards that report downstream.
The relay may modify the report based on local policy.
If an agent needs to perform local throttling, it must explicitly
reject each throttled request with a "Diameter-Throttled" error
code.[Section 5.1]
There may be circumstances where an agent must perform local
throttling. An obvious example is when downstream nodes do not
support DOIC, that is, requests from downstream nodes do not
contain OC-Supported-Features AVPs. Mismatched upstream and
downstream capabilities may require local throttling. For
example, if a relay uses a rate-limiting abatement algorithm
upstream, but downstream devices do not support rate-limiting, it
may have to locally throttle traffic to meet its upstream
Donovan & Campbell Expires January 4, 2015 [Page 31]
Internet-Draft Abbreviated Title July 2014
abatement commitment. It might still invoke the "loss" algorithm
downstream in order to reduce the amount of traffic that must be
locally throttled.[Section 5.2, Section 5.3]
A relay should apply all the information at hand to determine
upstream overload. For example, if a relay receives a host-report
from a directly attached TS, that relay can reasonable infer that the
overload condition applies to all traffic for the realm, and perform
local abatement by diverting realm-routed traffic to other servers.
If there is insufficient capacity to do so, then it can generate
realm-reports downstream. A relay might also have knowledge of the
overload or load state of other nodes through some non-DOIC
mechanism.[Section 5.1]
Finally, a relay should not generate or forward OLRs in a way likely
to cause redundant abatement. For example, if a relay locally
throttles traffic due to a "loss" algorithm OLR, it should not
forward the OLR downstream where other nodes will also apply
abatement to the same traffic. [Section 5.3]
The idea of redundant abatement is at least somewhat specific to
the algorithm. For example, a rate-limiting algorithm might allow
both local and delegated abatement, since the algorithm creates a
maximum rate limit. On the other hand, the "loss" algorithm
requests a percentage reduction. If a relay receives an OLR for a
10 percentage reduction, applies local throttling, and also
forwards the OLR downstream, the 10% reduction may be applied
twice.
7. Security Considerations
Several use cases in this document involve Agents inserting,
removing, or modifying DOIC related AVPs. [RFC6733] does not allow
"relay" agents to modify any part of a Diameter message except for
routing information. This has one of two implications; either relay
agents cannot take an active role in DOIC, or the DOIC AVPs should be
designated as "routing AVPs". The authors recommend the second.
But regardless of whether a relay is allowed to modify DOIC AVPs,
proxy agents will almost certainly need to do so. Diameter currently
only offers hop-by-hop integrity protection of message contents, but
the DIME working group is considering requirements for end-to-end
protection [I-D.ietf-dime-e2e-sec-req] at the time of this writing.
Those requirements currently recognize that different AVPs may
require different security treatments. The working group should
carefully consider how DOIC will interact with end-to-end security
when it is completed.
Donovan & Campbell Expires January 4, 2015 [Page 32]
Internet-Draft Abbreviated Title July 2014
Until such end-to-end protection is deployed, Diameter follows a
fundamentally transitive trust model. Adjacent nodes can
authenticate each other's identity, and protect exchanged messages
from tampering or eavesdropping. But Diameter nodes have no way of
authenticating message content received from non-adjacent nodes,
other than trusting the immediate peer to do the right thing.
DOIC related information may be sensitive, and could be destructive
if forged or modified by unauthorized parties. DOIC nodes must trust
DOIC supporting peers to ensure that no unauthorized parties insert
overload reports, and to ensure that reports are not delivered to
unauthorized parties. Peers that do not support DOIC cannot be
expected to enforce such policies.
At the time of this writing, DOIC provides no way for a supporting
node to distinguish between a DOIC AVP from a immediate peer that
supports DOIC, and one forwarded by a non-supporting peer. This
issue needs to be addressed before DOIC can meet requirements 27, 28,
and 29 of [RFC7068]
8. References
8.1. Normative References
[DOIC-rate]
Donovan, S. and E. Noel, "Diameter Agent Overload",
February 2014.
[I-D.ietf-dime-ovli]
Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
"Diameter Overload Indication Conveyance", draft-ietf-
dime-ovli-02 (work in progress), March 2014.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
[agent-overload]
Donovan, S., "Diameter Agent Overload", March 2014.
8.2. Informative References
Donovan & Campbell Expires January 4, 2015 [Page 33]
Internet-Draft Abbreviated Title July 2014
[I-D.ietf-dime-e2e-sec-req]
Tschofenig, H., Korhonen, J., Zorn, G., and K. Pillay,
"Diameter AVP Level Security: Scenarios and Requirements",
draft-ietf-dime-e2e-sec-req-01 (work in progress), October
2013.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", RFC 7068, November 2013.
Authors' Addresses
Steve Donovan
Oracle
Frisco, Texas
USA
Phone: +1
Email: srdonovan@usdonovans.com
Ben Campbell
Oracle
Frisco, Texas
USA
Phone: +1
Email: ben@nostrum.com
Donovan & Campbell Expires January 4, 2015 [Page 34]
