draft-ietf-dime-drmp-01.txt   draft-ietf-dime-drmp-02.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 October 12, 2015 Intended status: Standards Track November 11, 2015
Expires: April 14, 2016 Expires: May 14, 2016
Diameter Routing Message Priority Diameter Routing Message Priority
draft-ietf-dime-drmp-01.txt draft-ietf-dime-drmp-02.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 April 14, 2016. This Internet-Draft will expire on May 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. First Responder Related Signaling . . . . . . . . . . . . 5 5.1. First Responder Related Signaling . . . . . . . . . . . . 5
5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5 5.2. Emergency Call Related Signaling . . . . . . . . . . . . 5
5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 5.3. Differentiated Services . . . . . . . . . . . . . . . . . 5
5.4. Application Specific Priorities . . . . . . . . . . . . . 6 5.4. Application Specific Priorities . . . . . . . . . . . . . 6
6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
7. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11 8. Normative Behavior . . . . . . . . . . . . . . . . . . . . . 8
8.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 11
8.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12 9.1. DRMP AVP . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9.2. Attribute Value Pair flag rules . . . . . . . . . . . . . 12
9.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.2. New registries . . . . . . . . . . . . . . . . . . . . . 12 10.1. AVP codes . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10.2. New registries . . . . . . . . . . . . . . . . . . . . . 12
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Design Considerations and Questions . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 13
A.1. Relationship with SIP Resource Priority . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
A.2. Priority Encoding Method . . . . . . . . . . . . . . . . 14
A.3. Base Protocol versus Application Extension . . . . . . . 15
A.4. Scope of Priority Setting . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The DOIC solution [I-D.ietf-dime-ovli] for Diameter overload control The DOIC solution [RFC7683] for Diameter overload control introduces
introduces scenarios where Diameter routing decisions made by scenarios where Diameter routing decisions made by Diameter nodes can
Diameter nodes can be influenced by the overload state of other be influenced by the overload state of other Diameter nodes. This
Diameter nodes. This includes the scenarios where Diameter endpoints includes the scenarios where Diameter endpoints and Diameter agents
and Diameter agents can throttle requests as a result of the target can throttle requests as a result of the target for the request being
for the request being overloaded. 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 during a probability of transactions involving first responders during a
skipping to change at page 3, line 20 skipping to change at page 3, line 16
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.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
Diversion Diversion
As defined in [I-D.ietf-dime-ovli]. An overload abatement As defined in [RFC7683]. An overload abatement treatment where
treatment where the reacting node selects alternate destinations the reacting node selects alternate destinations or paths for
or paths for requests. requests.
DOIC DOIC
Diameter Overload Indication Conveyance. Diameter Overload Indication Conveyance.
DRMP DRMP
Diameter Routing Message Priority. Diameter Routing Message Priority.
Overload Abatement Overload Abatement
As defined in [I-D.ietf-dime-ovli]. Reaction to receipt of an As defined in [RFC7683]. Reaction to receipt of an overload
overload report resulting in a reduction in traffic sent to the report resulting in a reduction in traffic sent to the reporting
reporting node. Abatement actions include diversion and node. Abatement actions include diversion and throttling.
throttling.
Priority Priority
The relative importance of a Diameter message. A higher 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 [I-D.ietf-dime-ovli]. An abatement treatment that As defined in [RFC7683]. An abatement treatment that limits the
limits the number of requests sent by the DIOC reacting node. number of requests sent by the DIOC reacting node. Throttling can
Throttling can include a Diameter Client choosing to not send include a Diameter Client choosing to not send requests, or a
requests, or a Diameter Agent or Server rejecting requests with Diameter Agent or Server rejecting requests with appropriate error
appropriate error responses. In both cases the result of the responses. In both cases the result of the throttling is a
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 RFC 2119 [RFC2119].
RFC 2119 [RFC2119] interpretation does not apply for the above listed RFC 2119 [RFC2119] interpretation 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 format.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
treatment to lower priority transactions. treatment to lower priority transactions.
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 of default the handler of the answer message uses the priority of
the transaction. Priority information in the answer message is the transaction. Priority information in the answer message is
used when present. The priority is used when allocating used when present. The priority is used when allocating
resources for processing that occurs after the receipt of the resources for processing that occurs after the receipt of the
answer message. answer message.
7. Normative Behavior 7. Extensibility
This document does not define extensibility mechanisms that are
specific to the DRMP mechanism. As a result, any extension that
requires new AVPs will be required to use existing Diameter
extensibility mechanisms defined in [RFC6733]
8. Normative Behavior
This section contains the normative behavior associated with Diameter This section contains the normative behavior associated with Diameter
Resource Message Priority (DRMP). Resource Message Priority (DRMP).
When routing priority information is available, Diameter nodes SHOULD When routing priority information is available, Diameter nodes SHOULD
include Diameter routing message priority in 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 SHOULD 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 reqeust 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.
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.
skipping to change at page 9, line 20 skipping to change at page 9, line 29
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 MUST use the priority indicated in the DRMP AVP carried in the nodes MUST use the priority indicated in the DRMP AVP carried in the
answer message, if it exists. Otherwise, the Diameter node MUST use answer message, if it exists. Otherwise, the Diameter node MUST use
the priority indicated in the DRMP AVP of the associated request the priority indicated in the DRMP AVP of the associated request
message. message.
When there is a mix of transactions specifying priority in request Diameter nodes MUST have a default priority to apply to transactions
messages and transactions that do not have the priority specified, that do not have an explicit priority set in the DRMP AVP.
transactions that do not have a specified priority SHOULD be treated
as having the PRIORITY_14 priority.
Editor's Note: There are four options identified for defining the
default priority for transactions that do not have a priority
specified in in the request message.
1 - Make it operater defined local policy.
2 - Make it the lowest priority. This has issues in that it does Diameter nodes SHOULD use the PRIORITY_10 priority as this default
not allow for a Diameter node to explicitly indicate that a value.
transaction is to have a lower priority than the default priority.
3 - Make one of the middle priorities, such as PRIORITY_8, the Diameter nodes MUST support the ability for the default priority to
default priority. This effectively forces half of the priorities be modified through local configuration interfaces.
to be lower than the default priority.
4 - Make the default priority one greater than the lowest Note: There are scenarios where operators might want to specify a
different default value for transactions that do not have an
explicit priority. In this case, the operator defined local
policy would override the use of PRIORITY_10 as the default
priority. priority.
The current version of this draft proposes using option 4. This When using DRMP priority information, Diameter nodes MUST use the
needs to be verified to be the preferred approach. default priority for transactions that do not have priority specified
in a DRMP AVP.
Note: This guidance on the handling of messages without a priority
does not result in a Diameter agent inserting a DRMP AVP into the
message. Rather, it gives guidance on how that specific
transaction should be treated when its priority is compared with
other requests. When a Diameter agent relays the request it will
not insert a DRMP AVP with a priority value of 10.
When setting and using priorities, PRIORITY_0 MUST be treated as the When setting and using priorities, PRIORITY_0 MUST be treated as the
highest priority. highest priority.
When setting and using priorities, PRIORITY_1 MUST be treated as a When setting and using priorities, PRIORITY_1 MUST be treated as a
lower priority than PRIORITY_0 and a higher priority than PRIORITY_2. lower priority than PRIORITY_0 and a higher priority than PRIORITY_2.
When setting and using priorities, PRIORITY_2 MUST be treated as a When setting and using priorities, PRIORITY_2 MUST be treated as a
lower priority than PRIORITY_1 and a higher priority than PRIORITY_3. lower priority than PRIORITY_1 and a higher priority than PRIORITY_3.
skipping to change at page 11, line 5 skipping to change at page 11, line 16
lower priority than PRIORITY_12 and a higher priority than lower priority than PRIORITY_12 and a higher priority than
PRIORITY_14. PRIORITY_14.
When setting and using priorities, PRIORITY_14 MUST be treated as a When setting and using priorities, PRIORITY_14 MUST be treated as a
lower priority than PRIORITY_13 and a higher priority than lower priority than PRIORITY_13 and a higher priority than
PRIORITY_15. PRIORITY_15.
When setting and using priorities, PRIORITY_15 MUST be the lowest When setting and using priorities, PRIORITY_15 MUST be the lowest
priority. priority.
8. 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.
8.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
indicates the routing message priority for the transaction. The indicates the routing message priority for the transaction. The
following values are initially defined: following values are initially defined:
PRIORITY_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.
skipping to change at page 12, line 16 skipping to change at page 12, line 25
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.
8.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 TBD1 x.x Enumerated | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------+----+----+
9. IANA Considerations 10. IANA Considerations
9.1. AVP codes 10.1. AVP codes
New AVPs defined by this specification are listed in Section 8. All New AVPs defined by this specification are listed in Section 9. All
AVP codes are allocated from the 'Authentication, Authorization, and AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
9.2. New registries 10.2. New registries
There are no new IANA registries introduced by this document. There are no new IANA registries introduced by this document.
Editor's Note: The current assumption is that there is no need to 11. Security Considerations
extend the number of priorities beyond the five defined in this
specification. This assumption needs to be verified. If there is
the need for extensibility then a new IANA registry would be
required. This new registry would be established as part of the
standardization effort associated with the definition of new
priority values.
10. Security Considerations
The DRMP could be used to get better access to services. This could The DRMP could be used to get better access to services. This could
result in one segment of a Diameter network gaining assess to result in one segment of a Diameter network gaining assess to
services that would otherwise be given to other segments of the services that would otherwise be given to other segments of the
Diamter network. Diamter network.
11. Contributors 12. Contributors
The following people contributed substantial ideas, feedback, and The following people contributed substantial ideas, feedback, and
discussion to this document: discussion to this document:
o Janet P. Gunn o Janet P. Gunn
12. References 13. References
12.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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <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>.
12.2. Informative References 13.2. Informative References
[I-D.ietf-dime-ovli]
Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
"Diameter Overload Indication Conveyance", draft-ietf-
dime-ovli-08 (work in progress), February 2015.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, DOI 10.17487/RFC4412, February 2006, RFC 4412, DOI 10.17487/RFC4412, February 2006,
<http://www.rfc-editor.org/info/rfc4412>. <http://www.rfc-editor.org/info/rfc4412>.
[RFC7683] Korhonen, J., Ed., Donovan, S., Ed., Campbell, B., and L.
Morand, "Diameter Overload Indication Conveyance",
RFC 7683, DOI 10.17487/RFC7683, October 2015,
<http://www.rfc-editor.org/info/rfc7683>.
[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.
Appendix A. Design Considerations and Questions
This section contains a list of questions that will influence the
design of the DRMP mechanism. It is expected that this section will
be removed once the DRMP mechanism is defined.
A.1. Relationship with SIP Resource Priority
Question 1: Is there value with aligning the Diameter Routing Message
Priority design with the SIP Resource Priority [RFC4412]work?
Current thoughts: SIP Resource Priority is considered to be
addressing a superset of the requirements that DRMP addresses. The
consensus seems to be that there is no need for multiple name spaces
with DRMP.
Question 2: If so, is there value in reusing the existing SIP
Resource Priority name spaces and request handling strategies?
Current thoughts: Given that the direction for DRMP is to have a
single set of priority values, DRMP will not reuse name spaces.
A.2. Priority Encoding Method
Question 3: Is there a preference for handling DRMP by introducing
AVPs or by using existing bits in the Diameter Command Flags field?
Current thoughts: The advantage of using bits in the Command Flags
field is that it would reduce parsing overhead for elements that need
access to the routing priority information. The question is whether
this optimization in parsing overhead is worth the expense of using
the reserved bits.
There are four bits remaining in the Command Flags header. If this
approach is taken then the expectation would be that three of the
bits would be used, allowing for eight priority levels.
This approach has questionable utility if multiple namespaces are to
be used as the namespace identity would still require an AVP. Once
the requirement for parsing the namespace AVP is introduced the
incremental savings from utilizing the Command Flags would be
minimal.
The current direction is to use AVPs to communicate priority. This
gives the ability to extend the DRMP mechanism if additional
functionality, such as name spaces, is determined to be required.
A.3. Base Protocol versus Application Extension
Question 4: Should DRMP be base protocol behavior or should Diameter
applications be required to explicitly incorporate DRMP behavior?
The direction is to make the behavior generic across all
applications.
A.4. Scope of Priority Setting
Question 5: Which of the following does the DRMP priority apply to:
Messages - meaning that a separate priority can be set for request
messages and answer messages?
Transactions - meaning that the priority set in the request
message also applies to the answer messages?
Request messages - meaning that answer message priority always has
an implied higher priority than all request messages?
Current thoughts: The consensus is to have the DRMP priority apply to
transactions.
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
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
 End of changes. 30 change blocks. 
159 lines changed or deleted 83 lines changed or added

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