draft-ietf-dime-drmp-07.txt   rfc7944.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Internet Engineering Task Force (IETF) S. Donovan
Internet-Draft Oracle Request for Comments: 7944 Oracle
Intended status: Standards Track June 3, 2016 Category: Standards Track August 2016
Expires: December 5, 2016 ISSN: 2070-1721
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-07.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 addresses this by priority of Diameter messages. This document addresses this by
defining a mechanism to allow Diameter endpoints to indicate the defining a mechanism to allow Diameter endpoints to indicate the
relative priority of Diameter transactions. With this information relative priority of Diameter transactions. With this information,
Diameter nodes can factor that priority into routing, resource Diameter nodes can factor that priority into routing, resource
allocation and overload 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 is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 5, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7944.
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 15 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. First Responder Related Signaling . . . . . . . . . . . . 6 5.1. First-Responder-Related Signaling . . . . . . . . . . . . 6
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 6 5.2. Emergency-Call-Related Signaling . . . . . . . . . . . . 6
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 7
5.4. Application Specific Priorities . . . . . . . . . . . . . 7 5.4. Application-Specific Priorities . . . . . . . . . . . . . 7
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 10 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 10
9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12
9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 13 9.2. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 13
10. Considerations When Defining Application Priorities . . . . . 13 10. Considerations When Defining Application Priorities . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. New registries . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 15 12.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 15
12.2. Denial of Service Attacks . . . . . . . . . . . . . . . 16 12.2. Denial-of-Service Attacks . . . . . . . . . . . . . . . 16
12.3. End-to End-Security Issues . . . . . . . . . . . . . . . 16 12.3. End-to-End Security Issues . . . . . . . . . . . . . . . 16
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 17 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683] The Diameter Overload Indication Conveyance (DOIC) solution [RFC7683]
for Diameter overload control introduces scenarios where Diameter for Diameter overload control introduces scenarios where Diameter
routing decisions made by Diameter nodes can be influenced by the routing decisions made by Diameter nodes can be influenced by the
overload state of other Diameter nodes. This includes the scenarios overload state of other Diameter nodes. This includes the scenarios
where Diameter endpoints and Diameter agents can throttle requests as where Diameter endpoints and Diameter Agents can throttle requests as
a result of the target for the request being overloaded. a result of the target 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 mechanism to differentiate request message priorities when making a mechanism to differentiate request message priorities when making
these throttling decisions. As such, all requests are treated the these throttling decisions. As such, all requests are treated 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 being probability of transactions involving first responders being
throttled during overload scenarios caused, for example, by a period throttled during overload scenarios caused, for example, by a period
of heavy signaling resulting from a natural disaster. of heavy signaling resulting from a natural disaster.
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
information other Diameter nodes can factor the relative priority of information, other Diameter nodes can factor the relative priority of
requests into routing and throttling decisions. requests into routing and throttling decisions.
1.1. Applicability 1.1. Applicability
There are two primary considerations that must be addressed for the There are two primary considerations that must be addressed for the
mechanism described in this document to work effectively. The first mechanism described in this document to work effectively. The first
takes into consideration that the Diameter base protocol defined in takes into consideration the fact that the Diameter base protocol
[RFC6733] is designed to transport multiple Diameter applications defined in [RFC6733] is designed to transport multiple Diameter
and that Diameter nodes can be implemented that support multiple applications and that Diameter nodes can be implemented that support
applications. In order for the DRMP mechanism to work, the multiple applications. In order for the Diameter Routing Message
priorities defined for all messages across all applications used in a Priority (DRMP) mechanism to work, the priorities defined for all
Diameter administrative domain must be defined in a consistent and messages across all applications used in a Diameter administrative
coordinated fashion, taking the default priority into account. See domain must be defined in a consistent and coordinated fashion,
Section 10 for a discussion of some of the considerations that need taking the default priority into account. See Section 10 for a
to be factored into the setting of DRMP priorities used by Diameter discussion of some of the considerations that need to be factored
applications. into the setting of DRMPs used by Diameter applications.
Note that this consideration does not apply to Diameter networks Note that this consideration does not apply to Diameter networks
where all Diameter nodes only support a single application. where all Diameter nodes only support a single application.
Without this cross application priority design taken into Without this cross application priority design taken into
consideration it is possible for messages for one application to gain consideration, it is possible for messages for one application to
unwarranted preferential treatment over messages for other gain unwarranted preferential treatment over messages for other
applications. applications.
This mechanism also depends on all of the messages that carry the This mechanism also depends on all of the messages that carry the
DRMP AVP are inserted into Diameter messages by trusted nodes within DRMP Attribute Value Pair (AVP) that are inserted into Diameter
the Diameter administrative domain. As discussed in Section 12, messages by trusted nodes within the Diameter administrative domain.
misbehaving nodes have the ability to use the DRMP mechanism to gain As discussed in Section 12, misbehaving nodes have the ability to use
unwarranted preferential treatment. the DRMP mechanism to gain unwarranted preferential treatment.
When messages cross Diameter administrative boundaries, care should When messages cross Diameter administrative boundaries, care should
be taken to either strip or modify the DRMP priority values in these be taken to either strip or modify the DRMP values in these messages.
messages. If the priority definitions vary between the two Diameter If the priority definitions vary between the two Diameter
administrative domains then it is possible for messages from a administrative domains, then it is possible for messages from a
foreign domain to gain unwarranted preferential treatment. foreign domain to gain unwarranted preferential treatment.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diversion Diversion
As defined in [RFC7683]. An overload abatement treatment where As defined in [RFC7683]. An overload abatement treatment where
the reacting node selects alternate destinations or paths for the reacting node selects alternate destinations or paths for
requests. requests.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
Diameter Routing Message Priority. Diameter Routing Message Priority.
Overload Abatement Overload Abatement
As defined in [RFC7683]. Reaction to receipt of an overload As defined in [RFC7683]. Reaction to receipt of an overload
report resulting in a reduction in traffic sent to the reporting report resulting in a reduction in traffic sent to the reporting
node. Abatement actions include diversion and throttling. node. Abatement actions include diversion and throttling.
Priority Priority
The relative importance of a Diameter message. A lower priority The relative importance of a Diameter message. A lower-priority
value implies a higher relative importance of the message. value implies a higher relative importance of the message.
Throttling Throttling
As defined in [RFC7683]. An abatement treatment that limits the As defined in [RFC7683]. An abatement treatment that limits the
number of requests sent by the DOIC reacting node. Throttling can number of requests sent by the DOIC reacting node. Throttling can
include a Diameter Client choosing to not send requests, or a include a Diameter Client choosing to not send requests or a
Diameter Agent or Server rejecting requests with appropriate error Diameter Agent or Server rejecting requests with appropriate error
responses. In both cases the result of the throttling is a responses. In both cases, the result of the throttling is a
permanent rejection of the transaction. permanent rejection of the transaction.
3. Conventions Used in This Document 3. Conventions Used in This Document
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 [RFC2119].
RFC 2119 [RFC2119] interpretation does not apply for the above listed The interpretation from RFC 2119 does not apply for the above listed
words when they are not used in all-caps format. words when they are not used in all caps.
4. Problem Statement 4. Problem Statement
With the introduction of overload control mechanisms, Diameter nodes With the introduction of overload control mechanisms, Diameter nodes
will be required to make decisions regarding which Diameter request will be required to make decisions regarding which Diameter request
messages should be throttled as a result of overloaded Diameter messages should be throttled as a result of overloaded Diameter
nodes. nodes.
There is currently no generic mechanism to indicate which request There is currently no generic mechanism to indicate which request
messages should be given preferential treatment when these throttling messages should be given preferential treatment when these throttling
skipping to change at page 5, line 25 skipping to change at page 5, line 25
As a result, all messages are treated equally and, as such, have an As a result, all messages are treated equally and, as such, have an
equal probability of being throttled. equal probability of being throttled.
There are a number of scenarios where it is appropriate for an There are a number of scenarios where it is appropriate for an
application to mark a request as being of a higher priority than application to mark a request as being of a higher priority than
other application requests. These are discussed in the next section. other application requests. These are discussed in the next section.
This document defines a mechanism for applications to indicate This document defines a mechanism for applications to indicate
priority for individual transactions, reducing the probability of priority for individual transactions, reducing the probability of
those transactions being throttled if there are other lower priority those transactions being throttled if there are other lower-priority
transactions that are eligible for throttling treatment. transactions that are eligible for throttling treatment.
While the primary usage of DRMP defined priorities is for input to While the primary usage of DRMP-defined priorities is for input to
Diameter overload control related throttling decisions, it is also throttling decisions related to Diameter overload control, it is also
expected that the priority information could also be used for other expected that the priority information could also be used for other
routing related functionality. This might include giving higher routing-related functionality. This might include giving higher-
priority transactions preferential treatment when selecting routes. priority transactions preferential treatment when selecting routes.
It is also envisioned that DRMP priority information could be used by It is also envisioned that DRMP information could be used by Diameter
Diameter endpoints to make resource allocation decisions. For endpoints to make resource allocation decisions. For instance, a
instance, a Diameter Server might choose to use the priority Diameter Server might choose to use the priority information to treat
information to treat higher priority requests ahead of lower priority higher-priority requests ahead of lower-priority requests. It might
requests. It might also use the priority information to as a reason also use the priority information as a reason to fail a request as a
to fail a request as a result of insufficient resources. result of insufficient resources.
Note: There are a number of application specific definitions Note: There are a number of application-specific definitions
indicating various views of application level priority for indicating various views of application-level priority for
different requests. Using these application specific priority different requests. Using these application-specific priority
Attribute Value Pairs (AVPs) as input to throttling and other AVPs as input to throttling and other Diameter routing decisions
Diameter routing decisions would require Diameter agents to would require Diameter Agents to understand all applications and
understand all applications and do application specific parsing of do application-specific parsing of all messages in order to
all messages in order to determine the priority of individual determine the priority of individual messages. This is considered
messages. This is considered an unacceptable level of complexity an unacceptable level of complexity to put on elements whose
to put on elements whose primary responsibility is to route primary responsibility is to route Diameter messages.
Diameter messages.
5. Use Cases 5. Use Cases
This section discusses various scenarios where Diameter transactions This section discusses various scenarios where Diameter transactions
can benefit from the use of priority information. can benefit from the use of priority information.
It is important to note that for priority information to be reliably It is important to note that for priority information to be reliably
usable, the Diameter nodes sending and consuming DRMP AVPs must have usable, the Diameter nodes sending and consuming DRMP AVPs must have
pre-established trust relationships of the sort described in pre-established trust relationships of the sort described in
Section 12. Section 12.
5.1. First Responder Related Signaling 5.1. First-Responder-Related Signaling
Natural disasters can result in a considerable increase in usage of Natural disasters can result in a considerable increase in usage of
network resources. This can be made worse if the disaster results in network resources. This can be made worse if the disaster results in
a loss of network capacity. a loss of network capacity.
The combination of added load and reduced capacity can lead to The combination of added load and reduced capacity can lead to
Diameter nodes becoming overloaded and, as a result, the use of DOIC Diameter nodes becoming overloaded and, as a result, the use of DOIC
mechanisms to request a reduction in traffic. This in turn results mechanisms to request a reduction in traffic. In turn, this results
in requests being throttled in an attempt to control the overload in requests being throttled in an attempt to control the overload
scenario and prevent the overloaded node from failing. scenario and prevent the overloaded node from failing.
There is the need for first responders and other individuals There is the need for first responders and other individuals
responsible for handling the after effects of the disaster to be responsible for handling the after effects of the disaster to be
assured that they can gain access to the network resources in order assured that they can gain access to the network resources in order
to communicate both between themselves and with other network to communicate both between themselves and with other network
resources. resources.
Signaling associated with first responders needs to be given a higher Signaling associated with first responders needs to be given a higher
priority to help ensure they can most effectively do their jobs. priority to help ensure they can most effectively do their jobs.
The United States Wireless Priority Services (WPS) and Government The United States Wireless Priority Services (WPS) and Government
Emergency Telecommunications Service (GETS) are examples of systems Emergency Telecommunications Service (GETS) are examples of systems
designed to address the command and control aspects of these first designed to address the command and control aspects of these first
responder needs. responder needs.
5.2. Emergency Call Related Signaling 5.2. Emergency-Call-Related Signaling
Similar to the first responder scenario, there is also signaling Similar to the first responder scenario, there is also signaling
associated with emergency calls. Given the critical nature of these associated with emergency calls. Given the critical nature of these
emergency calls, this signaling should also be given preferential emergency calls, this signaling should also be given preferential
treatment when possible. treatment when possible.
5.3. Differentiated Services 5.3. Differentiated Services
Operators may desire to differentiate network-based services by Operators may desire to differentiate network-based services by
providing a service level agreement that includes preferential providing a service level agreement (SLA) that includes preferential
Diameter routing behavior. This might, for example, be modeled as Diameter routing behavior. This might, for example, be modeled as
Platinum, Gold and Silver levels of service. Platinum, Gold, and Silver levels of service.
In this scenario an operator might offer a Platinum SLA that includes In this scenario, an operator might offer a Platinum SLA that
ensuring that all signaling for a customer who purchases the Platinum includes ensuring that all signaling for a customer who purchases the
service being marked as having a higher priority than signaling Platinum service is being marked as having a higher priority than
associated with Gold and Silver customers. signaling associated with Gold and Silver customers.
5.4. Application Specific Priorities 5.4. Application-Specific Priorities
There are scenarios within Diameter applications where it might be There are scenarios within Diameter applications where it might be
appropriate to give a subset of the transactions for the application appropriate to give a subset of the transactions for the application
a higher priority than other transactions for that application. a higher priority than other transactions for that application.
For instance, when there is a series of transactions required for a For instance, when there is a series of transactions required for a
user to gain access to network services, it might be appropriate to user to gain access to network services, it might be appropriate to
mark transactions that occur later in the series at a higher priority mark transactions that occur later in the series at a higher priority
than those that occur early in the series. This would recognize that than those that occur early in the series. This would recognize that
there was potentially significant work done by the network already there was potentially significant work done by the network already
that would be lost if those later transactions were throttled. that would be lost if those later transactions were throttled.
There are also scenarios where an agent cannot easily differentiate a There are also scenarios where an agent cannot easily differentiate a
request that starts a session from requests that update or end request that starts a session from requests that update or end
sessions. In these scenarios it might be appropriate to mark the sessions. In these scenarios, it might be appropriate to mark the
requests that establish new sessions with a lower priority than requests that establish new sessions with a lower priority than
updates and session ending requests. This also recognizes that more updates and session ending requests. This also recognizes that more
work has already taken place for established sessions and, as a work has already taken place for established sessions, and as a
result, it might be more harmful from a signaling point of view if result, it might be more harmful from a signaling point of view if
the session update and session ending requests were to be throttled. the session update and session ending requests were to be throttled.
There are also scenarios where the priority of requests for There are also scenarios where the priority of requests for
individual command codes within an application depends on the context individual command codes within an application depends on the context
that exists when the request is sent. There isn't always information that exists when the request is sent. There isn't always information
in the message from which this context can be determined by Diameter in the message from which this context can be determined by Diameter
nodes other than the node that originates the request. nodes other than the node that originates the request.
This is similar to the scenario where a series of requests are needed 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 to access a network service. It is different in that the series of
requests involve different application command codes. In this requests involves different application command codes. In this
scenario requests with the same command code have different implied scenario, requests with the same command code have different implied
priorities. priorities.
One example of this is in the 3GPP application [S6a] where an One example of this is in the 3GPP application [S6a] where an
Update Location Request (ULR) request resulting from an MME Update Location Request (ULR) resulting from a Mobility Management
(Mobility Management Entity) restoration procedure might be given Entity (MME) restoration procedure might be given a higher
a higher priority than a ULR (Update Location Request) resulting priority than a ULR resulting from an initial attach.
from an initial attach.
6. Theory of Operation 6. Theory of Operation
This section outlines the envisioned usage of DRMP. This section outlines the envisioned usage of DRMP.
The expected behavior depends on the role (request sender, agent or The expected behavior depends on the role (request sender, agent, or
request handler) of the Diameter node handling the request. request handler) of the Diameter node handling the request.
The following behavior is expected during the flow of a Diameter The following behavior is expected during the flow of a Diameter
transaction. transaction.
1. Request sender - The sender of a request, be it a Diameter Client 1. Request sender -- The sender of a request, be it a Diameter
or a Diameter Server, determines the relative priority of the Client or a Diameter Server, determines the relative priority of
request and includes that priority information in the request. the request and includes that priority information in the
The method for determining the relative priority is application request. The method for determining the relative priority is
specific and is outside the scope of this specification. The application specific and is outside the scope of this
request sender also saves the priority information with the specification. The request sender also saves the priority
transaction state. This will be used when handling the answer information with the transaction state. This will be used when
messages. handling the answer messages.
2. Agents handling the request - Agents use the priority information 2. Agents handling the request -- Agents use the priority
when making routing decisions. This can include determining information when making routing decisions. This can include
which requests to route first, which requests to throttle and determining which requests to route first, which requests to
where the request is routed. For instance, requests with higher throttle, and where the request is routed. For instance,
priority might have a lower probability of being throttled. The requests with higher priority might have a lower probability of
mechanism for how the agent determines which requests are being throttled. The mechanism for how the agent determines
candidates to be throttled is implementation dependent and is which requests are candidates to be throttled is implementation
outside the scope of this document. Before forwarding request dependent and is outside the scope of this document. Before
messages, agents generally do not modify the priority information forwarding request messages, agents generally do not modify the
present in the received request message nor include the priority priority information present in the received request message nor
information when absent in the received request message. include the priority information when absent in the received
However, in some scenarios, agents can modify the priority request message. However, in some scenarios, agents can modify
information, for example, edge agents modifying the priority the priority information, for example, edge agents modifying the
values set by an adjacent operator. There might be other priority values set by an adjacent operator. There might be
scenarios where a Diameter endpoint does not support the DRMP other scenarios where a Diameter endpoint does not support the
mechanism and agents insert the priority information in the DRMP mechanism, and agents insert the priority information in the
request messages for that non supporting endpoint. When request messages for that non-supporting endpoint. When
forwarding the request messages, the agent also saves the forwarding the request messages, the agent also saves the
transaction priority in the transaction state, either as locally transaction priority in the transaction state either as locally
managed state or using the Proxy-Info mechanism defined in managed state or using the Proxy-Info mechanism defined in
[RFC6733]. This will be used when handling the associated answer [RFC6733]. This will be used when handling the associated answer
message for the transaction. message for the transaction.
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 the 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. The preferential treatment over lower-priority transactions. The
answer sender also has the option of including priority answer sender also has the option of including priority
information in the answer message. This is done when the answer information in the answer message. This is done when the answer
message needs to have a different priority than the priority message needs to have a different priority than the priority
carried in the request message. The priority included by the carried in the request message. The priority included by the
answer sender is application specific. answer sender is application specific.
5. Agent handling the answer - By default, agents handling answer 5. Agent handling the answer -- By default, agents handling answer
messages use the priority information stored with the transaction messages use the priority information stored with the transaction
state to determine the priority of relaying the answer message. state to determine the priority of relaying the answer message.
However, priority information included in the answer message, However, priority information included in the answer message,
when present, is used in place of the stored priority when present, is used in place of the stored priority
information. The use of priority information implies that information. The use of priority information implies that
answers for higher priority transactions are given preferential answers for higher-priority transactions are given preferential
treatment to lower priority transactions. When forwarding the treatment over lower-priority transactions. When forwarding the
answer messages, agents generally do not modify the priority answer messages, agents generally do not modify the priority
information present in the received answer messages nor include information present in the received answer messages nor include
the priority information when absent in the received answer the priority information when absent in the received answer
messages. However, in some scenarios, agents can modify the messages. However, in some scenarios, agents can modify the
priority information, for example, edge agents modifying the priority information, for example, edge agents modifying the
priority values set by an adjacent operator. There might be priority values set by an adjacent operator. There might be
other scenarios where a Diameter endpoint does not support the other scenarios where a Diameter endpoint does not support the
DRMP mechanism and agents insert the priority information for DRMP mechanism, and agents insert the priority information for
that non-supporting endpoint. that non-supporting endpoint.
6. Answer handler - The answer handler uses the same method as the 6. Answer handler -- The answer handler uses the same method as the
agent to determine the priority of the answer message. By agent to determine the priority of the answer message. By
default the handler of the answer message uses the priority saved default, the handler of the answer message uses the priority
in the transaction's state. Priority information in the answer saved in the transaction's state. Priority information in the
message is used when present. The priority is used when answer message is used when present. The priority is used when
allocating resources for processing that occurs after the receipt allocating resources for processing that occurs after the receipt
of the answer message. of the answer message.
7. Extensibility 7. Extensibility
This document does not define extensibility mechanisms that are This document does not define extensibility mechanisms that are
specific to the DRMP mechanism. As a result, any extension that specific to the DRMP mechanism. As a result, any extension that
requires new AVPs will be required to use existing Diameter requires new AVPs will be required to use existing Diameter
extensibility mechanisms defined in [RFC6733]. extensibility mechanisms defined in [RFC6733].
8. Normative Behavior 8. Normative Behavior
This section contains the normative behavior associated with Diameter This section contains the normative behavior associated with 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 the DRMP AVP in all include Diameter routing message priority in the DRMP AVP in all
Diameter request 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 does not require the Diameter Agents to The priority marking scheme does not require the Diameter Agents to
understand application specific AVPs. understand application-specific AVPs.
When available, Diameter nodes SHOULD use routing priority When available, Diameter nodes SHOULD use routing priority
information included in the DRMP AVP when making Diameter overload information included in the DRMP AVP when making Diameter overload
throttling decisions. throttling decisions.
Diameter agents MAY use routing priority information included in the Diameter Agents MAY use routing priority information included in the
DRMP AVP when relaying request and answer messages. This includes DRMP AVP when relaying request and answer messages. This includes
the selection of routes and the ordering of messages relayed. the selection of routes and the ordering of messages relayed.
Note: The priority information included in the DRMP AVP in request Note: The priority information included in the DRMP AVP in request
messages applies to both the request message and, by default, messages applies to both the request message and, by default, the
answer message associated with the transaction. answer message associated with the transaction.
While done only in exceptional circumstances, Diameter agents MAY While done only in exceptional circumstances, Diameter Agents MAY
modify priority information when relaying request and answer modify priority information when relaying request and answer
messages. messages.
Note: There might be scenarios where a Diameter agent does modify Note: There might be scenarios where a Diameter Agent does modify
priority information. For instance, an edge agent might need to priority information. For instance, an edge agent might need to
modify the priority values set by an adjacent operator. modify the priority values set by an adjacent operator.
While done only in exceptional circumstances, Diameter agents MAY add While done only in exceptional circumstances, Diameter Agents MAY add
priority information when relaying request and answer messages. priority information when relaying request and answer messages.
Note: There might be scenarios where a Diameter endpoint does not Note: There might be scenarios where a Diameter endpoint does not
support the DRMP mechanism and agents insert priority information support the DRMP mechanism, and agents insert priority information
for that non-supporting endpoint. for that non-supporting endpoint.
Diameter endpoints MAY use routing priority information included in Diameter endpoints MAY use routing priority information included in
the DRMP AVP when making resource allocation decisions for the the DRMP AVP when making resource allocation decisions for the
transaction associated with the request message that contains the transaction associated with the request message that contains the
DRMP information. DRMP information.
Diameter endpoints MAY use routing priority information included in Diameter endpoints MAY use routing priority information included in
the DRMP AVP when making resource allocation decisions for the the DRMP AVP when making resource allocation decisions for the
transaction associated with the answer messages using the DRMP transaction associated with the answer messages using the DRMP
information associated with the transaction. information associated with the transaction.
Diameter endpoints MAY include the DRMP AVP in answer messages. This Diameter endpoints MAY include the DRMP AVP in answer messages. This
is done when the priority for the answer message needs to have a is done when the priority for the answer message needs to have a
different priority than the priority carried in the request message. different priority than the priority carried in the request message.
When determining the priority to apply to answer messages, Diameter When determining the priority to apply to answer messages, Diameter
nodes SHOULD use the priority indicated in the DRMP AVP carried in nodes SHOULD use the priority indicated in the DRMP AVP carried in
the answer message, if it exists. If there is not DRMP AVP in the the answer message, if it exists. If there is not DRMP AVP in the
answer message then the Diameter node SHOULD use the priority answer message, then the Diameter node SHOULD use the priority
indicated in the DRMP AVP of the associated request message. indicated in the DRMP AVP of the associated request message.
Note: One method to determine what priority to apply to an answer Note: One method to determine what priority to apply to an answer
when there is no DRMP AVP in the answer message is to save the when there is no DRMP AVP in the answer message is to save the
priority included in the request message in state associated with priority included in the request message in the state associated
the Diameter transaction. Another is to use the Proxy-Info with the Diameter transaction. Another is to use the Proxy-Info
mechanism defined in [RFC6733]. mechanism defined in [RFC6733].
Diameter nodes MUST have a default priority to apply to transactions Diameter nodes MUST have a default priority to apply to transactions
that do not have an explicit priority set in the DRMP AVP. that do not have an explicit priority set in the DRMP AVP.
In order to guaranty consistent handling of messages from nonupgraded In order to guarantee consistent handling of messages from non-
Diameter clients, Diameter nodes SHOULD use the PRIORITY_10 priority upgraded Diameter Clients, Diameter nodes SHOULD use the PRIORITY_10
as this default priority value. priority as this default priority value.
PRIORITY_10 is a mid range priority that corresponds to "normal" PRIORITY_10 is a midrange priority that corresponds to "normal"
traffic and thus would be a suitable default for most deployments, traffic and thus would be a suitable default for most deployments,
while still allowing different Diameter applications to designate while still allowing different Diameter applications to designate
other priorities for lower and higher priority traffic. other priorities for lower- and higher-priority traffic.
Note: This does not imply that a DRMP AVP is added to the message. Note: This does not imply that a DRMP AVP is added to the message.
Rather, the message is treated the same as a message that has a Rather, the message is treated the same as a message that has a
DRMP AVP with priority value of PRIORITY_10. DRMP AVP with a priority value of PRIORITY_10.
Diameter nodes MUST support the ability for the default priority to Diameter nodes MUST support the ability for the default priority to
be modified through local configuration interfaces. be modified through local configuration interfaces.
Note: There are scenarios where operators might want to specify a Note: There are scenarios where operators might want to specify a
different default value for transactions that do not have an different default value for transactions that do not have an
explicit priority. In this case, the operator defined local explicit priority. In this case, the operator-defined local
policy would override the use of PRIORITY_10 as the default policy would override the use of PRIORITY_10 as the default
priority. priority.
When using DRMP priority information, Diameter nodes MUST use the When using DRMP information, Diameter nodes MUST use the default
default priority for transactions that do not have priority specified priority for transactions that do not have priority specified in a
in a DRMP AVP. DRMP AVP.
Note: This guidance on the handling of messages without a priority Note: This guidance on the handling of messages without a priority
does not result in a Diameter agent inserting a DRMP AVP into the does not result in a Diameter Agent inserting a DRMP AVP into the
message. Rather, it gives guidance on how that specific message. Rather, it gives guidance on how that specific
transaction should be treated when its priority is compared with transaction should be treated when its priority is compared with
other requests. When a Diameter agent relays the request it will other requests. When a Diameter Agent relays the request, it will
not insert a DRMP AVP with a priority value of 10. not insert a DRMP AVP with a priority value of 10.
When setting and using priorities, for all integers x,y in [0,15] When setting and using priorities, for all integers x,y in [0,15],
treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x. treat PRIORITY_<x> as lower priority than PRIORITY_<y> when y<x.
Note: As a result PRIORITY_0 is the highest priority. Note: As a result, PRIORITY_0 is the highest priority.
9. Attribute Value Pairs 9. 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 Pair (AVP) defined in this Routing Message Priority AVP defined in this document.
document.
9.1. DRMP AVP 9.1. DRMP AVP
The DRMP (AVP code TBD1) is of type Enumerated. The value of the AVP The DRMP (AVP code 301) 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 defined: following values are defined:
PRIORITY_15 15 PRIORITY_15 is the lowest priority. PRIORITY_15 15 PRIORITY_15 is the lowest priority.
PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and PRIORITY_14 14 PRIORITY_14 is a higher priority than PRIORITY_15 and
a lower priority than PRIORITY_13. a lower priority than PRIORITY_13.
PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and PRIORITY_13 13 PRIORITY_13 is a higher priority than PRIORITY_14 and
a lower priority than PRIORITY_12. a lower priority than PRIORITY_12.
skipping to change at page 13, line 31 skipping to change at page 13, line 34
lower priority than PRIORITY_2. lower priority than PRIORITY_2.
PRIORITY_2 2 PRIORITY_2 is a higher priority than PRIORITY_3 and a PRIORITY_2 2 PRIORITY_2 is a higher priority than PRIORITY_3 and a
lower priority than PRIORITY_1. lower priority than PRIORITY_1.
PRIORITY_1 1 PRIORITY_1 is a higher priority than PRIORITY_2 and a PRIORITY_1 1 PRIORITY_1 is a higher priority than PRIORITY_2 and a
lower priority than PRIORITY_0. lower priority than PRIORITY_0.
PRIORITY_0 0 Priority 0 is the highest priority. PRIORITY_0 0 Priority 0 is the highest priority.
9.2. Attribute Value Pair flag rules 9.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 x.x Enumerated | | V | |DRMP 301 9.1 Enumerated | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
10. Considerations When Defining Application Priorities 10. Considerations When Defining Application Priorities
As discussed in Section 1.1, it is important that the definition of As discussed in Section 1.1, it is important that the definition of
priority values used by all applications within a single Diameter priority values used by all applications within a single Diameter
administrative domain be done in a consistent and coordinated manner. administrative domain be done in a consistent and coordinated manner.
The following are some things to be considered when defining the DRMP The following are some things to be considered when defining the
priorities to be used in Diameter networks which support Diameter DRMPs to be used in Diameter networks that support Diameter nodes
nodes handling multiple applications. handling multiple applications.
1. As with any prioritization scheme, it is possible for higher 1. As with any prioritization scheme, it is possible for higher-
priority messages to block lower priority messages from ever priority messages to block lower-priority messages from ever
being handled. In a Diameter network this will often result in being handled. In a Diameter network, this will often result in
those Diameter transactions being retried. This can result in those Diameter transactions being retried. This can result in
more traffic than the network would have handled without use of more traffic than the network would have handled without use of
the DRMP mechanism. the DRMP mechanism.
One potential guideline to prevent unwanted starving of lower One potential guideline to prevent unwanted starving of lower-
priority messages is to have higher priority messages represent a priority messages is to have higher-priority messages represent a
relatively small portion of messages handled by the Diameter relatively small portion of messages handled by the Diameter
network under normal scenarios. network under normal scenarios.
Note that there are scenarios, such as first responder Note that there are scenarios, such as first responder
messages, where the blocking of lower priority messages is a messages, where the blocking of lower-priority messages is a
requirement. requirement.
2. When setting priorities for any of the use cases outlined in 2. When setting priorities for any of the use cases outlined in
Section 5 it is important to use the same priority values across Section 5, it is important to use the same priority values across
applications. For instance, when defining priority for the First applications. For instance, when defining priority for the first
Responder use case discussed in Section 5.1 and the Emergency responder use case discussed in Section 5.1 and the emergency
call use case discussed in Section 5.2 use cases, one high call use case discussed in Section 5.2, one high-priority value
priority value might be used for all first responder messages, might be used for all first responder messages, say PRIORITY_2,
say PRIORITY_2, and a slightly lower priority value, say and a slightly lower-priority value, say PRIORITY_3, might be
PRIORITY_3, might be used for emergency call related messages. used for emergency-call-related messages. These values should be
These values should be specified for these use cases across all specified for these use cases across all applications used within
applications used within the Diameter administrative domain. the Diameter administrative domain.
Note that the values mentioned here are strictly for Note that the values mentioned here are strictly for
illustrative purposes. The actual values used for these use illustrative purposes. The actual values used for these use
cases are likely to be different. cases are likely to be different.
3. Messages without the DRMP AVP will be given default priority 3. Messages without the DRMP AVP will be given default priority
value threatment. This will include messages from Diameter value treatment. This will include messages from Diameter
Clients that have not been updated to support the DRMP mechanism. Clients that have not been updated to support the DRMP mechanism.
It might also include messages from foreign administrative It might also include messages from foreign administrative
domains if the DRMP AVPs are stripped from messages crossing the domains if the DRMP AVPs are stripped from messages crossing the
Diameter administrative domains. Diameter administrative domains.
4. The process used to introduce the DRMP mechanism into a Diameter 4. The process used to introduce the DRMP mechanism into a Diameter
network should also be taken into consideration. Messages of the network should also be taken into consideration. Messages of the
same type within the same application might get different same type within the same application might get different
treatment depending on whether those messages are sent from nodes treatment depending on whether those messages are sent from nodes
that are upgraded to support the DRMP mechanism versus nodes that that are upgraded to support the DRMP mechanism versus nodes that
have not yet been upgraded to support the DRMP mechanism. have not yet been upgraded to support the DRMP mechanism.
11. IANA Considerations 11. IANA Considerations
11.1. AVP codes 11.1. AVP Codes
The new AVP defined by this specification is listed in Section 9. The new AVP defined by this specification is listed in Section 9.
All AVP codes are allocated from the 'Authentication, Authorization, All AVP codes are allocated from the "AVP Codes" subregistry of the
and Accounting (AAA) Parameters' AVP Codes registry. "Authentication, Authorization, and Accounting (AAA) Parameters"
registry.
11.2. New registries
There are no new IANA registries introduced by this document.
12. Security Considerations 12. Security Considerations
DRMP gives Diameter nodes the ability to influence which requests are DRMP gives Diameter nodes the ability to influence which requests are
throttled during overload scenarios. In addition, DRMP can be used throttled during overload scenarios. In addition, DRMP can be used
in determining the routing decisions for request messages. Improper in determining the routing decisions for request messages. Improper
use of the DRMP mechanism could result in the malicious Diameter node use of the DRMP mechanism could result in the malicious Diameter node
gaining preferential treatment, by reducing the probability of its gaining preferential treatment, by reducing the probability of its
requests being throttled, over other Diameter nodes. This would be requests being throttled, over other Diameter nodes. This would be
achieved by the malicious node inserting artificially high priority achieved by the malicious node inserting priority values that are
values. artificially high.
Diameter does not include features to provide end-to-end Diameter does not include features to provide end-to-end
authentication, integrity protection, or confidentiality. This opens authentication, integrity protection, or confidentiality. This opens
the possibility that malicious or compromised agents in the path of a the possibility that malicious or compromised agents in the path of a
request could modify the DRMP AVP to reflect a priority different request could modify the DRMP AVP to reflect a priority different
than that asserted by the sender of the request. than that asserted by the sender of the request.
12.1. Potential Threat Modes 12.1. Potential Threat Modes
The Diameter protocol involves transactions in the form of requests The Diameter protocol involves transactions in the form of requests
and answers exchanged between clients and servers. These clients and and answers exchanged between clients and servers. These clients and
servers may be peers, that is, they may share a direct transport servers may be peers; that is, they may share a direct transport
(e.g., Transmission Control Protocol (TCP) or Stream Control (e.g., the Transmission Control Protocol (TCP) or Stream Control
Transmission Protocol (SCTP)) connection, or the messages may Transmission Protocol (SCTP)) connection, or the messages may
traverse one or more intermediaries, known as Diameter Agents. traverse one or more intermediaries, known as Diameter Agents.
Diameter nodes use Transport Layer Security (TLS), Datagram Transport Diameter nodes use Transport Layer Security (TLS), Datagram Transport
Layer Security (DTLS), or IPsec to authenticate peers, and to provide Layer Security (DTLS), or IPsec to authenticate peers and to provide
confidentiality and integrity protection of traffic between peers. confidentiality and integrity protection of traffic between peers.
Nodes can make authorization decisions based on the peer identities Nodes can make authorization decisions based on the peer identities
authenticated at the transport layer. authenticated at the transport layer.
When agents are involved, this presents an effectively transitive When agents are involved, this presents an effectively transitive
trust model. That is, a Diameter client or server can authorize an trust model. That is, a Diameter Client or Server can authorize an
agent for certain actions, but it must trust that agent to make agent for certain actions, but it must trust that agent to make
appropriate authorization decisions about its peers, and so on. appropriate authorization decisions about its peers, and so on.
Since confidentiality and integrity protection occurs at the Since confidentiality and integrity protection occurs at the
transport layer, agents can read, and perhaps modify, any part of a transport layer, agents can read, and perhaps modify, any part of a
Diameter message, including the DRMP AVP. Diameter message, including the DRMP AVP.
There are several ways an attacker might attempt to exploit the DRMP There are several ways an attacker might attempt to exploit the DRMP
mechanism. A malicious or compromised Diameter node might insert mechanism. A malicious or compromised Diameter node might insert
invalid priority values resulting in either preferential treatment, invalid priority values resulting in either preferential treatment,
resulting from higher values, or degraded treatment resulting from resulting from higher values, or degraded treatment resulting from
lower values, for that node. lower values, for that node.
A similar attack involves a malicious or compromised Diameter agent A similar attack involves a malicious or compromised Diameter Agent
changing the priority value resulting in the sending Diameter node changing the priority value resulting in the sending Diameter node
getting either preferential or degraded service. getting either preferential or degraded service.
The DRMP mechanism can be used to aid in overload throttling The DRMP mechanism can be used to aid in overload throttling
decisions. When this is the case then the above attacks are limited decisions. When this is the case, then the above attacks are limited
in scope to when one or more Diameter nodes are in an overloaded in scope to when one or more Diameter nodes are in an overloaded
state. state.
The DRMP mechanism can also be used to influence the order in which The DRMP mechanism can also be used to influence the order in which
Diameter messages are handled by Diameter nodes. The above attacks Diameter messages are handled by Diameter nodes. The above attacks
have a potentially greater impact in this scenario as the priority have a potentially greater impact in this scenario as the priority
indication impacts the handling of all requests at all times, indication impacts the handling of all requests at all times,
independent of the overload status of Diameter nodes in the Diameter independent of the overload status of Diameter nodes in the Diameter
network. network.
12.2. Denial of Service Attacks 12.2. Denial-of-Service Attacks
The DRMP mechanism does not open direct denial of service attack The DRMP mechanism does not open direct denial-of-service attack
vectors. Rather, it introduces a mechanism where a node can gain vectors. Rather, it introduces a mechanism where a node can gain
unwarranted preferential treatment. It also introduces a mechanism unwarranted preferential treatment. It also introduces a mechanism
where a node can get degraded service in the scenario where a rogue where a node can get degraded service in the scenario where a rogue
agent changes the priority value included in messages. agent changes the priority value included in messages.
12.3. End-to End-Security Issues 12.3. End-to-End Security Issues
The lack of end-to-end integrity features in Diameter [RFC6733] makes The lack of end-to-end integrity features in Diameter [RFC6733] makes
it difficult to establish trust in DRMP AVPs received from non- it difficult to establish trust in DRMP AVPs received from non-
adjacent nodes. Any agents in the message path may insert or modify adjacent nodes. Any agents in the message path may insert or modify
DRMP AVPs. Nodes must trust that their adjacent peers perform proper DRMP AVPs. Nodes must trust that their adjacent peers perform proper
checks on overload reports from their peers, and so on, creating a checks on overload reports from their peers, and so on, creating a
transitive-trust requirement extending for potentially long chains of transitive-trust requirement extending for potentially long chains of
nodes. Network operators must determine if this transitive trust nodes. Network operators must determine if this transitive trust
requirement is acceptable for their deployments. Nodes supporting requirement is acceptable for their deployments. Nodes supporting
DRMP MUST give operators the ability to select which peers are DRMP MUST give operators the ability to select which peers are
trusted to deliver DRMP AVPs, and whether they are trusted to forward trusted to deliver DRMP AVPs, and whether they are trusted to forward
the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip
DRMP AVPs from messages received from peers that are not trusted for DRMP AVPs from messages received from peers that are not trusted for
DRMP purposes. DRMP purposes.
It is expected that work on end-to-end Diameter security might make It is expected that work on end-to-end Diameter security might make
it easier to establish trust in non-adjacent nodes for DRMP purposes. it easier to establish trust in non-adjacent nodes for DRMP purposes.
Readers should be reminded, however, that the DRMP mechanism allows Readers should be reminded, however, that the DRMP mechanism allows
Diameter agents to modify AVPs in existing messages that are Diameter Agents to modify AVPs in existing messages that are
originated by other nodes. If end-to-end security is enabled, there originated by other nodes. If end-to-end security is enabled, there
is a risk that such modification could violate integrity protection. is a risk that such modification could violate integrity protection.
The details of using any future Diameter end-to-end security The details of using any future Diameter end-to-end security
mechanism with DRMP will require careful consideration, and are mechanism with DRMP will require careful consideration and are beyond
beyond the scope of this document. the scope of this document.
13. Contributors
The following people contributed substantial ideas, feedback, and
discussion to this document:
o Janet P. Gunn
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>. <http://www.rfc-editor.org/info/rfc6733>.
14.2. Informative References 13.2. Informative References
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L. [RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance", Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015, RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>. <http://www.rfc-editor.org/info/rfc7683>.
[S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management [S6a] 3GPP, "Evolved Packet System (EPS); Mobility Management
Entity (MME) and Serving GPRS Support Node (SGSN) related Entity (MME) and Serving GPRS Support Node (SGSN) related
interfaces based on Diameter protocol", 3GPP TS 29.272 interfaces based on Diameter protocol", 3GPP TS
10.8.0, June 2013. 29.272, 14.0.0, June 2016,
<http://www.3gpp.org/ftp/Specs/html-info/29272.htm>.
Contributors
The following person contributed substantial ideas, feedback, and
discussion to this document:
o Janet P. Gunn
Author's Address Author's Address
Steve Donovan Steve Donovan
Oracle Oracle
7460 Warren Parkway 7460 Warren Parkway
Frisco, Texas 75034 Frisco, Texas 75034
United States United States of America
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
 End of changes. 103 change blocks. 
228 lines changed or deleted 218 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/