draft-ietf-dime-drmp-00.txt   draft-ietf-dime-drmp-01.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 August 6, 2015 Intended status: Standards Track October 12, 2015
Expires: February 7, 2016 Expires: April 14, 2016
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-00.txt draft-ietf-dime-drmp-01.txt
Abstract Abstract
When making routing and resource allocation decisions, Diameter nodes When making routing and resource allocation decisions, Diameter nodes
currently have no generic mechanism to determine the relative currently have no generic mechanism to determine the relative
priority of Diameter messages. This document defines a mechanism to priority of Diameter messages. This document addresses this by
allow Diameter endpoints to indicate the relative priority of defining a mechanism to allow Diameter endpoints to indicate the
Diameter transactions. With this information Diameter nodes can relative priority of Diameter transactions. With this information
factor that priority into routing, resource allocation and overload Diameter nodes can factor that priority into routing, resource
abatement decisions. allocation and overload abatement decisions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 7, 2016. This Internet-Draft will expire on April 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 20 skipping to change at page 2, line 20
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. First Responder Related Signaling . . . . . . . . . . . . 5 5.1. First Responder Related Signaling . . . . . . . . . . . . 5
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5
5.4. Application Specific Priorities . . . . . . . . . . . . . 6 5.4. Application Specific Priorities . . . . . . . . . . . . . 6
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
7. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 7. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8
8. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 9 8. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11
8.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 9 8.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. New registries . . . . . . . . . . . . . . . . . . . . . 10 9.2. New registries . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Design Considerations and Questions . . . . . . . . 11 Appendix A. Design Considerations and Questions . . . . . . . . 14
A.1. Relationship with SIP Resource Priority . . . . . . . . . 11 A.1. Relationship with SIP Resource Priority . . . . . . . . . 14
A.2. Priority Encoding Method . . . . . . . . . . . . . . . . 12 A.2. Priority Encoding Method . . . . . . . . . . . . . . . . 14
A.3. Base Protocol versus Application Extension . . . . . . . 12 A.3. Base Protocol versus Application Extension . . . . . . . 15
A.4. Scope of Priority Setting . . . . . . . . . . . . . . . . 13 A.4. Scope of Priority Setting . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The DOIC solution [I-D.ietf-dime-ovli] for Diameter overload control The DOIC solution [I-D.ietf-dime-ovli] for Diameter overload control
introduces scenarios where Diameter routing decisions made by introduces scenarios where Diameter routing decisions made by
Diameter nodes can be influenced by the overload state of other Diameter nodes can be influenced by the overload state of other
Diameter nodes. This includes the scenarios where Diameter endpoints Diameter nodes. This includes the scenarios where Diameter endpoints
and Diameter agents can throttle requests as a result of the target and Diameter agents can throttle requests as a result of the target
for the request being overloaded. for the request being overloaded.
With currently available mechanisms these Diameter nodes do not have With currently available mechanisms these Diameter nodes do not have
a clean mechanism to differentiate request message priorities when a mechanism to differentiate request message priorities when making
making these throttling decisions. As such, all requests are treated these throttling decisions. As such, all requests are treated the
the same meaning that all requests have the same probability of being same meaning that all requests have the same probability of being
throttled. throttled.
There are scenarios where treating all requests the same can cause There are scenarios where treating all requests the same can cause
issues. For instance it might be considered important to reduce the issues. For instance it might be considered important to reduce the
probability of transactions involving first responders during a probability of transactions involving first responders during a
period of heavy signaling resulting from a natural disaster being period of heavy signaling resulting from a natural disaster being
throttled during overload scenarios. throttled during overload scenarios.
This document defines a mechanism that allows Diameter nodes to This document defines a mechanism that allows Diameter nodes to
indicate the relative priority of Diameter transactions. With this indicate the relative priority of Diameter transactions. With this
skipping to change at page 7, line 45 skipping to change at page 7, line 45
3. Request handler - The handler of the request, be it a Diameter 3. Request handler - The handler of the request, be it a Diameter
Server or a Diameter Client, can use the priority information to Server or a Diameter Client, can use the priority information to
determine how to handle the request. This could include determine how to handle the request. This could include
determining the order in which requests are handled and resources determining the order in which requests are handled and resources
that are applied to handling of the request. that are applied to handling of the request.
4. Answer sender - The handler of the request is also the sender of 4. Answer sender - The handler of the request is also the sender of
the answer. The answer sender uses the priority information the answer. The answer sender uses the priority information
received in the request message when sending the answer. This received in the request message when sending the answer. This
implies that answers for higher priority transactions are given implies that answers for higher priority transactions are given
preferential treatment to lower priority transactions. preferential treatment to lower priority transactions. The
answer sender also has the option of including priority
information in the answer message. This is done what the answer
message needs to have a different priority than the priority
carried in the request message.
5. Agent handling the answer - Agents handling answer messages use 5. Agent handling the answer - By default, agents handling answer
the priority information stored with the transaction state to messages use the priority information stored with the transaction
determine the priority of relaying the answer message. This state to determine the priority of relaying the answer message.
implies that answers for higher priority transactions are given However, priority information included in the answer message,
preferential treatment to lower priority transactions. when present, is used in place of the stored priority
information. The use of priority information implies that
answers for higher priority transactions are given preferential
treatment to lower priority transactions.
6. Answer handler - The handler of the answer message uses the 6. Answer handler - The answer handler uses the same method as the
priority of the transaction when allocating resources for agent to determine the priority of the answer message. By
processing that occurs after the receipt of the answer message. default the handler of the answer message uses the priority of
the transaction. Priority information in the answer message is
used when present. The priority is used when allocating
resources for processing that occurs after the receipt of the
answer message.
7. Normative Behavior 7. Normative Behavior
This section contains the normative behavior associated with Diameter This section contains the normative behavior associated with Diameter
Resource Message Priority (DRMP). Resource Message Priority (DRMP).
When routing priority information is available, Diameter nodes SHOULD When routing priority information is available, Diameter nodes SHOULD
include Diameter routing message priority in all Diameter request include Diameter routing message priority in the DRMP AVP in all
messages. Diameter request messages.
Note: The method of determining the priority value included in the Note: The method of determining the priority value included in the
request is application specific and is not in the scope of this request is application specific and is not in the scope of this
specification. specification.
The priority marking scheme SHOULD NOT require the Diameter Agents to The priority marking scheme SHOULD NOT require the Diameter Agents to
understand application specific AVPs. understand application specific AVPs.
When routing priority information is available, Diameter nodes SHOULD When available, Diameter nodes SHOULD use routing priority
use DRMP information when making Diameter overload related throttling information included in the DRMP AVP when making Diameter overload
decisions. throttling decisions.
Diameter agents MAY use DRMP information when relaying messages. Diameter agents MAY use routing priority information included in the
This includes the selection of routes and the ordering of messages DRMP AVP when relaying reqeust and answer messages. This includes
relayed. the selection of routes and the ordering of messages relayed.
The priority information included applies to both the request The priority information included in the DRMP AVP in request
message and answer message associated with the transaction. As messages applies to both the request message and, by default,
such it is used in the processing of both types of messages. answer message associated with the transaction.
Diameter endpoints MAY use DRMP information when making resource Diameter endpoints MAY use routing priority information included in
allocation decisions for the transaction associated with the request the DRMP AVP when making resource allocation decisions for the
message that contains the DRMP information. transaction associated with the request message that contains the
DRMP information.
Diameter endpoints MAY use DRMP information when making resource Diameter endpoints MAY use routing priority information included in
allocation decisions for the transaction associated with the answer the DRMP AVP when making resource allocation decisions for the
messages using the DRMP information associated with the transaction. transaction associated with the answer messages using the DRMP
information associated with the transaction.
Diameter endpoints MAY include the DRMP AVP in answer messages. This
is done when the priority for the answer message needs to have a
different priority than the priority carried in the request message.
When determining the priority to apply to answer messages, Diameter
nodes MUST use the priority indicated in the DRMP AVP carried in the
answer message, if it exists. Otherwise, the Diameter node MUST use
the priority indicated in the DRMP AVP of the associated request
message.
When there is a mix of transactions specifying priority in request When there is a mix of transactions specifying priority in request
messages and transactions that do not have the priority specified, messages and transactions that do not have the priority specified,
transactions that do not have a specified priority SHOULD be treated transactions that do not have a specified priority SHOULD be treated
as having the PRIORITY_0 priority. as having the PRIORITY_14 priority.
Editor's Note: There are four options identified for defining the
default priority for transactions that do not have a priority
specified in in the request message.
1 - Make it operater defined local policy.
2 - Make it the lowest priority. This has issues in that it does
not allow for a Diameter node to explicitly indicate that a
transaction is to have a lower priority than the default priority.
3 - Make one of the middle priorities, such as PRIORITY_8, the
default priority. This effectively forces half of the priorities
to be lower than the default priority.
4 - Make the default priority one greater than the lowest
priority.
The current version of this draft proposes using option 4. This
needs to be verified to be the preferred approach.
When setting and using priorities, PRIORITY_0 MUST be treated as the When setting and using priorities, PRIORITY_0 MUST be treated as the
highest priority. highest priority.
When setting and using priorities, PRIORITY_1 MUST be treated as a When setting and using priorities, PRIORITY_1 MUST be treated as a
lower priority than PRIORITY_0 and a higher priority than PRIORITY_2. lower priority than PRIORITY_0 and a higher priority than PRIORITY_2.
When setting and using priorities, PRIORITY_2 MUST be treated as a When setting and using priorities, PRIORITY_2 MUST be treated as a
lower priority than PRIORITY_1 and a higher priority than PRIORITY_3. lower priority than PRIORITY_1 and a higher priority than PRIORITY_3.
When setting and using priorities, PRIORITY_3 MUST be treated as a When setting and using priorities, PRIORITY_3 MUST be treated as a
lower priority than PRIORITY_2 and a higher priority than PRIORITY_4. lower priority than PRIORITY_2 and a higher priority than PRIORITY_4.
When setting and using priorities, PRIORITY_4 MUST be the lowest When setting and using priorities, PRIORITY_4 MUST be treated as a
priority. lower priority than PRIORITY_3 and a higher priority than PRIORITY_5.
Editor's note: It is likely that there are other considerations When setting and using priorities, PRIORITY_5 MUST be treated as a
for setting and using priorities. For instance, it might be good lower priority than PRIORITY_4 and a higher priority than PRIORITY_6.
to use priority 1 to indicate elevated priority for strictly
protocol reasons (e.g.; the S6a use case). Priorities 3, 4 and 5 When setting and using priorities, PRIORITY_6 MUST be treated as a
would then be used for non protocol reasons. lower priority than PRIORITY_5 and a higher priority than PRIORITY_7.
When setting and using priorities, PRIORITY_7 MUST be treated as a
lower priority than PRIORITY_6 and a higher priority than PRIORITY_8.
When setting and using priorities, PRIORITY_8 MUST be treated as a
lower priority than PRIORITY_7 and a higher priority than PRIORITY_9.
When setting and using priorities, PRIORITY_9 MUST be treated as a
lower priority than PRIORITY_8 and a higher priority than
PRIORITY_10.
When setting and using priorities, PRIORITY_10 MUST be treated as a
lower priority than PRIORITY_9 and a higher priority than
PRIORITY_11.
When setting and using priorities, PRIORITY_11 MUST be treated as a
lower priority than PRIORITY_10 and a higher priority than
PRIORITY_12.
When setting and using priorities, PRIORITY_12 MUST be treated as a
lower priority than PRIORITY_11 and a higher priority than
PRIORITY_13.
When setting and using priorities, PRIORITY_13 MUST be treated as a
lower priority than PRIORITY_12 and a higher priority than
PRIORITY_14.
When setting and using priorities, PRIORITY_14 MUST be treated as a
lower priority than PRIORITY_13 and a higher priority than
PRIORITY_15.
When setting and using priorities, PRIORITY_15 MUST be the lowest
priority.
8. Attribute Value Pairs 8. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) defined in this
document. document.
8.1. DRMP AVP 8.1. DRMP AVP
The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP
indicates the routing message priority for the transaction. The indicates the routing message priority for the transaction. The
following values are initially defined: following values are initially defined:
PRIORITY_4 4 Priority 4 is the lowest priority. PRIORITY_15 15 PRIORITY_15 is the lowest priority.
PRIORITY_3 3 Priority 3 is the second lowest priority. PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and
a lower priority than PRIORITY_13.
PRIORITY_2 2 Priority 2 is the middle priority. PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and
a lower priority than PRIORITY_12.
PRIORITY_1 1 Priority 1 is the second highest priority. PRIORITY_12 12 PRIORITY_12 is a higher priority than PRIORITY_13 and
a lower priority than PRIORITY_11.
PRIORITY_11 11 PRIORITY_11 is a higher priority than PRIORITY_12 and
a lower priority than PRIORITY_10.
PRIORITY_10 10 PRIORITY_10 is a higher priority than PRIORITY_11 and
a lower priority than PRIORITY_9.
PRIORITY_9 9 PRIORITY_9 is a higher priority than PRIORITY_10 and a
lower priority than PRIORITY_8.
PRIORITY_8 8 PRIORITY_8 is a higher priority than PRIORITY_9 and a
lower priority than PRIORITY_7.
PRIORITY_7 7 PRIORITY_7 is a higher priority than PRIORITY_8 and a
lower priority than PRIORITY_6.
PRIORITY_6 6 PRIORITY_6 is a higher priority than PRIORITY_7 and a
lower priority than PRIORITY_5.
PRIORITY_5 5 PRIORITY_5 is a higher priority than PRIORITY_6 and a
lower priority than PRIORITY_4.
PRIORITY_4 4 PRIORITY_4 is a higher priority than PRIORITY_5 and a
lower priority than PRIORITY_3.
PRIORITY_3 3 PRIORITY_3 is a higher priority than PRIORITY_4 and a
lower priority than PRIORITY_2.
PRIORITY_2 2 PRIORITY_2 is a higher priority than PRIORITY_3 and a
lower priority than PRIORITY_1.
PRIORITY_1 1 PRIORITY_1 is a higher priority than PRIORITY_2 and a
lower priority than PRIORITY_0.
PRIORITY_0 0 Priority 0 is the highest priority. PRIORITY_0 0 Priority 0 is the highest priority.
8.2. Attribute Value Pair flag rules 8.2. Attribute Value Pair flag rules
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
|DRMP TBD1 8.1 Grouped | | V | |DRMP TBD1 x.x Enumerated | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
9. IANA Considerations 9. IANA Considerations
9.1. AVP codes 9.1. AVP codes
New AVPs defined by this specification are listed in Section 8. All New AVPs defined by this specification are listed in Section 8. All
AVP codes are allocated from the 'Authentication, Authorization, and AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
skipping to change at page 10, line 37 skipping to change at page 13, line 8
extend the number of priorities beyond the five defined in this extend the number of priorities beyond the five defined in this
specification. This assumption needs to be verified. If there is specification. This assumption needs to be verified. If there is
the need for extensibility then a new IANA registry would be the need for extensibility then a new IANA registry would be
required. This new registry would be established as part of the required. This new registry would be established as part of the
standardization effort associated with the definition of new standardization effort associated with the definition of new
priority values. priority values.
10. Security Considerations 10. Security Considerations
The DRMP could be used to get better access to services. This could The DRMP could be used to get better access to services. This could
result in one segment of a Diameter network limiting service to result in one segment of a Diameter network gaining assess to
another segment of a Diameter network. services that would otherwise be given to other segments of the
Diamter network.
11. Contributors 11. Contributors
The following people contributed substantial ideas, feedback, and The following people contributed substantial ideas, feedback, and
discussion to this document: discussion to this document:
o Janet P. Gunn o Janet P. Gunn
12. References 12. References
 End of changes. 25 change blocks. 
70 lines changed or deleted 184 lines changed or added

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