draft-ietf-dime-drmp-03.txt   draft-ietf-dime-drmp-04.txt 
Diameter Maintenance and Extensions (DIME) S. Donovan Diameter Maintenance and Extensions (DIME) S. Donovan
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track February 2, 2016 Intended status: Standards Track March 10, 2016
Expires: August 5, 2016 Expires: September 11, 2016
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-03.txt draft-ietf-dime-drmp-04.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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2016. This Internet-Draft will expire on September 11, 2016.
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 20 skipping to change at page 2, line 20
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. First Responder Related Signaling . . . . . . . . . . . . 5 5.1. First Responder Related Signaling . . . . . . . . . . . . 5
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 6
5.4. Application Specific Priorities . . . . . . . . . . . . . 6 5.4. Application Specific Priorities . . . . . . . . . . . . . 6
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 9
9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11
9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12 9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 12
10.2. New registries . . . . . . . . . . . . . . . . . . . . . 13 10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13 11.1. Potential Threat Modes . . . . . . . . . . . . . . . . . 13
11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14 11.2. Denial of Service Attacks . . . . . . . . . . . . . . . 14
11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14 11.3. End-to End-Security Issues . . . . . . . . . . . . . . . 14
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The DOIC solution [RFC7683] for Diameter overload control introduces The DOIC solution [RFC7683] for Diameter overload control introduces
scenarios where Diameter routing decisions made by Diameter nodes can scenarios where Diameter routing decisions made by Diameter nodes can
be influenced by the overload state of other Diameter nodes. This be influenced by the overload state of other Diameter nodes. This
includes the scenarios where Diameter endpoints and Diameter agents includes the scenarios where Diameter endpoints and Diameter agents
can throttle requests as a result of the target for the request being can throttle requests as a result of the target for the request being
overloaded. overloaded.
skipping to change at page 7, line 6 skipping to change at page 6, line 52
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 involve different application command codes. In this
scenario it is requests with the same command code that have scenario it is requests with the same command code that have
different implied priorities. different implied priorities.
One example of this is in the 3GPP application [S6a] where a ULR One example of this is in the 3GPP application [S6a] where a ULR
request resulting from an MME restoration procedure might be given request resulting from an MME (Mobility Management Entity)
a higher priority than a ULR resulting from an initial attach. restoration procedure might be given a higher priority than a ULR
(Update Location Request) resulting 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 Client
or a Diameter Server, determines the relative priority of the or a Diameter Server, determines the relative priority of the
request and includes that priority information in the request. request and includes that priority information in the request.
The method for determining the relative priority is application The method for determining the relative priority is application
specific and is outside the scope of this specification. The specific and is outside the scope of this specification. The
request sender also saves the priority information with the request sender also saves the priority information with the
transaction state. This will be used when handling the answer transaction state. This will be used when handling the answer
messages. messages.
2. Agents handing the request - Agents use the priority information 2. Agents handling the request - Agents use the priority information
when making routing decisions. This can include determining when making routing decisions. This can include determining
which requests to route first, which requests to throttle and which requests to route first, which requests to throttle and
where the request is routed. For instance, requests with higher where the request is routed. For instance, requests with higher
priority might have a lower probability of being throttled. The priority might have a lower probability of being throttled. The
mechanism for how the agent determines which requests are mechanism for how the agent determines which requests are
throttled is implementation dependent and is outside the scope of throttled is implementation dependent and is outside the scope of
this document. The agent also saves the transaction priority in this document. Before forwarding request messages, agents
the transaction state, either as locally managed state or using generally do not modify the priority information present in the
the Proxy-Info mechanism defined in [RFC6733]. This will be used received request message nor include the priority information
when handling the associated answer message for the transaction. when absent in the received request message. However, in some
scenarios, agents can modify the priority information, for
example, edge agents modifying the priority values set by an
adjacent operator. There might be other scenarios where a
Diameter endpoint does not support the DRMP mechanism and agents
insert the priority information in the request messages for that
non supporting endpoint. When forwarding the request messages,
the agent also saves the transaction priority in the transaction
state, either as locally managed state or using the Proxy-Info
mechanism defined in [RFC6733]. 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 3. Request handler - The handler of the request, be it a Diameter
Server or a Diameter Client, can use the priority information to Server or a Diameter Client, can use the priority information to
determine how to handle the request. This could include determine how to handle the request. This could include
determining the order in which requests are handled and resources determining the order in which requests are handled and resources
that are applied to handling of the request. that are applied to handling of the request.
4. Answer sender - The handler of the request is also the sender of 4. Answer sender - The handler of the request is also the sender of
the answer. The answer sender uses the priority information the answer. The answer sender uses the priority information
received in the request message when sending the answer. This received in the request message when sending the answer. This
skipping to change at page 8, line 15 skipping to change at page 8, line 25
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. treatment to lower priority transactions. When forwarding the
answer messages, agents generally do not modify the priority
information present in the received answer messages nor include
the priority information when absent in the received answer
messages. However, in some scenarios, agents can modify the
priority information, for example, edge agents modifying the
priority values set by an adjacent operator. There might be
other scenarios where a Diameter endpoint does not support the
DRMP mechanism and agents insert the priority information for
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 saved
in the transaction's state. Priority information in the answer in the transaction's state. Priority information in the answer
message is used when present. The priority is used when 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
skipping to change at page 8, line 45 skipping to change at page 9, line 18
Resource Message Priority (DRMP). Resource Message Priority (DRMP).
When routing priority information is available, Diameter nodes SHOULD When routing priority information is available, Diameter nodes SHOULD
include Diameter routing message priority in 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 SHOULD 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.
The priority information included in the DRMP AVP in request 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,
answer message associated with the transaction. answer message associated with the transaction.
While done only in exceptional circumstances, Diameter agents MAY
modify priority information when relaying request and answer
messages.
There might be scenarios where a Diameter agent does modify
priority information. For instance, an edge agent might need to
modify the priority values set by an adjacent operator.
While done only in exceptional circumstances, Diameter agents MAY add
priority information when relaying request and answer messages.
There might be scenarios where a Diameter endpoint does not
support the DRMP mechanism and agents insert priority information
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.
skipping to change at page 10, line 16 skipping to change at page 11, line 5
default priority for transactions that do not have priority specified default priority for transactions that do not have priority specified
in a DRMP AVP. in a 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, PRIORITY_0 MUST be treated as the When setting and using priorities, for all integers x,y in [0,15]
highest priority. treat PRIORITY_<x> as lower priority than PRIOIRTY_<y> when y<x.
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.
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 Note: As a result PRIORITY_0 is the highest priority.
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 Pairs (AVPs) defined in this Overload Indication Attribute Value Pairs (AVPs) 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 TBD1) is of type Enumerated. The value of the AVP
skipping to change at page 13, line 25 skipping to change at page 13, line 7
DRMP gives Diameter nodes the ability to influence which requests are DRMP gives Diameter nodes the ability to influence which requests are
are throttled during overload scenarios. Improper use of the DRMP are throttled during overload scenarios. Improper use of the DRMP
mechanism could result in the malicious Diameter node gaining mechanism could result in the malicious Diameter node gaining
preferential treatment, by reducing the probability of its requests preferential treatment, by reducing the probability of its requests
being throttled, over other Diameter nodes. This would be achieved being throttled, over other Diameter nodes. This would be achieved
by the malicious node inserting artificially high priority values. by the malicious node inserting artificially high priority values.
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 agents in the path of a request could modify the the possibility that malicious or compromised agents in the path of a
DRMP AVP to reflect a priority different than that asserted by the request could modify the DRMP AVP to reflect a priority different
sender of the request. than that asserted by the sender of the request.
11.1. Potential Threat Modes 11.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., TCP or SCTP) connection, or the messages may traverse one or (e.g., TCP or SCTP) connection, or the messages may traverse one or
more intermediaries, known as Diameter Agents. Diameter nodes use more intermediaries, known as Diameter Agents. Diameter nodes use
TLS, DTLS, or IPsec to authenticate peers, and to provide TLS, 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.
skipping to change at page 15, line 25 skipping to change at page 15, line 5
13. References 13. References
13.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>.
[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, [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>.
13.2. Informative References 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. [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 29.272
10.8.0, June 2013. 10.8.0, June 2013.
 End of changes. 18 change blocks. 
86 lines changed or deleted 62 lines changed or added

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