< 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/ |