draft-ietf-dime-load-01.txt   draft-ietf-dime-load-02.txt 
Internet Engineering Task Force B. Campbell Internet Engineering Task Force B. Campbell
Internet-Draft S. Donovan, Ed. Internet-Draft S. Donovan, Ed.
Intended status: Informational Oracle Intended status: Standards Track Oracle
Expires: April 14, 2016 JJ. Trottin Expires: September 19, 2016 JJ. Trottin
Alcatel-Lucent Nokia
October 12, 2015 March 18, 2016
Diameter Load Information Conveyance Diameter Load Information Conveyance
draft-ietf-dime-load-01 draft-ietf-dime-load-02
Abstract Abstract
This document defines a mechanism for sharing of Diameter load This document defines a mechanism for sharing of Diameter load
information. RFC 7068 describes requirements for Overload Control in information. [RFC7068] describes requirements for Overload Control
Diameter. This includes a requirement to allow Diameter nodes to in Diameter. This includes a requirement to allow Diameter nodes to
send "load" information, even when the node is not overloaded. The send "load" information, even when the node is not overloaded. The
Diameter Overload Information Conveyance (DOIC) solution describes a Diameter Overload Information Conveyance (DOIC) [RFC7683] solution
mechanism meeting most of the requirements, but does not currently describes a mechanism meeting most of the requirements, but does not
include the ability to send load information. currently include the ability to send load information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Differences between Load and Overload information . . . . 4 4.1. Differences between Load and Overload information . . . . 4
4.2. How is Load Information Used? . . . . . . . . . . . . . . 5 4.2. How is Load Information Used? . . . . . . . . . . . . . . 5
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 7 5.1. Theory of Operation . . . . . . . . . . . . . . . . . . . 7
6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 9 6. Load Mechanism Procedures . . . . . . . . . . . . . . . . . . 10
6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 9 6.1. Reporting Node Behavior . . . . . . . . . . . . . . . . . 10
6.1.1. End-point Reporting Node Behavior . . . . . . . . . . 10 6.1.1. Endpoint Reporting Node Behavior . . . . . . . . . . 10
6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 10 6.1.2. Agent Reporting Node Behavior . . . . . . . . . . . . 11
6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11 6.2. Receiving Node Behavior . . . . . . . . . . . . . . . . . 11
6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 6.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 12 7. Attribute Value Pairs . . . . . . . . . . . . . . . . . . . . 13
7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Load AVP . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Load-Type AVP . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13 7.3. Load-Value AVP . . . . . . . . . . . . . . . . . . . . . 13
7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 13 7.4. SourceID AVP . . . . . . . . . . . . . . . . . . . . . . 14
7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 13 7.5. Attribute Value Pair flag rules . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 14 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 15 Appendix A. Topology Scenarios . . . . . . . . . . . . . . . . . 16
A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. No Agent . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Single Agent . . . . . . . . . . . . . . . . . . . . . . 16
A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 16 A.3. Multiple Agents . . . . . . . . . . . . . . . . . . . . . 17
A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 17 A.4. Linked Agents . . . . . . . . . . . . . . . . . . . . . . 18
A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 18 A.5. Shared Server Pools . . . . . . . . . . . . . . . . . . . 19
A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 18 A.6. Agent Chains . . . . . . . . . . . . . . . . . . . . . . 19
A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 19 A.7. Fully Meshed Layers . . . . . . . . . . . . . . . . . . . 20
A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 19 A.8. Partitions . . . . . . . . . . . . . . . . . . . . . . . 20
A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 19 A.9. Active-Standby Nodes . . . . . . . . . . . . . . . . . . 20
A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 20 A.10. Addition and removal of Nodes . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[RFC7068] describes requirements for Overload Control in Diameter [RFC7068] describes requirements for Overload Control in Diameter
[RFC6733]. At the time of this writing, the DIME working group is [RFC6733]. The DIME working group has finished the Diameter Overload
working on the Diameter Overload Information Conveyance (DOIC) Information Conveyance (DOIC) mechanism [RFC7683]. As currently
mechanism [I-D.ietf-dime-ovli] . As currently specified, DOIC specified, DOIC fulfills some, but not all, of the requirements.
fulfills some, but not all, of the requirements.
In particular, DOIC does not fulfill Req 24, which requires a In particular, DOIC does not fulfill Req 24, which requires a
mechanism where Diameter nodes can indicate their current load, even mechanism where Diameter nodes can indicate their current load, even
if they are not currently overloaded. DOIC also does not fulfill Req if they are not currently overloaded. DOIC also does not fulfill Req
23, which requires that nodes that divert traffic away from 23, which requires that nodes that divert traffic away from
overloaded nodes be provided with sufficient information to select overloaded nodes be provided with sufficient information to select
targets that are most likely to have sufficient capacity. targets that are most likely to have sufficient capacity.
There are several other requirements in RFC 7068 that mention both There are several other requirements in [RFC7068] that mention both
overload and load information that are only partially fulfilled by overload and load information that are only partially fulfilled by
DOIC. DOIC.
The DIME working group explicitly chose not to fulfill these The DIME working group explicitly chose not to fulfill these
requirements in DOIC due to several reasons. A principal reason was requirements in DOIC due to several reasons. A principal reason was
that the working group did not agree on a general approach for that the working group did not agree on a general approach for
conveying load information. It chose to progress the rest of DOIC, conveying load information. It chose to progress the rest of DOIC,
and defer load information conveyance to a DOIC extension or a and deferred load information conveyance to a DOIC extension or a
separate mechanism. separate mechanism.
This document defines a mechanism that addresses the load-related This document defines a mechanism that addresses the load-related
requirements from RFC 7068. requirements from RFC 7068.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
DOIC DOIC
Diameter Overload Information Conveyance Diameter Overload Information Conveyance ([RFC7683])
Load Load
The relative capacity of a Diameter node. A low value indicates The relative capacity of a Diameter node. A low load level
that the Diameter node is under utilized. A high value indicated indicates that the Diameter node is under utilized. A high load
that the node is closer to being fully utilized. level indicates that the node is closer to being fully utilized.
Offered Load Offered Load
The actual traffic sent to the reporting node after overload The actual traffic sent to the reporting node after overload
abatement and routing decisions are made. abatement and routing decisions are made.
Reporting, Reacting Node
Reporting node and reacting node terminology is defined in
[RFC7683].
Routing Information
Routing Information - Routing information referred to in this
document can include the Routing and Peer tables defined in RFC
6733. It can also include other implementation specific tables
used to store load information. This document does not define the
structure of such tables.
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.
4. Background 4. Background
4.1. Differences between Load and Overload information 4.1. Differences between Load and Overload information
Previous discussions of how to solve the load-related requirements in Previous discussions of how to solve the load-related requirements in
[RFC7068] have shown that people have not had an agreed-upon concept [RFC7068] have shown that people did not had an agreed-upon concept
of how "load" information differs from "overload" information. While of how "load" information differs from "overload" information. While
the two concepts are highly interrelated, in the opinion of the the two concepts are highly interrelated, in the opinion of the
authors, there are two primary differences. First, a Diameter node authors, there are two primary differences. First, a Diameter node
always has a load. At any given time that load maybe effectively always has a load. At any given time that load maybe effectively
zero, effectively fully loaded, or somewhere in between. In zero, effectively fully loaded, or somewhere in between. In
contrast, overload is an exceptional condition. A node only has contrast, overload is an exceptional condition. A node only has
overload information when it is in an overloaded state. Furthermore, overload information when it is in an overloaded state. Furthermore,
the relationship between a node's load level and overload state at the relationship between a node's load level and overload state at
any given time may be vague. For example, a node may normally any given time may be vague. For example, a node may normally
operate at a "fully loaded" level, but still not be considered operate at a "fully loaded" level, but still not be considered
overloaded. Another node may declare itself to be "overloaded" even overloaded. Another node may declare itself to be "overloaded" even
though it might not be fully "loaded". though it might not be fully "loaded".
Second, Overload information, in the form of a DOIC Overload Report Second, Overload information, in the form of a DOIC Overload Report
(OLR) [I-D.ietf-dime-ovli] indicates an explicit request for action (OLR) [RFC7683] indicates an explicit request for action on the part
on the part of the reacting node. That is, the OLR requests that the of the reacting node. That is, the OLR requests that the reacting
reacting node reduce the offered load -- the actual traffic sent to node reduce the offered load -- the actual traffic sent to the
the reporting node after overload abatement and routing decisions are reporting node after overload abatement and routing decisions are
made -- by an indicated amount or to an indicated level. made -- by an indicated amount or to an indicated level.
Effectively, DOIC provides a contract between the reporting node and Effectively, DOIC provides a contract between the reporting node and
the reacting node. the reacting node.
In contrast, load is informational. That is, load information can be In contrast, load is informational. That is, load information can be
considered a hint to the recipient node. That node may use the load considered a hint to the recipient node. That node may use the load
information for load balancing purposes, as an input to certain information for load balancing purposes, as an input to certain
overload abatement techniques, to make inferences about the overload abatement techniques, to make inferences about the
likelihood that the sending node becomes overloaded in the immediate likelihood that the sending node becomes overloaded in the immediate
future, or for other purposes. future, or for other purposes.
skipping to change at page 5, line 12 skipping to change at page 5, line 23
offered load based on load information. The fundamental difference offered load based on load information. The fundamental difference
is that an overload report requires that reduction. It is also is that an overload report requires that reduction. It is also
reasonable for a Diameter node to decide to increase the offered load reasonable for a Diameter node to decide to increase the offered load
based on load information. based on load information.
4.2. How is Load Information Used? 4.2. How is Load Information Used?
[RFC7068] contemplates two primary uses for load information. Req 23 [RFC7068] contemplates two primary uses for load information. Req 23
discusses how load information might be used when performing discusses how load information might be used when performing
diversion as an overload abatement technique, as described in diversion as an overload abatement technique, as described in
[I-D.ietf-dime-ovli]. When a reacting node diverts traffic away from [RFC7683]. When a reacting node diverts traffic away from an
an overloaded node, it needs load information for the other overloaded node, it needs load information for the other candidates
candidates for that traffic in order to effectively load balance the for that traffic in order to effectively load balance the diverted
diverted load between potential candidates. Otherwise, diversion has load between potential candidates. Otherwise, diversion has a
a greater potential to drive other nodes into overload. greater potential to drive other nodes into overload.
Req 24 discusses how Diameter load information might be used when no Req 24 discusses how Diameter load information might be used when no
overload condition currently exists. Diameter nodes can use the load overload condition currently exists. Diameter nodes can use the load
information to make decisions to try to avoid overload conditions in information to make decisions to try to avoid overload conditions in
the first place. Normal load-balancing falls into this category. A the first place. Normal load-balancing falls into this category. A
node might also take other proactive steps to reduce offered load node might also take other proactive steps to reduce offered load
based on load information, so that the loaded node never goes into based on load information, so that the loaded node never goes into
overload in the first place. overload in the first place.
If the loaded nodes are Diameter servers (or clients in the case of If the loaded nodes are Diameter servers (or clients in the case of
skipping to change at page 5, line 46 skipping to change at page 6, line 9
For example, a Diameter node (e.g. client) can use a redirect For example, a Diameter node (e.g. client) can use a redirect
agent to get candidate destination host addresses. The redirect agent to get candidate destination host addresses. The redirect
agent might return several destination host addresses, from which agent might return several destination host addresses, from which
the Diameter node selects one. The Diameter node can use load the Diameter node selects one. The Diameter node can use load
information received from these hosts to make the selection. information received from these hosts to make the selection.
Just as load information can be used as part of server selection, it Just as load information can be used as part of server selection, it
can also be used as input to the selection of the next-hop peer to can also be used as input to the selection of the next-hop peer to
which a request is to be routed. which a request is to be routed.
Editor's Note: One area that requires thought is how load It should be noted that a Diameter node will need to process both
information is used, if at all, in the presence of an overload Load reports and Overload reports from the same Diameter node. The
report from the same Diameter node. It might be that the load reacting node for the Overload report always has the responsibility
information from that Diameter node is ignored for the duration of to reduce the amount of Diameter traffic sent to the overloaded node.
the time that the overload report is in effect. It might also be If, or how, the reacting node uses Load information to achieve this
possible that the load information can aid in the diverting of is left as an implementation decision.
non-abated requests targeted for the overloaded Diameter node.
5. Solution Overview 5. Solution Overview
The mechanism defined here for the conveyance of load information is The mechanism defined here for the conveyance of load information is
similar in some says to the mechanism defined for DOIC and is similar in some ways to the mechanism defined for DOIC and is
different in other ways. different in other ways.
As with DOIC, load information is conveyed by piggy-backing the load As with DOIC, load information is conveyed by piggy-backing the load
AVPs on existing Diameter applications. AVPs on existing Diameter applications.
There are two primary differences. First, there is no capability There are two primary differences. First, there is no capability
negotiation process for load. The sender of the load information is negotiation process for load. The sender of the load information is
sending it with the expectation that any supporting nodes will use it sending it with the expectation that any supporting nodes will use it
when making routing decisions. If there are no nodes that support when making routing decisions. If there are no nodes that support
the load extension then the load information is ignored. the Load mechanism then the load information is ignored.
The second big difference between DOIC and Load is visibility of the The second big difference between DOIC and Load is visibility of the
DOIC or Load information within a Diameter network. DOIC information DOIC or Load information within a Diameter network. DOIC information
is sent end-to-end resulting in the ability of all nodes in the path is sent end-to-end resulting in the ability of all nodes in the path
of the answer message that carries the OC-OLR AVP to act on the of the answer message that carries the OC-OLR AVP to act on the
information. The DOIC overload reports much remain in the message information. The DOIC overload reports much remain in the message
all the way from the reporting node to the node that is the target all the way from the reporting node to the node that is the target
for the answer message. for the answer message.
For the Load mechanism there are two types of load reports. For the Load mechanism there are two types of load reports.
The first is the load of the end-point sending the answering the The first is the load of the endpoint sending the answer message.
message. This load report is carried end-to-end to enable any nodes This load report is carried end-to-end to enable any nodes that make
that make server selection decisions to use the load status of the server selection decisions to use the load status of the sending
sending end-point as part of the server selection decision. endpoint as part of the server selection decision.
The second type of load report is a peer report. This report is used The second type of load report is a peer report. This report is used
by Diameter nodes as part of the logic to select the next hop by Diameter nodes as part of the logic to select the next hop
Diameter node and, as such, do not have significance beyond the peer Diameter node and, as such, do not have significance beyond the peer
node. These load reports are removed by the first supporting node. These load reports are removed by the first supporting
Diameter node. Diameter node to receive the report.
Because load reports can traverse Diameter nodes that do not support Because load reports can traverse Diameter nodes that do not support
the load mechanism, it is necessary to include the identity of the the Load mechanism, it is necessary to include the identity of the
node to which the load report applies as part of the load report. node to which the load report applies as part of the load report.
This allows for a Diameter node to verify that the load report This allows for a Diameter node to verify that a load report applies
applies to its peer or if it should be ignored. to its peer or if it should be ignored.
The load report includes the relative load of the sending node. This The load report includes the relative load of the sending node. This
relative load is specified in a manner consistent with that defined relative load is specified in a manner consistent with that defined
for DNS SRV [RFC2782]. for DNS SRV [RFC2782].
The goal is make it possible to use both the load values received as
a part of the Diameter Load mechanism and weight values received as a
result of a DNS SRV query. As a result, the Diameter load value has
a range of 0-65535. This value and DNS SRV weight values are then
used in a distribution algorithm similar to that specified in
[RFC2782].
The DNS SRV distribution algorithm results in more messages being
sent to a node with a higher weight value. As a result, a higher
Diameter load value indicates a LOWER load on the sending node. A
node that is heavily loaded sends a lower Diameter load value.
Stated another way, a node that has zero load would have a load value
of 65535. A node that is 100% loaded would have a load value of 0.
The distribution algorithm used by Diameter nodes supporting the
Diameter Load mechanism is an implementation decision but it needs to
result in similar behavior as the algorithm specified in [RFC2782].
The method for calculating the load value included in the load report The method for calculating the load value included in the load report
is left as an implementation decision. is also left as an implementation decision.
The frequency for sending of load reports is also left as an The frequency for sending of load reports is also left as an
implementation decision. The sending node might choose to send load implementation decision. The sending node might choose to send load
reports in all messages or it might choose to only send load reports reports in all messages or it might choose to only send load reports
when the load value has changed by some implementation specific when the load value has changed by some implementation specific
value. The important consideration is that all nodes needing the amount. The important consideration is that all nodes needing the
load information have a sufficiently accurate view of the nodes load. load information have a sufficiently accurate view of the nodes load.
5.1. Theory of Operation 5.1. Theory of Operation
This section outlines how the Diameter load mechanism is expected to This section outlines how the Diameter Load mechanism is expected to
work. work.
For this discussion, assume the following Diameter network For this discussion, assume the following Diameter network
configuration: configuration:
---A1---A3----S[1], S[2]...S[p] ---A1---A3----S[1], S[2]...S[p]
/ | \ / / | \ /
C | x C | x
\ | / \ \ | / \
---A2---A4----S[p+1], S[p+2] ...S[n] ---A2---A4----S[p+1], S[p+2] ...S[n]
Figure 1: Example Diameter Network Figure 1: Example Diameter Network
Note that in this diagram, S[1], S[2] through S[p] are peers to A3.
S[p+1], S[p+2] through S[n] are peers to A4.
Also assume that the request for a Diameter transaction takes the Also assume that the request for a Diameter transaction takes the
following path: following path:
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
|----->|----->|----->| |----->|----->|----->|
xxR xxR xxR xxR xxR xxR
Figure 2: Request Message Path Figure 2: Request Message Path
When sending the answer message, an end-point node that supports the When sending the answer message, an endpoint node that supports the
Diameter Load mechanism includes it's own load information in the Diameter Load mechanism includes it's own load information in the
answer message. Because it is a Diameter end-point it includes an answer message. Because it is a Diameter endpoint it includes a HOST
end-point load report. load report.
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
| | |<-----| | | |<-----|
| | xxA(Load type:host, source:S[n]) | | xxA(Load type:HOST, source:S[n])
| | | | | | | |
Figure 3: Answer Message from S[n] Figure 3: Answer Message from S[n]
If Agent A4 supports the Load mechanism then it will verify that the If Agent A4 supports the Load mechanism then it will verify that the
load information received is valid. For a host load report this is load information received is valid. For a HOST load report this is
achieved by matching the identity included in the load information achieved by matching the identity included in the load information
with the identity of the host node from which the answer message was with the identity of the host node from which the answer message was
received. received.
Note: If A4 does not support the load mechanism then it will relay Note: If A4 does not support the Load mechanism then it will relay
the answer message without doing any processing on the load the answer message without doing any processing on the load
information. In this case the load AVPs will be relayed without information. In this case the load information AVPs will be
change. relayed without change.
If the identity included in the load information AVPs matches the If the identity included in the load information AVPs matches the
identity of the host from which the load information is received then identity of the host from which the load information is received then
Agent A4 stores the load information for S[n] in its routing tables. Agent A4 stores the load information for S[n] in its routing
information.
Because the load report is an host load report, A4 leaves the load Because the load report is an HOST load report, A4 leaves the load
report in the message it relays. report in the message it relays.
A4 then calculates its own load information and inserts load A4 then calculates its own load information and inserts load
information AVPs in the message before sending the message to A1: information AVPs of type PEER in the message before sending the
message to A1:
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
| |<-----| | | |<-----| |
| xxA(Load type:peer, source:A4) | xxA(Load type:PEER, source:A4)
| xxA(Load type:host, source:S[n]) | xxA(Load type:HOST, source:S[n])
| | | | | | | |
Figure 4: Answer Message from A4 Figure 4: Answer Message from A4
If A1 supports the Load mechanism then it processes each of the Load If A1 supports the Load mechanism then it processes each of the Load
reports it receives separately. reports it receives separately.
For the peer load report, A1 first determines if the source of the For the PEER load report, A1 first determines if the source of the
report indicated in the load report matches the DiameterID of the report indicated in the load report matches the DiameterIdentity of
Diameter node from which the request was received. If the identities the Diameter node from which the request was received. If the
do not match then the peer load report is discarded. If the identities do not match then the PEER load report is discarded. If
identities match then A1 saves the load information in its routing the identities match then A1 saves the load information in its
tables for routing of subsequent request messages. In both cases A1 routing information for routing of subsequent request messages. In
strips the peer load report from the message. both cases A1 strips the PEER load report from the message.
For the host load report, A1's actions depend on whether A1 is For the HOST load report, A1's actions depend on whether A1 is
responsible for doing server selection. If A1 is not doing server responsible for doing server selection. If A1 is not doing server
selection then A1 ignores the host load report. If A1 is responsible selection then A1 ignores the HOST load report. If A1 is responsible
for doing server selection then it stores the load information for for doing server selection then it stores the load information for
S[n] in its routing tables for the handling of subsequent request S[n] in its routing information for the handling of subsequent
messages. In both cases A1 leaves the host report in the message. request messages. In both cases A1 leaves the HOST report in the
message.
A1 then calculates its own load information and inserts load A1 then calculates its own load information and inserts load
information AVPs in the message before sending the message to A1: information AVPs of type PEER in the message before sending the
message to A1:
C A1 A4 S[n] C A1 A4 S[n]
| | | | | | | |
|<-----| | | |<-----| | |
xxA(Load type:peer, source:A1) xxA(Load type:PEER, source:A1)
xxA(Load type:host, source:S[n]) xxA(Load type:HOST, source:S[n])
Figure 5: Answer Message from A1 Figure 5: Answer Message from A1
As with A1, C processes each load report separately. As with A1, C processes each load report separately.
For the peer load report, C follows the same procedure for For the PEER load report, C follows the same procedure as A1 for
determining if the Load report was received from the peer from which determining if the Load report was received from the peer from which
the report was sent and, when finding it does, stores the load the report was sent and, when finding it does, stores the load
information for use when making future routing decisions. information for use when making future routing decisions.
For the host load report, C saves the load information only if it is For the HOST load report, C saves the load information only if it is
responsible for doing server selection. responsible for doing server selection.
The Load information received by all nodes is then used for routing The Load information received by all nodes is then used for routing
of subsequent request messages. of subsequent request messages.
6. Load Mechanism Procedures 6. Load Mechanism Procedures
This section defines the normative behaviors for the Load mechanism. This section defines the normative behaviors for the Load mechanism.
6.1. Reporting Node Behavior 6.1. Reporting Node Behavior
This section defines the procedures of Diameter nodes that generate This section defines the procedures of Diameter reporting nodes that
load reports. generate load reports.
6.1.1. End-point Reporting Node Behavior 6.1.1. Endpoint Reporting Node Behavior
A Diameter end-point that supports the Diameter Load mechanism MUST A Diameter endpoint that supports the Diameter Load mechanism MUST
include a load report of type HOST in sufficient answer messages to include a load report of type HOST in sufficient answer messages to
ensure that all consumers of the load information receive timely ensure that all consumers of the load information receive timely
updates. updates.
The Diameter end-point MUST include it's own DiameterID in the The Diameter endpoint MUST include it's own DiameterIdentity in the
Source-ID AVP included in the Load AVP. Source-ID AVP included in the Load AVP.
The Diameter end-point MUST include a Load-Type AVP of type HOST in The Diameter endpoint MUST include a Load-Type AVP of type HOST in
the Load AVP. the Load AVP.
The Diameter end-point MUST include its load value in the Value AVP The Diameter endpoint MUST include its load value in the Value AVP in
in the load AVP. the load AVP.
The method for determining the load value included in the load report The method for determining the load value included in the load report
is an implementation decision. is an implementation decision.
The value included MUST be consistant with DNS SRV....
Editor's note: We need to elaborate on this.
The frequency of sending load reports is an implementation decision. The frequency of sending load reports is an implementation decision.
For instance, if the only consumer of the load reports is the end- For instance, if the only consumer of the load reports is the
points peer then the end-point can choose to only include a load endpoints peer then the endpoint can choose to only include a load
report when the load of the end-point has changed by a significant report when the load of the endpoint has changed by a meaningful
percentage. If there are consumers of the end-point load report percentage. If there are consumers of the endpoint load report
other then the end-points peer (this will be the case if other other then the endpoints peer (this will be the case if other
nodes are responsible for server selection) then the end-point nodes are responsible for server selection) then the endpoint
might choose to include load reports in all answer messages as a might choose to include load reports in all answer messages as a
way of ensuring that all nodes doing server selection get accurate way of ensuring that all nodes doing server selection get accurate
load information. load information.
6.1.2. Agent Reporting Node Behavior 6.1.2. Agent Reporting Node Behavior
A Diameter agent that supports the Diameter Load mechanism MUST A Diameter agent that supports the Diameter Load mechanism MUST
include a PEER load report in sufficient answer messages to ensure include a PEER load report in sufficient answer messages to ensure
that all users of the load information receive timely updates. that all users of the load information receive timely updates.
The Diameter agent MUST include it's own DiameterID in the Source-ID The Diameter agent MUST include it's own DiameterIdentity in the
AVP included in the Load AVP. Source-ID AVP included in the Load AVP.
The Diameter agent MUST include a Load-Type AVP of type PEER in the The Diameter agent MUST include a Load-Type AVP of type PEER in the
Load AVP. Load AVP.
The Diameter agent MUST include its load value in the Value AVP in The Diameter agent MUST include its load value in the Value AVP in
the load AVP. the load AVP.
The method for determining the load value included in the load report The method for determining the load value included in the load report
is an implementation decision. is an implementation decision.
The value included MUST be consistant with DNS SRV....
Editor's note: We need to elaborate on this.
The frequency of sending load reports is an implementation decision. The frequency of sending load reports is an implementation decision.
Note: In the case of peer load reports it is only necessary to Note: In the case of peer load reports it is only necessary to
include load reports when the load value has changed by some include load reports when the load value has changed by some
significant value. It is also acceptable to include the load meaningful value, as long as the agent insures that all peers
receive the report. It is also acceptable to include the load
report in every answer message handled by the Diameter agent. report in every answer message handled by the Diameter agent.
6.2. Receiving Node Behavior 6.2. Receiving Node Behavior
This section defines the behavior of Diameter nodes processing load This section defines the behavior of Diameter nodes processing load
reports. reports.
A Diameter node MUST be prepared to process both load reports of type A Diameter node MUST be prepared to process load reports of type HOST
HOST and of type PEER, as indicated in the Load-Type AVP included in and of type PEER, as indicated in the Load-Type AVP included in the
the Load AVP. Load AVP received in the same answer message or from multiple answer
messages.
Note that the node needs to be able to handle messages with no Note that the node needs to be able to handle messages with no
load reports, messages with just a PEER load report, messages with load reports, messages with just a PEER load report, messages with
just an HOST load report and messages with both types of load just an HOST load report and messages with both types of load
reports. reports.
If the Diameter node is not responsible for doing server selection If the Diameter node is not responsible for doing server selection
then it SHOULD ignore load reports of type HOST. then it SHOULD ignore load reports of type HOST.
If the Diameter node is responsible for doing server selection then If the Diameter node is responsible for doing server selection then
it SHOULD save the load value included in the Value AVP included in it SHOULD save the load value included in the Value AVP included in
the Load AVP of type HOST in its routing tables. the Load AVP of type HOST in its routing information.
If the Diameter node receives a Load report of type PEER then the If the Diameter node receives a Load report of type PEER then the
Diameter node MUST determine if the Load report was inserted into the Diameter node MUST determine if the Load report was inserted into the
answer message by the peer from which the message was received. This answer message by the peer from which the message was received. This
is achieved by comparing the DiameterID associated with the is achieved by comparing the DiameterIdentity associated with the
connection from which the message was received with the DiameterID connection from which the message was received with the
included in the Source-ID AVP in the Load report. DiameterIdentity included in the Source-ID AVP in the Load report.
If the Diameter node determines that the Load report of type PEER was If the Diameter node determines that the Load report of type PEER was
not received from the peer that sent or relayed the answer message not received from the peer that sent or relayed the answer message
then the node MUST ignore the Load report. then the node MUST ignore the Load report.
If the Diameter node determines that the Load report of type PEER was If the Diameter node determines that the Load report of type PEER was
received from the peer that sent or relayed the answer message then received from the peer that sent or relayed the answer message then
the node SHOULD save the load information in its routing table. the node SHOULD save the load information in its routing information.
How a Diameter node uses load information for making routing How a Diameter node uses load information for making routing
decisions is an implememtation decision. decisions is an implementation decision. However, the distribution
algorithm MUST result in similar behavior as the algorithm described
for the use of weigth values in [RFC2782].
6.3. Extensibility 6.3. Extensibility
The Load mechanism can be extended to include additional information The Load mechanism can be extended to include additional information
in the load reports. in the load reports.
Any extension may define new AVPs for use in Load reports. These new Any extension may define new AVPs for use in Load reports. These new
AVPs SHOULD be defined to be extensions to the Load AVPs defined in AVPs SHOULD be defined to be extensions to the Load AVPs defined in
this document. this document.
[RFC6733] defined Grouped AVP extension mechanisms apply. This [RFC6733] defined Grouped AVP extension mechanisms apply. This
allows, for example, defining a new feature that is mandatory to be allows, for example, defining a new feature that is mandatory to be
understood even when piggybacked on an existing application. understood even when piggybacked on an existing application.
As with any Diameter specification, RFC6733 requires all new AVPs to As with any Diameter specification, [RFC6733] requires all new AVPs
be registered with IANA. See Section 9 for the required procedures. to be registered with IANA. See Section 9 for the required
procedures.
7. Attribute Value Pairs 7. Attribute Value Pairs
The section defines the AVPs required for the Load mechanism. The section defines the AVPs required for the Load mechanism.
7.1. Load AVP 7.1. Load AVP
The Load AVP (AVP code TBD1) is of type Grouped and is used to convey The Load AVP (AVP code TBD1) is of type Grouped and is used to convey
load information between Diameter nodes. load information between Diameter nodes.
skipping to change at page 13, line 11 skipping to change at page 13, line 40
HOST 0 The load report is for a host. HOST 0 The load report is for a host.
PEER 1 The load report is for a peer. PEER 1 The load report is for a peer.
7.3. Load-Value AVP 7.3. Load-Value AVP
The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used The Load-Value AVP (AVP code TBD3) is of type Unsigned64. It is used
to convey relative load information about the sender of the load to convey relative load information about the sender of the load
report. report.
The Load-Value AVP is specified in a manner similar to the weight
value in DNS SRV ([RFC2782]).
The Load-Value has a range of 0-65535.
A higher value indicates a lower load on the sending node. A lower
value indicates that the sending node is heavily loaded.
Stated another way, a node that has zero load would have a load
value of 65535. A node that is 100% loaded would have a load
value of 0.
7.4. SourceID AVP 7.4. SourceID AVP
The SourceID AVP is defined in [I-D.ietf-dime-agent-overload]. It is The SourceID AVP is defined in [I-D.ietf-dime-agent-overload]. It is
used to identify the Diameter node that sent the Load report. used to identify the Diameter node that sent the Load report.
7.5. Attribute Value Pair flag rules 7.5. 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|
+--------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|Load TBD1 x.1 Grouped | | V | |Load TBD1 x.1 Grouped | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|Load-Type TBD2 x.2 Enumerated | | V | |Load-Type TBD2 x.2 Enumerated | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
|Load-Value TBD3 x.3 Unsigned64 | | V | |Load-Value TBD3 x.3 Unsigned64 | | V |
+--------------------------------------------------+----+----+ +------------------------------------------------------ -+----+----+
|SourceID TBD4 x.4 DiameterID | | V | |SourceID TBD4 x.4 DiameterIdentity | | V |
+--------------------------------------------------+----+----+ +--------------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit usage As described in the Diameter base protocol [RFC6733], the M-bit usage
for a given AVP in a given command may be defined by the application. for a given AVP in a given command may be defined by the application.
8. Security Considerations 8. Security Considerations
Load information may be sensitive information in some cases. Load information may be sensitive information in some cases.
Depending on the mechanism, an unauthorized recipient might be able Depending on the mechanism, an unauthorized recipient might be able
to infer the topology of a Diameter network from load information. to infer the topology of a Diameter network from load information.
Load information might be useful in identifying targets for Denial of Load information might be useful in identifying targets for Denial of
skipping to change at page 14, line 28 skipping to change at page 15, line 26
This document makes no new registry requests of IANA. This document makes no new registry requests of IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dime-agent-overload] [I-D.ietf-dime-agent-overload]
Donovan, S., "Diameter Agent Overload", draft-ietf-dime- Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
agent-overload-02 (work in progress), August 2015. agent-overload-02 (work in progress), August 2015.
[I-D.ietf-dime-ovli]
Korhonen, J., Donovan, S., Campbell, B., and L. Morand,
"Diameter Overload Indication Conveyance", draft-ietf-
dime-ovli-03 (work in progress), July 2014.
[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>.
[RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control [RFC7068] McMurry, E. and B. Campbell, "Diameter Overload Control
Requirements", RFC 7068, DOI 10.17487/RFC7068, November Requirements", RFC 7068, DOI 10.17487/RFC7068, November
2013, <http://www.rfc-editor.org/info/rfc7068>. 2013, <http://www.rfc-editor.org/info/rfc7068>.
[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>.
10.2. Informative References 10.2. Informative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
Appendix A. Topology Scenarios Appendix A. Topology Scenarios
This section presents a number of Diameter topology scenarios, and This section presents a number of Diameter topology scenarios, and
skipping to change at page 15, line 34 skipping to change at page 16, line 29
using the load information received from each server. using the load information received from each server.
------S1 ------S1
/ /
C C
\ \
------S2 ------S2
Figure 6: Basic Client Server Scenario Figure 6: Basic Client Server Scenario
Open Issue: Will a Diameter node include potential peers that it If a node supports dynamic discovery, it will not obtain load
is not currently connected to as part of the candidate set? It is information from the nodes with which it has no Diameter
unlikely the client would have load information from peers that it connection established. Nevertheless it might take into account
is not currently connected to. the load information from the other nodes to decide to add
connections to new nodes with the dynamic discovery mechanism.
Note: The use of dynamic connections needs to be considered. Note: The use of dynamic connections needs to be considered.
A.2. Single Agent A.2. Single Agent
Figure 7 shows a client that sends requests to an agent. The agent Figure 7 shows a client that sends requests to an agent. The agent
selects the request destination from a set of candidate servers, selects the request destination from a set of candidate servers,
using load information received from each server. The client does using load information received from each server. The client does
not need to receive load information, since it does not select not need to receive load information, since it does not select
between multiple agents. between multiple agents.
skipping to change at page 16, line 29 skipping to change at page 17, line 29
servers. servers.
This scenario adds a complication that one set of servers may be more This scenario adds a complication that one set of servers may be more
loaded than the other set. If, for example, S4 was the least loaded loaded than the other set. If, for example, S4 was the least loaded
server, C would need to know to select agent A2 to reach S4. This server, C would need to know to select agent A2 to reach S4. This
might require C to receive load information from the servers as well might require C to receive load information from the servers as well
as the agents. Alternatively, each agent might use the load of its as the agents. Alternatively, each agent might use the load of its
servers as an input into calculating its own load, in effect servers as an input into calculating its own load, in effect
aggregating upstream load. aggregating upstream load.
Similarly, if C sends a host-routed request [I-D.ietf-dime-ovli], it Similarly, if C sends a host-routed request [RFC7683], it needs to
needs to know which agent can deliver requests to the selected know which agent can deliver requests to the selected server.
server. Without some special, potentially proprietary, knowledge of Without some special, potentially proprietary, knowledge of the
the topology upstream of A1 and A2, C would select the agent based on topology upstream of A1 and A2, C would select the agent based on the
the normal peer selection procedures for the realm and application, normal peer selection procedures for the realm and application, and
and perhaps consider the load information from A1 and A2. If C sends perhaps consider the load information from A1 and A2. If C sends a
a request to A1 that contains a Destination-Host AVP with a value of request to A1 that contains a Destination-Host AVP with a value of
S4, A1 will not be able to deliver the request. S4, A1 will not be able to deliver the request.
-----S3 -----S3
/ /
---A1------S1 ---A1------S1
/ /
C C
\ \
---A2------S2 ---A2------S2
\ \
skipping to change at page 19, line 30 skipping to change at page 20, line 30
---A1---A3---S[1], S[2]...S[p] ---A1---A3---S[1], S[2]...S[p]
/ | \ / |\ / / | \ / |\ /
C | x | x C | x | x
\ | / \ |/ \ \ | / \ |/ \
---A2---A4---S[p+1], S[p+2] ...S[n] ---A2---A4---S[p+1], S[p+2] ...S[n]
Figure 13: Full Mesh Figure 13: Full Mesh
A.8. Partitions A.8. Partitions
A Diameter network with multiple is said to be "partitioned" when A Diameter network with multiple servers is said to be "partitioned"
only a subset of available servers can server a particular realm- when only a subset of available servers can serve a particular realm-
routed request. For example, one group of servers may handle users routed request. For example, one group of servers may handle users
whose names start with "A" through "M", and another group may handle whose names start with "A" through "M", and another group may handle
"N" through "Z". "N" through "Z".
In such a partitioned network, nodes cannot load-balance requests In such a partitioned network, nodes cannot load-balance requests
across partitions, since not all servers can handle the request. A across partitions, since not all servers can handle the request. A
client, or an intermediate agent, may still be able to load-balance client, or an intermediate agent, may still be able to load-balance
between servers inside a partition. between servers inside a partition.
A.9. Active-Standby Nodes A.9. Active-Standby Nodes
skipping to change at page 20, line 11 skipping to change at page 21, line 11
active peers became unavailable. For example, requests might be active peers became unavailable. For example, requests might be
diverted to a stand-by peer if one or more active peers becomes diverted to a stand-by peer if one or more active peers becomes
overloaded. overloaded.
A.10. Addition and removal of Nodes A.10. Addition and removal of Nodes
When a Diameter node is added, the new node will start by advertising When a Diameter node is added, the new node will start by advertising
its load. Downstream nodes will need to factor the new load its load. Downstream nodes will need to factor the new load
information into load balancing decisions. The downstream nodes information into load balancing decisions. The downstream nodes
should attempt to ensure a smooth increase of the traffic to the new should attempt to ensure a smooth increase of the traffic to the new
node, avoiding an immediate spike of traffic to the new node. It node, avoiding an immediate spike of traffic to the new node. The
should be determined if this use case is in the scope of the load handling of such a smooth increase is implementation specific but it
control mechanism. can rely on the evolution of load information received from the new
node and from the other nodes.
When removing a node in a controlled way (e.g. for maintenance When removing a node in a controlled way (e.g. for maintenance
purpose, so outside a failure case), it might be appropriate to purpose, so outside a failure case), it might be appropriate to
progressively reduce the traffic to this node by routing traffic to progressively reduce the traffic to this node by routing traffic to
other nodes. Simple load information (load percentage) would be not other nodes. Simple load information (load percentage) would be not
sufficient. It should be determined if this use case is in the scope sufficient. The handling of the node removal is implementation
of the load control mechanism. specific but it can rely on the evolution of the load information
received from the node to be removed
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
Oracle Oracle
7460 Warren Parkway # 300 7460 Warren Parkway # 300
Frisco, Texas 75034 Frisco, Texas 75034
USA USA
Email: ben@nostrum.com Email: ben@nostrum.com
Steve Donovan (editor) Steve Donovan (editor)
Oracle Oracle
7460 Warren Parkway # 300 7460 Warren Parkway # 300
Frisco, Texas 75034 Frisco, Texas 75034
United States United States
Email: srdonovan@usdonovans.com Email: srdonovan@usdonovans.com
Jean-Jacques Trottin Jean-Jacques Trottin
Alcatel-Lucent Nokia
Route de Villejust Route de Villejust
91620 Nozay 91620 Nozay
France France
Email: jean-jacques.trottin@alcatel-lucent.com Email: jean-jacques.trottin@nokia.com
 End of changes. 76 change blocks. 
184 lines changed or deleted 231 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/