draft-ietf-dime-agent-overload-06.txt   draft-ietf-dime-agent-overload-07.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track June 21, 2016 Updates: RFC7683 (if approved) December 1, 2016
Expires: December 23, 2016 Intended status: Standards Track
Expires: June 4, 2017
Diameter Agent Overload and the Peer Overload Report Diameter Agent Overload and the Peer Overload Report
draft-ietf-dime-agent-overload-06.txt draft-ietf-dime-agent-overload-07.txt
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to RFC 7683 (Diameter
Indication Conveyance (DOIC) [RFC7683] base solution. The extension Overload Indication Conveyance (DOIC)) base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
Requirements Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 40 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2016. This Internet-Draft will expire on June 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 47
6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14 6.1.2. OC-Peer-Algo . . . . . . . . . . . . . . . . . . . . 14
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15 6.2.1. OC-Report-Type AVP . . . . . . . . . . . . . . . . . 15
6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. SourceID . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15 6.4. Attribute Value Pair flag rules . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16 7.2. New registries . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. The extension Indication Conveyance (DOIC) [RFC7683] base solution. The extension
defines the Peer overload report type. The initial use case for the defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter Peer report is the handling of occurrences of overload of a Diameter
agent. agent.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
In the case where both agents are reporting overload, the client may In the case where both agents are reporting overload, the client may
need to start decreasing the total traffic sent to the agents. This need to start decreasing the total traffic sent to the agents. This
would be done in a similar fashion as discussed in Section 3.1.1 The would be done in a similar fashion as discussed in Section 3.1.1 The
amount of traffic depends on the combined reduction requested by the amount of traffic depends on the combined reduction requested by the
two agents. two agents.
3.1.3. Agent Chains 3.1.3. Agent Chains
There are also deployment scenarios where there can be multiple There are also deployment scenarios where there can be multiple
Diameter Agents between Diameter Clients and Diameter Servers. An Diameter Agents between Diameter Clients and Diameter Servers. An
example of this type of deployment include when there are edge agents example of this type of deployment include when there are Diameter
between Diameter networks. agents between administrative domains.
Figure 5 illustrates one such network deployment case. Note that Figure 5 illustrates one such network deployment case. Note that
while this figure shows a maximum of two agents being involved in a while this figure shows a maximum of two agents being involved in a
Diameter transaction, it is possible that more than two agents could Diameter transaction, it is possible that more than two agents could
be in the path of a transaction. be in the path of a transaction.
+---+ +---+ +-+ +---+ +---+ +-+
--|a11|-----|a21|---|s| --|a11|-----|a21|---|s|
+-+ / +---+ \ / +---+\ /+-+ +-+ / +---+ \ / +---+\ /+-+
|c|- x x |c|- x x
skipping to change at page 8, line 46 skipping to change at page 8, line 46
5. Peer Report Behavior 5. Peer Report Behavior
This section defines the normative behavior associated with the Peer This section defines the normative behavior associated with the Peer
Report extension to the DOIC solution. Report extension to the DOIC solution.
5.1. Capability Announcement 5.1. Capability Announcement
5.1.1. Reacting Node Behavior 5.1.1. Reacting Node Behavior
When sending a Diameter request a DOIC node that supports the When sending a Diameter request a DOIC node that supports the
OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.
When sending a request a DOIC node that supports the OC_PEER_REPORT When sending a request a DOIC node that supports the OC_PEER_REPORT
feature MUST include a SourceID AVP in the OC-Supported-Features AVP feature MUST include a SourceID AVP in the OC-Supported-Features AVP
with its own DiameterIdentity. with its own DiameterIdentity.
Note: This allows the DOIC nodes in the path of the request to
determine if the indication of support came from a Diameter peer
or if the request traversed a node that does not support the
OC_PEER_REPORT feature.
When an agent relays a request that includes a SourceID AVP in the When an agent relays a request that includes a SourceID AVP in the
OC-Supported-Features AVP, a DOIC node that supports the OC-Supported-Features AVP, a DOIC node that supports the
OC_PEER_REPORT feature MUST remove the received SourceID AVP and OC_PEER_REPORT feature MUST remove the received SourceID AVP and
replace it with a SourceID AVP containing its own Diameter identity. replace it with a SourceID AVP containing its own Diameter identity.
5.1.2. Reporting Node Behavior 5.1.2. Reporting Node Behavior
When receiving a request a DOIC node that supports the OC_PEER_REPORT When receiving a request a DOIC node that supports the OC_PEER_REPORT
feature MUST update transaction state with an indication of whether feature MUST update transaction state with an indication of whether
or not the peer from which the request was received supports the or not the peer from which the request was received supports the
skipping to change at page 16, line 9 skipping to change at page 16, line 9
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|OC-Peer-Algo TBD1 x.x Unsigned64 | | V | |OC-Peer-Algo TBD1 x.x Unsigned64 | | V |
|SourceID TBD2 x.x DiameterIdentity | | V | |SourceID TBD2 x.x DiameterIdentity | | V |
+--------------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
7. IANA Considerations 7. IANA Considerations
7.1. AVP codes 7.1. AVP codes
New AVPs defined by this specification are listed in Section 6. All New AVPs defined by this specification are listed in Section 6.4.
AVP codes are allocated from the 'Authentication, Authorization, and All AVP codes are allocated from the 'Authentication, Authorization,
Accounting (AAA) Parameters' AVP Codes registry. and Accounting (AAA) Parameters' AVP Codes registry.
One new OC-Report-Type AVP value is defined in Section 6.2.1
7.2. New registries 7.2. New registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
The values used for the OC-Peer-Algo AVP are the subset of the "OC- The values used for the OC-Peer-Algo AVP are the subset of the "OC-
Feature-Vector AVP Values (code 622)" registry. Only the values in Feature-Vector AVP Values (code 622)" registry. Only the values in
that registry that apply to overload abatement algorithms apply to that registry that apply to overload abatement algorithms apply to
the OC-Peer-Algo AVP. the OC-Peer-Algo AVP.
 End of changes. 9 change blocks. 
18 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/