[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-donovan-dime-drmp) 00 01 02
03 04 05 06 07 RFC 7944
Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle
Intended status: Standards Track November 11, 2015
Expires: May 14, 2016
Diameter Routing Message Priority
draft-ietf-dime-drmp-02.txt
Abstract
When making routing and resource allocation decisions, Diameter nodes
currently have no generic mechanism to determine the relative
priority of Diameter messages. This document addresses this by
defining a mechanism to allow Diameter endpoints to indicate the
relative priority of Diameter transactions. With this information
Diameter nodes can factor that priority into routing, resource
allocation and overload abatement decisions.
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 May 14, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Donovan Expires May 14, 2016 [Page 1]
Internet-Draft DOIC November 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. First Responder Related Signaling . . . . . . . . . . . . 5
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5
5.4. Application Specific Priorities . . . . . . . . . . . . . 6
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8
9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11
9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The DOIC solution [RFC7683] for Diameter overload control introduces
scenarios where Diameter routing decisions made by Diameter nodes can
be influenced by the overload state of other Diameter nodes. This
includes the scenarios where Diameter endpoints and Diameter agents
can throttle requests as a result of the target for the request being
overloaded.
With currently available mechanisms these Diameter nodes do not have
a mechanism to differentiate request message priorities when making
these throttling decisions. As such, all requests are treated the
same meaning that all requests have the same probability of being
throttled.
There are scenarios where treating all requests the same can cause
issues. For instance it might be considered important to reduce the
probability of transactions involving first responders during a
Donovan Expires May 14, 2016 [Page 2]
Internet-Draft DOIC November 2015
period of heavy signaling resulting from a natural disaster being
throttled during overload scenarios.
This document defines a mechanism that allows Diameter nodes to
indicate the relative priority of Diameter transactions. With this
information other Diameter nodes can factor the relative priority of
requests into routing and throttling decisions.
2. Terminology and Abbreviations
Diversion
As defined in [RFC7683]. An overload abatement treatment where
the reacting node selects alternate destinations or paths for
requests.
DOIC
Diameter Overload Indication Conveyance.
DRMP
Diameter Routing Message Priority.
Overload Abatement
As defined in [RFC7683]. Reaction to receipt of an overload
report resulting in a reduction in traffic sent to the reporting
node. Abatement actions include diversion and throttling.
Priority
The relative importance of a Diameter message. A lower priority
value implies a higher relative importance of the message.
Throttling
As defined in [RFC7683]. An abatement treatment that limits the
number of requests sent by the DIOC reacting node. Throttling can
include a Diameter Client choosing to not send requests, or a
Diameter Agent or Server rejecting requests with appropriate error
responses. In both cases the result of the throttling is a
permanent rejection of the transaction.
Donovan Expires May 14, 2016 [Page 3]
Internet-Draft DOIC November 2015
3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
RFC 2119 [RFC2119] interpretation does not apply for the above listed
words when they are not used in all-caps format.
4. Problem Statement
With the introduction of overload control mechanisms, Diameter nodes
will be required to make decisions regarding which Diameter request
messages should be throttled as a result of overloaded Diameter
nodes.
There is currently no generic mechanism to indicate which request
messages should be given preferential treatment when these throttling
decisions are made.
As a result, all messages are treated equally and, as such, have an
equal probability of being throttled.
There are a number of scenarios where it is appropriate for an
application to mark a request as being of a higher priority than
other application requests. These are discussed in the next section.
This document defines a mechanism for applications to indicate
priority for individual transactions, reducing the probability of
those transactions being throttled if there are other lower priority
transactions that are eligible for throttling treatment.
While the primary usage of DRMP defined priorities is for input to
Diameter overload control related throttling decisions, it is also
expected that the priority information could also be used for other
routing related functionality. This might include giving higher
priority transactions preferential treatment when selecting routes.
It is also envisioned that DRMP priority information could be used by
Diameter endpoints to make resource allocation decisions. For
instance, a Diameter Server might choose to use the priority
information to treat higher priority requests ahead of lower priority
requests.
Note: There are a number of application specific definitions
indicating various views of application level priority for
different requests. Using these application specific priority
AVPs as input to throttling and other Diameter routing decisions
Donovan Expires May 14, 2016 [Page 4]
Internet-Draft DOIC November 2015
would require Diameter agents to understand all applications and
do application specific parsing of all messages in order to
determine the priority of individual messages. This is considered
an unacceptable level of complexity to put on elements whose
primary responsibility is to route Diameter messages.
5. Use Cases
This section discussed various scenarios where Diameter transactions
can benefit from the use of priority information.
5.1. First Responder Related Signaling
Natural disasters can result in a considerable increase in usage of
network resources. This can be made worse if the disaster results in
a loss of network capacity.
The combination of added load and reduced capacity can lead to
Diameter nodes becoming overloaded and, as a result, the use of DOIC
mechanisms to request a reduction in traffic. This in turn results
in requests being throttled in an attempt to control the overload
scenario and prevent the overloaded node from failing.
There is the need for first responders and other individuals
responsible for handling the after effects of the disaster to be
assured that they can gain access to the network resources in order
to communicate both between themselves and with other network
resources.
Signaling associated with first responders needs to be given a higher
priority to help ensure they can most effectively do their job.
The United States Wireless Priority Services (WPS) and Government
Emergency Telecommunications Service (GETS) are examples of systems
designed to address these first responder needs.
5.2. Emergency Call Related Signaling
Similar to the first responder scenario, there is also signaling
associated with emergency calls. Given the critical nature of these
emergency calls, this signaling should also be given preferential
treatment when possible.
5.3. Differentiated Services
Operators may desire to differentiate network-based services by
providing a service level agreement that includes preferential
Donovan Expires May 14, 2016 [Page 5]
Internet-Draft DOIC November 2015
Diameter routing behavior. This might, for example, be modeled as
Platinum, Gold and Silver levels of service.
In this scenario an operator might offer a Platinum SLA the includes
ensuring that all signaling for a customer who purchases the Platinum
service being marked as having a higher priority than signaling
associated with Gold and Silver customers.
5.4. Application Specific Priorities
There are scenarios within Diameter applications where it might be
appropriate to give a subset of the transactions for the application
a higher priority than other transactions for that application.
For instance, when there is a series of transactions required for a
user to gain access to network services, it might be appropriate to
mark transactions that occur later in the series at a higher priority
than those that occur early in the series. This would recognize that
there was potentially significant work done by the network already
that would be lost if those later transactions were throttled.
There are also scenarios where an agent cannot easily differentiate a
request that starts a session from requests that update or end
sessions. In these scenarios it might be appropriate to mark the
requests that establish new sessions with a lower priority than
updates and session ending requests. This also recognizes that more
work has already taken place for established sessions and, as a
result, it might be more harmful if the session update and session
ending requests were to be throttled.
There are also scenarios where the priority of requests for
individual command codes within an application depends on the context
that exists when the request is sent. There isn't always information
in the message from which this context can be determined by Diameter
nodes other than the node that originates the request.
This is similar to the scenario where a series of requests are needed
to access a network service. It is different in that the series of
requests involve different application command-codes. In this
scenario it is requests with the same command-code that have
different implied priorities.
One example of this is in the 3GPP application [S6a] where a ULR
request resulting from an MME restoration procedure might be given
a higher priority than a ULR resulting from an initial attach.
Donovan Expires May 14, 2016 [Page 6]
Internet-Draft DOIC November 2015
6. Theory of Operation
This section outlines the envisioned usage of DRMP.
The expected behavior depends on the role (request sender, agent or
request handler) of the Diameter node handling the request.
The following behavior is expected during the flow of a Diameter
transaction.
1. Request sender - The sender of a request, be it a Diameter Client
or a Diameter Server, determines the relative priority of the
request and includes that priority information in the request.
The method for determining the relative priority is application
specific and is outside the scope of this specification. The
request sender also saves the priority information with the
transaction state. This will be used when handling the answer
messages.
2. Agents handing the request - Agents use the priority information
when making routing decisions. This can include determining
which requests to route first, which requests to throttle and
where the request is routed. For instance, requests with higher
priority might have a lower probability of being throttled. The
mechanism for how the agent determines which requests are
throttled is implementation dependent and is outside the scope of
this document. The agent also records the transaction priority
in the transaction state. This will be used when handling the
associated answer message for the transaction.
3. Request handler - The handler of the request, be it a Diameter
Server or a Diameter Client, can use the priority information to
determine how to handle the request. This could include
determining the order in which requests are handled and resources
that are applied to handling of the request.
4. Answer sender - The handler of the request is also the sender of
the answer. The answer sender uses the priority information
received in the request message when sending the answer. This
implies that answers for higher priority transactions are given
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 - By default, agents handling answer
messages use the priority information stored with the transaction
Donovan Expires May 14, 2016 [Page 7]
Internet-Draft DOIC November 2015
state to determine the priority of relaying the answer message.
However, priority information included in the answer message,
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 answer handler uses the same method as the
agent to determine the priority of the answer message. By
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. Extensibility
This document does not define extensibility mechanisms that are
specific to the DRMP mechanism. As a result, any extension that
requires new AVPs will be required to use existing Diameter
extensibility mechanisms defined in [RFC6733]
8. Normative Behavior
This section contains the normative behavior associated with Diameter
Resource Message Priority (DRMP).
When routing priority information is available, Diameter nodes SHOULD
include Diameter routing message priority in the DRMP AVP in all
Diameter request messages.
Note: The method of determining the priority value included in the
request is application specific and is not in the scope of this
specification.
The priority marking scheme SHOULD NOT require the Diameter Agents to
understand application specific AVPs.
When available, Diameter nodes SHOULD use routing priority
information included in the DRMP AVP when making Diameter overload
throttling decisions.
Diameter agents MAY use routing priority information included in the
DRMP AVP when relaying request and answer messages. This includes
the selection of routes and the ordering of messages relayed.
Donovan Expires May 14, 2016 [Page 8]
Internet-Draft DOIC November 2015
The priority information included in the DRMP AVP in request
messages applies to both the request message and, by default,
answer message associated with the transaction.
Diameter endpoints MAY use routing priority information included in
the DRMP AVP when making resource allocation decisions for the
transaction associated with the request message that contains the
DRMP information.
Diameter endpoints MAY use routing priority information included in
the DRMP AVP when making resource allocation decisions for the
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.
Diameter nodes MUST have a default priority to apply to transactions
that do not have an explicit priority set in the DRMP AVP.
Diameter nodes SHOULD use the PRIORITY_10 priority as this default
value.
Diameter nodes MUST support the ability for the default priority to
be modified through local configuration interfaces.
Note: There are scenarios where operators might want to specify a
different default value for transactions that do not have an
explicit priority. In this case, the operator defined local
policy would override the use of PRIORITY_10 as the default
priority.
When using DRMP priority information, Diameter nodes MUST use the
default priority for transactions that do not have priority specified
in a DRMP AVP.
Note: This guidance on the handling of messages without a priority
does not result in a Diameter agent inserting a DRMP AVP into the
message. Rather, it gives guidance on how that specific
transaction should be treated when its priority is compared with
Donovan Expires May 14, 2016 [Page 9]
Internet-Draft DOIC November 2015
other requests. When a Diameter agent relays the request it will
not insert a DRMP AVP with a priority value of 10.
When setting and using priorities, PRIORITY_0 MUST be treated as the
highest priority.
When setting and using priorities, PRIORITY_1 MUST be treated as a
lower priority than PRIORITY_0 and a higher priority than PRIORITY_2.
When setting and using priorities, PRIORITY_2 MUST be treated as a
lower priority than PRIORITY_1 and a higher priority than PRIORITY_3.
When setting and using priorities, PRIORITY_3 MUST be treated as a
lower priority than PRIORITY_2 and a higher priority than PRIORITY_4.
When setting and using priorities, PRIORITY_4 MUST be treated as a
lower priority than PRIORITY_3 and a higher priority than PRIORITY_5.
When setting and using priorities, PRIORITY_5 MUST be treated as a
lower priority than PRIORITY_4 and a higher priority than PRIORITY_6.
When setting and using priorities, PRIORITY_6 MUST be treated as a
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.
Donovan Expires May 14, 2016 [Page 10]
Internet-Draft DOIC November 2015
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.
9. Attribute Value Pairs
This section describes the encoding and semantics of the Diameter
Overload Indication Attribute Value Pairs (AVPs) defined in this
document.
9.1. DRMP AVP
The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP
indicates the routing message priority for the transaction. The
following values are initially defined:
PRIORITY_15 15 PRIORITY_15 is the lowest priority.
PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and
a lower priority than PRIORITY_13.
PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and
a lower priority than PRIORITY_12.
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.
Donovan Expires May 14, 2016 [Page 11]
Internet-Draft DOIC November 2015
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.
9.2. Attribute Value Pair flag rules
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+--------------------------------------------------+----+----+
|DRMP TBD1 x.x Enumerated | | V |
+--------------------------------------------------+----+----+
10. IANA Considerations
10.1. AVP codes
New AVPs defined by this specification are listed in Section 9. All
AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry.
10.2. New registries
There are no new IANA registries introduced by this document.
Donovan Expires May 14, 2016 [Page 12]
Internet-Draft DOIC November 2015
11. Security Considerations
The DRMP could be used to get better access to services. This could
result in one segment of a Diameter network gaining assess to
services that would otherwise be given to other segments of the
Diamter network.
12. Contributors
The following people contributed substantial ideas, feedback, and
discussion to this document:
o Janet P. Gunn
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
13.2. Informative References
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, DOI 10.17487/RFC4412, February 2006,
<http://www.rfc-editor.org/info/rfc4412>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>.
Donovan Expires May 14, 2016 [Page 13]
Internet-Draft DOIC November 2015
[S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management
Entity (MME) and Serving GPRS Support Node (SGSN) related
interfaces based on Diameter protocol", 3GPP TS 29.272
10.8.0, June 2013.
Author's Address
Steve Donovan
Oracle
7460 Warren Parkway
Frisco, Texas 75034
United States
Email: srdonovan@usdonovans.com
Donovan Expires May 14, 2016 [Page 14]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/