< draft-ietf-soc-overload-control-13.txt   draft-ietf-soc-overload-control-14.txt >
SOC Working Group V. Gurbani, Ed. SOC Working Group V. Gurbani, Ed.
Internet-Draft V. Hilt Internet-Draft V. Hilt
Intended status: Standards Track Bell Laboratories, Alcatel-Lucent Intended status: Standards Track Bell Laboratories,
Expires: November 24, 2013 H. Schulzrinne Expires: June 12, 2014 Alcatel-Lucent
H. Schulzrinne
Columbia University Columbia University
May 23, 2013 December 9, 2013
Session Initiation Protocol (SIP) Overload Control Session Initiation Protocol (SIP) Overload Control
draft-ietf-soc-overload-control-13 draft-ietf-soc-overload-control-14
Abstract Abstract
Overload occurs in Session Initiation Protocol (SIP) networks when Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable) overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This response code, SIP servers are still vulnerable to overload. This
document defines the behaviour of SIP servers involved in overload document defines the behaviour of SIP servers involved in overload
control, and in addition, it specifies a loss-based overload scheme control, and in addition, it specifies a loss-based overload scheme
skipping to change at page 1, line 39 skipping to change at page 1, line 40
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 November 24, 2013. This Internet-Draft will expire on June 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 18 skipping to change at page 3, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of operations . . . . . . . . . . . . . . . . . . . . 5 3. Overview of operations . . . . . . . . . . . . . . . . . . . . 5
4. Via header parameters for overload control . . . . . . . . . . 6 4. Via header parameters for overload control . . . . . . . . . . 6
4.1. The oc parameter . . . . . . . . . . . . . . . . . . . . . 6 4.1. The oc parameter . . . . . . . . . . . . . . . . . . . . . 6
4.2. The oc-algo parameter . . . . . . . . . . . . . . . . . . 7 4.2. The oc-algo parameter . . . . . . . . . . . . . . . . . . 7
4.3. The oc-validity parameter . . . . . . . . . . . . . . . . 8 4.3. The oc-validity parameter . . . . . . . . . . . . . . . . 8
4.4. The oc-seq parameter . . . . . . . . . . . . . . . . . . . 8 4.4. The oc-seq parameter . . . . . . . . . . . . . . . . . . . 8
5. General behaviour . . . . . . . . . . . . . . . . . . . . . . 9 5. General behaviour . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Determining support for overload control . . . . . . . . . 9 5.1. Determining support for overload control . . . . . . . . . 9
5.2. Creating and updating the overload control parameters . . 10 5.2. Creating and updating the overload control parameters . . 10
5.3. Determining the 'oc' Parameter Value . . . . . . . . . . . 11 5.3. Determining the 'oc' Parameter Value . . . . . . . . . . . 12
5.4. Processing the Overload Control Parameters . . . . . . . . 12 5.4. Processing the Overload Control Parameters . . . . . . . . 12
5.5. Using the Overload Control Parameter Values . . . . . . . 13 5.5. Using the Overload Control Parameter Values . . . . . . . 13
5.6. Forwarding the overload control parameters . . . . . . . . 13 5.6. Forwarding the overload control parameters . . . . . . . . 13
5.7. Terminating overload control . . . . . . . . . . . . . . . 13 5.7. Terminating overload control . . . . . . . . . . . . . . . 14
5.8. Stabilizing overload algorithm selection . . . . . . . . . 14 5.8. Stabilizing overload algorithm selection . . . . . . . . . 14
5.9. Self-Limiting . . . . . . . . . . . . . . . . . . . . . . 15 5.9. Self-Limiting . . . . . . . . . . . . . . . . . . . . . . 15
5.10. Responding to an Overload Indication . . . . . . . . . . . 15 5.10. Responding to an Overload Indication . . . . . . . . . . . 15
5.10.1. Message prioritization at the hop before the 5.10.1. Message prioritization at the hop before the
overloaded server . . . . . . . . . . . . . . . . . . 15 overloaded server . . . . . . . . . . . . . . . . . . 16
5.10.2. Rejecting requests at an overloaded server . . . . . 16 5.10.2. Rejecting requests at an overloaded server . . . . . 16
5.11. 100-Trying provisional response and overload control 5.11. 100-Trying provisional response and overload control
parameters . . . . . . . . . . . . . . . . . . . . . . . . 16 parameters . . . . . . . . . . . . . . . . . . . . . . . . 17
6. The loss-based overload control scheme . . . . . . . . . . . . 17 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Special parameter values for loss-based overload 7. The loss-based overload control scheme . . . . . . . . . . . . 18
control . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Special parameter values for loss-based overload
6.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 18 control . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Default algorithm for loss-based overload control . . . . 19 7.2. Default algorithm for loss-based overload control . . . . 19
7. Relationship with other IETF SIP load control efforts . . . . 23 8. Relationship with other IETF SIP load control efforts . . . . 23
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Design Considerations . . . . . . . . . . . . . . . . . . . . 24 10. Design Considerations . . . . . . . . . . . . . . . . . . . . 23
9.1. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 24 10.1. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 24
9.1.1. SIP Response Header . . . . . . . . . . . . . . . . . 24 10.1.1. SIP Response Header . . . . . . . . . . . . . . . . . 24
9.1.2. SIP Event Package . . . . . . . . . . . . . . . . . . 25 10.1.2. SIP Event Package . . . . . . . . . . . . . . . . . . 24
9.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 26 10.2. Backwards Compatibility . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Appendix B. RFC5390 requirements . . . . . . . . . . . . . . . . 29 Appendix B. RFC5390 requirements . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
As with any network element, a Session Initiation Protocol (SIP) As with any network element, a Session Initiation Protocol (SIP)
[RFC3261] server can suffer from overload when the number of SIP [RFC3261] server can suffer from overload when the number of SIP
messages it receives exceeds the number of messages it can process. messages it receives exceeds the number of messages it can process.
Overload can pose a serious problem for a network of SIP servers. Overload can pose a serious problem for a network of SIP servers.
During periods of overload, the throughput of a network of SIP During periods of overload, the throughput of a network of SIP
servers can be significantly degraded. In fact, overload may lead to servers can be significantly degraded. In fact, overload may lead to
a situation in which the throughput drops down to a small fraction of a situation in which the throughput drops down to a small fraction of
skipping to change at page 4, line 52 skipping to change at page 4, line 52
A detailed discussion of the SIP overload problem, the problems with A detailed discussion of the SIP overload problem, the problems with
the 503 (Service Unavailable) response code and the requirements for the 503 (Service Unavailable) response code and the requirements for
a SIP overload control mechanism can be found in [RFC5390]. a SIP overload control mechanism can be found in [RFC5390].
This document defines the protocol for communicating overload This document defines the protocol for communicating overload
information between SIP servers and clients, so that clients can information between SIP servers and clients, so that clients can
reduce the volume of traffic sent to overloaded servers, avoiding reduce the volume of traffic sent to overloaded servers, avoiding
congestion collapse and increasing useful throughput. Section 4 congestion collapse and increasing useful throughput. Section 4
describes the Via header parameters used for this communication. The describes the Via header parameters used for this communication. The
general behaviour of SIP servers and clients involved in overload general behaviour of SIP servers and clients involved in overload
control is described in Section 5. In addition, Section 6 specifies control is described in Section 5. In addition, Section 7 specifies
a loss-based overload control scheme. SIP clients and servers a loss-based overload control scheme. SIP clients and servers
conformant to this specification MUST implement the loss-based conformant to this specification MUST implement the loss-based
overload control scheme. They MAY implement other overload control overload control scheme. They MAY implement other overload control
schemes as well. schemes as well.
2. Terminology 2. Terminology
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].
skipping to change at page 6, line 5 skipping to change at page 6, line 5
We now explain the overview of how the overload control mechanism We now explain the overview of how the overload control mechanism
operates by introducing the overload control parameters. Section 4 operates by introducing the overload control parameters. Section 4
provides more details and normative behavior on the parameters listed provides more details and normative behavior on the parameters listed
below. below.
Because overload control is performed hop-by-hop, the Via parameter Because overload control is performed hop-by-hop, the Via parameter
is attractive since it allows two adjacent SIP entities to indicate is attractive since it allows two adjacent SIP entities to indicate
support for, and exchange information associated with overload support for, and exchange information associated with overload
control [RFC6357]. Additional advantages of this choice are control [RFC6357]. Additional advantages of this choice are
discussed in Section 9.1.1. An alternative mechanism using SIP event discussed in Section 10.1.1. An alternative mechanism using SIP
packages was also considered, and the characteristics of that choice event packages was also considered, and the characteristics of that
are further outlined in Section 9.1.2. choice are further outlined in Section 10.1.2.
This document defines four new parameters for the SIP Via header for This document defines four new parameters for the SIP Via header for
overload control. These parameters provide a mechanism for conveying overload control. These parameters provide a mechanism for conveying
overload control information between adjacent SIP entities. The "oc" overload control information between adjacent SIP entities. The "oc"
parameter is used by a SIP server to indicate a reduction in the parameter is used by a SIP server to indicate a reduction in the
amount of requests arriving at the server. The "oc-algo" parameter amount of requests arriving at the server. The "oc-algo" parameter
contains a token or a list of tokens corresponding to the class of contains a token or a list of tokens corresponding to the class of
overload control algorithms supported by the client. The server overload control algorithms supported by the client. The server
chooses one algorithm from this list. The "oc-validity" parameter chooses one algorithm from this list. The "oc-validity" parameter
establishes a time limit for which overload control is in effect, and establishes a time limit for which overload control is in effect, and
skipping to change at page 7, line 51 skipping to change at page 7, line 51
supported algorithms in subsequent requests; the server MUST respond supported algorithms in subsequent requests; the server MUST respond
with the agreed to algorithm until such time that the algorithm is with the agreed to algorithm until such time that the algorithm is
changed by the server. The selection SHOULD stay the same for a non- changed by the server. The selection SHOULD stay the same for a non-
trivial duration of time to allow the overload control algorithm to trivial duration of time to allow the overload control algorithm to
stabilize its behaviour (see Section 5.8). stabilize its behaviour (see Section 5.8).
The "oc-algo" parameter does not define the exact algorithm to be The "oc-algo" parameter does not define the exact algorithm to be
used for traffic reduction, rather, the intent is to use any used for traffic reduction, rather, the intent is to use any
algorithm from a specific class of algorithms that affect traffic algorithm from a specific class of algorithms that affect traffic
reduction similarly. For example, the reference algorithm in reduction similarly. For example, the reference algorithm in
Section 6.3 can be used as a loss-based algorithm, or it can be Section 7.2 can be used as a loss-based algorithm, or it can be
substituted by any other loss-based algorithm that results in substituted by any other loss-based algorithm that results in
equivalent traffic reduction. equivalent traffic reduction.
4.3. The oc-validity parameter 4.3. The oc-validity parameter
This parameter MAY be inserted by the SIP server in a response; it This parameter MAY be inserted by the SIP server in a response; it
MUST NOT be inserted by the SIP client in a request. MUST NOT be inserted by the SIP client in a request.
This parameter contains a value that indicates an interval of time This parameter contains a value that indicates an interval of time
(measured in milliseconds) that the load reduction specified in the (measured in milliseconds) that the load reduction specified in the
skipping to change at page 8, line 41 skipping to change at page 8, line 41
After the value specified in the "oc-validity" parameter expires and After the value specified in the "oc-validity" parameter expires and
until the SIP client receives an updated set of overload control until the SIP client receives an updated set of overload control
parameters from the SIP server, the client MUST behave as if overload parameters from the SIP server, the client MUST behave as if overload
control is not in effect between it and the downstream SIP server. control is not in effect between it and the downstream SIP server.
4.4. The oc-seq parameter 4.4. The oc-seq parameter
This parameter MUST be inserted by the SIP server in a response; it This parameter MUST be inserted by the SIP server in a response; it
MUST NOT be inserted by the SIP client in a request. MUST NOT be inserted by the SIP client in a request.
This parameter contains a value that indicates the sequence number This parameter contains an unsigned integer value that indicates the
associated with the "oc" parameter. This sequence number is used to sequence number associated with the "oc" parameter. This sequence
differentiate two "oc" parameter values generated by an overload number is used to differentiate two "oc" parameter values generated
control algorithm at two different instants in time. "oc" parameter by an overload control algorithm at two different instants in time.
values generated by an overload control algorithm at time t and t+1 "oc" parameter values generated by an overload control algorithm at
MUST have an increasing value in the "oc-seq" parameter. This allows time t and t+1 MUST have an increasing value in the "oc-seq"
the upstream SIP client to properly collate out-of-order responses. parameter. This allows the upstream SIP client to properly collate
out-of-order responses.
A timestamp can be used as a value of the "oc-seq" parameter. A timestamp can be used as a value of the "oc-seq" parameter.
If the value contained in "oc-seq" parameter overflows during the If the value contained in "oc-seq" parameter overflows during the
period in which the load reduction is in effect, then the "oc-seq" period in which the load reduction is in effect, then the "oc-seq"
parameter MUST be reset to the current timestamp or an appropriate parameter MUST be reset to the current timestamp or an appropriate
base value. base value.
Due to an overflow, client implementations should be prepared to A client implementation can recognize that an overflow has
receive an "oc-seq" parameter whose value is less than the occurred when it receives an "oc-seq" parameter whose value is
previous value. Client implementations can handle this by significantly less than several previous values. (Note that an
continuing to perform overload control until the "oc-validity" "oc-seq" parameter whose value does not deviate significantly from
related to the previous value of "oc-seq" parameter expires. the last several previous values is symptomatic of a tardy packet.
However, overflow will cause "oc-seq" an "oc-seq" parameter value
to be significantly less than the last several values.) If an
overflow is detected, then the client should use the overload
parameters in the new message, even though the sequence number is
lower. The client should also reset any internal state to reflect
the overflow so that future messages (following the overflow) will
be accepted.
5. General behaviour 5. General behaviour
When forwarding a SIP request, a SIP client uses the SIP procedures When forwarding a SIP request, a SIP client uses the SIP procedures
of [RFC3263] to determine the next hop SIP server. The procedures of of [RFC3263] to determine the next hop SIP server. The procedures of
[RFC3263] take as input a SIP URI, extract the domain portion of that [RFC3263] take as input a SIP URI, extract the domain portion of that
URI for use as a lookup key, and query the Domain Name Service (DNS) URI for use as a lookup key, and query the Domain Name Service (DNS)
to obtain an ordered set of one or more IP addresses with a port to obtain an ordered set of one or more IP addresses with a port
number and transport corresponding to each IP address in this set number and transport corresponding to each IP address in this set
(the "Expected Output"). (the "Expected Output").
skipping to change at page 13, line 34 skipping to change at page 13, line 40
chosen from the Expected Output, then this chosen server is operating chosen from the Expected Output, then this chosen server is operating
in overload control mode. Thus, the SIP client MUST determine if it in overload control mode. Thus, the SIP client MUST determine if it
can or cannot forward the current request to the SIP server based on can or cannot forward the current request to the SIP server based on
the "oc" and "oc-algo" parameters and any relevant local policy. the "oc" and "oc-algo" parameters and any relevant local policy.
The particular algorithm used to determine whether or not to forward The particular algorithm used to determine whether or not to forward
a particular SIP request is a matter of local policy, and may take a particular SIP request is a matter of local policy, and may take
into account a variety of prioritization factors. However, this into account a variety of prioritization factors. However, this
local policy SHOULD transmit the same number of SIP requests as the local policy SHOULD transmit the same number of SIP requests as the
sample algorithm defined by the overload control scheme being used. sample algorithm defined by the overload control scheme being used.
(See Section 6.3 for the default loss-based overload control (See Section 7.2 for the default loss-based overload control
algorithm.) algorithm.)
5.6. Forwarding the overload control parameters 5.6. Forwarding the overload control parameters
Overload control is defined in a hop-by-hop manner. Therefore, Overload control is defined in a hop-by-hop manner. Therefore,
forwarding the contents of the overload control parameters is forwarding the contents of the overload control parameters is
generally NOT RECOMMENDED and should only be performed if permitted generally NOT RECOMMENDED and should only be performed if permitted
by the configuration of SIP servers. This means that a SIP proxy by the configuration of SIP servers. This means that a SIP proxy
SHOULD strip the overload control parameters inserted by the client SHOULD strip the overload control parameters inserted by the client
before proxying the request further downstream. before proxying the request further downstream.
skipping to change at page 14, line 17 skipping to change at page 14, line 22
previously specify an "oc-validity" parameter) expires; previously specify an "oc-validity" parameter) expires;
2. The client is explicitly told by the server to stop performing 2. The client is explicitly told by the server to stop performing
overload control using the "oc-validity=0" parameter. overload control using the "oc-validity=0" parameter.
A SIP server can decide to terminate overload control by explicitly A SIP server can decide to terminate overload control by explicitly
signaling the client. To do so, the SIP server MUST set the value of signaling the client. To do so, the SIP server MUST set the value of
the "oc-validity" parameter to 0. The SIP server MUST increment the the "oc-validity" parameter to 0. The SIP server MUST increment the
value of "oc-seq", and SHOULD set the value of the "oc" parameter to value of "oc-seq", and SHOULD set the value of the "oc" parameter to
0. 0.
Note that the loss-based overload control scheme (Section 6) can Note that the loss-based overload control scheme (Section 7) can
effectively stop overload control by setting the value of the "oc" effectively stop overload control by setting the value of the "oc"
parameter to 0. However, the rate-based scheme parameter to 0. However, the rate-based scheme
([I-D.ietf-soc-overload-rate-control]) needs an additional piece ([I-D.ietf-soc-overload-rate-control]) needs an additional piece
of information in the form of "oc-validity=0". of information in the form of "oc-validity=0".
When the client receives a response with a higher "oc-seq" number When the client receives a response with a higher "oc-seq" number
than the one it most recently processed, it checks the "oc-validity" than the one it most recently processed, it checks the "oc-validity"
parameter. If the value of the "oc-validity" parameter is 0, the parameter. If the value of the "oc-validity" parameter is 0, the
client MUST stop performing overload control of messages destined to client MUST stop performing overload control of messages destined to
the server and the traffic should flow without any reduction. the server and the traffic should flow without any reduction.
Furthermore, when the value of the "oc-validity" parameter is 0, the Furthermore, when the value of the "oc-validity" parameter is 0, the
client SHOULD disregard the value in the "oc" parameter. client SHOULD disregard the value in the "oc" parameter.
5.8. Stabilizing overload algorithm selection 5.8. Stabilizing overload algorithm selection
Realities of deployments of SIP necessitate that the overload control Realities of deployments of SIP necessitate that the overload control
algorithm may be changed upon a system reboot or a software upgrade. algorithm may be changed upon a system reboot or a software upgrade.
However, frequent changes of the overload control algorithm MUST be However, frequent changes of the overload control algorithm must be
avoided. Frequent changes of the overload control algorithm will not avoided. Frequent changes of the overload control algorithm will not
benefit the client or the server as such flapping does not allow the benefit the client or the server as such flapping does not allow the
chosen algorithm to stabilize. An algorithm change, when desired, is chosen algorithm to stabilize. An algorithm change, when desired, is
simply accomplished by the SIP server choosing a new algorithm from simply accomplished by the SIP server choosing a new algorithm from
the list in the client's "oc-algo" parameter and sending it back to the list in the client's "oc-algo" parameter and sending it back to
the client in a response. the client in a response.
The client associates a specific algorithm with each server it sends The client associates a specific algorithm with each server it sends
traffic to and when the server changes the algorithm, the client must traffic to and when the server changes the algorithm, the client must
change its behaviour accordingly. change its behaviour accordingly.
Once the server selects a specific overload control algorithm for a Once the server selects a specific overload control algorithm for a
given client, the algorithm MUST remain in effect for at least 3600 given client, the algorithm SHOULD NOT change the algorithm
seconds (1 hour) before another change occurs. This period may associated with that client for at least 3600 seconds (1 hour). This
involve one or more cycles of overload control being in effect and period may involve one or more cycles of overload control being in
then being stopped depending on the traffic and resources at the effect and then being stopped depending on the traffic and resources
server. at the server.
One way to accomplish this involves the server saving the time of One way to accomplish this involves the server saving the time of
the last algorithm change in a lookup table, indexed by the the last algorithm change in a lookup table, indexed by the
client's network identifiers. The server only changes the "oc- client's network identifiers. The server only changes the "oc-
algo" parameter when the time since the last change has surpassed algo" parameter when the time since the last change has surpassed
3600 seconds. 3600 seconds.
5.9. Self-Limiting 5.9. Self-Limiting
In some cases, a SIP client may not receive a response from a server In some cases, a SIP client may not receive a response from a server
after sending a request. RFC3261 [RFC3261] defines that when a after sending a request. RFC3261 [RFC3261] defines that when a
timeout error is received from the transaction layer, it MUST be timeout error is received from the transaction layer, it MUST be
treated as if a 408 (Request Timeout) status code has been received. treated as if a 408 (Request Timeout) status code has been received.
If a fatal transport error is reported by the transport layer, it If a fatal transport error is reported by the transport layer, it
MUST be treated as a 503 (Service Unavailable) status code. MUST be treated as a 503 (Service Unavailable) status code.
In the event of repeated timeouts or fatal transport errors, the SIP In the event of repeated timeouts or fatal transport errors, the SIP
client MUST stop sending requests to this server. The SIP client client MUST stop sending requests to this server. The SIP client
SHOULD periodically probe if the downstream server is alive using any SHOULD periodically probe if the downstream server is alive using any
mechanism at its disposal. Once a SIP client has successfully mechanism at its disposal. Clients should be conservative in their
received a normal response for a request sent to the downstream probing (e.g., using an exponential back-off) so that their liveness
server, the SIP client can resume sending SIP requests. It should, probes do not exacerbate an overload situation. Once a SIP client
of course, honor any overload control parameters it may receive in has successfully received a normal response for a request sent to the
the initial, or later, responses. downstream server, the SIP client can resume sending SIP requests.
It should, of course, honor any overload control parameters it may
receive in the initial, or later, responses.
5.10. Responding to an Overload Indication 5.10. Responding to an Overload Indication
A SIP client can receive overload control feedback indicating that it A SIP client can receive overload control feedback indicating that it
needs to reduce the traffic it sends to its downstream server. The needs to reduce the traffic it sends to its downstream server. The
client can accomplish this task by sending some of the requests that client can accomplish this task by sending some of the requests that
would have gone to the overloaded element to a different destination. would have gone to the overloaded element to a different destination.
It needs to ensure, however, that this destination is not in overload It needs to ensure, however, that this destination is not in overload
and capable of processing the extra load. A client can also buffer and capable of processing the extra load. A client can also buffer
requests in the hope that the overload condition will resolve quickly requests in the hope that the overload condition will resolve quickly
skipping to change at page 17, line 21 skipping to change at page 17, line 31
receiving SIP client, the 100-Trying is consumed at the transaction receiving SIP client, the 100-Trying is consumed at the transaction
layer by inhibiting the retransmission of the corresponding request. layer by inhibiting the retransmission of the corresponding request.
Consequently, implementations that insert overload control Consequently, implementations that insert overload control
information in the 100-Trying cannot assume that the upstream SIP information in the 100-Trying cannot assume that the upstream SIP
client passed the overload control information in the 100-Trying to client passed the overload control information in the 100-Trying to
their corresponding TU. For this reason, implementations that insert their corresponding TU. For this reason, implementations that insert
overload control information in the 100-Trying MUST re-insert the overload control information in the 100-Trying MUST re-insert the
same (or updated) overload control information in the first non-100 same (or updated) overload control information in the first non-100
response being sent to the upstream SIP client. response being sent to the upstream SIP client.
6. The loss-based overload control scheme 6. Example
Under a loss-based approach, a SIP server asks an upstream neighbor
to reduce the number of requests it would normally forward to this
server by a certain percentage. For example, a SIP server can ask an
upstream neighbor to reduce the number of requests this neighbor
would normally send by 10%. The upstream neighbor then redirects or
rejects 10% of the traffic originally destined for that server.
This section specifies the semantics of the overload control
parameters associated with the loss-based overload control scheme.
The general behaviour of SIP clients and servers is specified in
Section 5 and is applicable to SIP clients and servers that implement
loss-based overload control.
6.1. Special parameter values for loss-based overload control
The loss-based overload control scheme is identified using the token
"loss". This token MUST appear in the "oc-algo" parameter list sent
by the SIP client.
A SIP server that has selected the loss-based algorithm, upon
entering the overload state, will assign a value to the "oc"
parameter. This value MUST be in the range of [0, 100], inclusive.
This value MUST be interpreted by the client as a percentage, and the
SIP client MUST reduce the number of requests being forwarded to the
overloaded server by that percent. The SIP client may use any
algorithm that reduces the traffic it sends to the overloaded server
by the amount indicated. Such an algorithm SHOULD honor the message
prioritization discussion of Section 5.10.1. While a particular
algorithm is not subject to standardization, for completeness a
default algorithm for loss-based overload control is provided in
Section 6.3.
When a SIP server using the loss-based algorithm receives a request
from a client with an "oc" parameter but the SIP server is not
experiencing overload, it MUST assign a value of 0 to the "oc"
parameter in the response. Assigning such a value lets the client
know that the server supports overload control but is not currently
requesting any reduction in traffic.
When the "oc-validity" parameter is used to signify overload control
termination (Section 5.7), the server MUST insert a value of 0 in the
"oc-validity" parameter. The server MUST insert a value of 0 in the
"oc" parameter as well. When a client receives a response whose "oc-
validity" parameter contains a 0, it MUST treat any non-zero value in
the "oc" parameter as if it had received a value of 0 in that
parameter.
6.2. Example
Consider a SIP client, P1, which is sending requests to another Consider a SIP client, P1, which is sending requests to another
downstream SIP server, P2. The following snippets of SIP messages downstream SIP server, P2. The following snippets of SIP messages
demonstrate how the overload control parameters work. demonstrate how the overload control parameters work.
INVITE sips:user@example.com SIP/2.0 INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net; Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;oc;oc-algo="loss,A" branch=z9hG4bK2d4790.1;oc;oc-algo="loss,A"
... ...
skipping to change at page 19, line 31 skipping to change at page 18, line 40
After some time, the overload condition at P2 subsides. It then After some time, the overload condition at P2 subsides. It then
changes the parameter values in the response it sends to P1 to allow changes the parameter values in the response it sends to P1 to allow
P1 to send all messages destined to P2. P1 to send all messages destined to P2.
SIP/2.0 183 Queued SIP/2.0 183 Queued
Via: SIP/2.0/TLS p1.example.net; Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.4;received=192.0.2.111; branch=z9hG4bK2d4790.4;received=192.0.2.111;
oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439 oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
... ...
6.3. Default algorithm for loss-based overload control 7. The loss-based overload control scheme
Under a loss-based approach, a SIP server asks an upstream neighbor
to reduce the number of requests it would normally forward to this
server by a certain percentage. For example, a SIP server can ask an
upstream neighbor to reduce the number of requests this neighbor
would normally send by 10%. The upstream neighbor then redirects or
rejects 10% of the traffic originally destined for that server.
This section specifies the semantics of the overload control
parameters associated with the loss-based overload control scheme.
The general behaviour of SIP clients and servers is specified in
Section 5 and is applicable to SIP clients and servers that implement
loss-based overload control.
7.1. Special parameter values for loss-based overload control
The loss-based overload control scheme is identified using the token
"loss". This token MUST appear in the "oc-algo" parameter list sent
by the SIP client.
A SIP server that has selected the loss-based algorithm, upon
entering the overload state, will assign a value to the "oc"
parameter. This value MUST be in the range of [0, 100], inclusive.
This value MUST be interpreted by the client as a percentage, and the
SIP client MUST reduce the number of requests being forwarded to the
overloaded server by that percent. The SIP client may use any
algorithm that reduces the traffic it sends to the overloaded server
by the amount indicated. Such an algorithm SHOULD honor the message
prioritization discussion of Section 5.10.1. While a particular
algorithm is not subject to standardization, for completeness a
default algorithm for loss-based overload control is provided in
Section 7.2.
7.2. Default algorithm for loss-based overload control
This section describes a default algorithm that a SIP client can use This section describes a default algorithm that a SIP client can use
to throttle SIP traffic going downstream by the percentage loss value to throttle SIP traffic going downstream by the percentage loss value
specified in the "oc" parameter. specified in the "oc" parameter.
The client maintains two categories of requests; the first category The client maintains two categories of requests; the first category
will include requests that are candidates for reduction, and the will include requests that are candidates for reduction, and the
second category will include requests that are not subject to second category will include requests that are not subject to
reduction except when all messages in the first category have been reduction except when all messages in the first category have been
rejected, and further reduction is still needed. Section rejected, and further reduction is still needed. Section
skipping to change at page 23, line 8 skipping to change at page 23, line 5
Periodically (every 5-10s) get the value of the counters and calculate Periodically (every 5-10s) get the value of the counters and calculate
the ratio of category 1 messages to category 2 messages since the the ratio of category 1 messages to category 2 messages since the
last calculation. last calculation.
Example: In the last 5 seconds, a total of 500 requests arrived Example: In the last 5 seconds, a total of 500 requests arrived
at the queue. 450 out of the 500 were messages subject at the queue. 450 out of the 500 were messages subject
to reduction and 50 out of 500 were classified as requests not to reduction and 50 out of 500 were classified as requests not
subject to reduction. Based on this ratio, cat1 := 90 and subject to reduction. Based on this ratio, cat1 := 90 and
cat2 := 10, so a 90/10 mix will be used in overload calculations. cat2 := 10, so a 90/10 mix will be used in overload calculations.
7. Relationship with other IETF SIP load control efforts 8. Relationship with other IETF SIP load control efforts
The overload control mechanism described in this document is reactive The overload control mechanism described in this document is reactive
in nature and apart from message prioritization directives listed in in nature and apart from message prioritization directives listed in
Section 5.10.1 the mechanisms described in this draft will not Section 5.10.1 the mechanisms described in this draft will not
discriminate requests based on user identity, filtering action and discriminate requests based on user identity, filtering action and
arrival time. SIP networks that require pro-active overload control arrival time. SIP networks that require pro-active overload control
mechanisms can upload user-level load control filters as described in mechanisms can upload user-level load control filters as described in
[I-D.ietf-soc-load-control-event-package]. Local policy will also [I-D.ietf-soc-load-control-event-package]. Local policy will also
dictate the precedence of different overload control mechanisms dictate the precedence of different overload control mechanisms
applied to the traffic. Specifically, in a scenario where load applied to the traffic. Specifically, in a scenario where load
control filters are installed by signaling neighbours [I-D.ietf-soc- control filters are installed by signaling neighbours [I-D.ietf-soc-
load-control-event-package] and the same traffic can also be load-control-event-package] and the same traffic can also be
throttled using the overload control mechanism, local policy will throttled using the overload control mechanism, local policy will
dictate which of these schemes shall be given precedence. dictate which of these schemes shall be given precedence.
Interactions between the two schemes are out of scope for this Interactions between the two schemes are out of scope for this
document. document.
8. Syntax 9. Syntax
This specification extends the existing definition of the Via header This specification extends the existing definition of the Via header
field parameters of [RFC3261] as follows: field parameters of [RFC3261] as follows:
via-params = via-ttl / via-maddr via-params = via-ttl / via-maddr
/ via-received / via-branch / via-received / via-branch
/ oc / oc-validity / oc / oc-validity
/ oc-seq / oc-algo / via-extension / oc-seq / oc-algo / via-extension
oc = "oc" [EQUAL oc-num] oc = "oc" [EQUAL oc-num]
oc-num = 1*DIGIT oc-num = 1*DIGIT
oc-validity = "oc-validity" [EQUAL delta-ms] oc-validity = "oc-validity" [EQUAL delta-ms]
oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT
oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list) oc-algo = "oc-algo" EQUAL DQUOTE algo-list *(COMMA algo-list)
DQUOTE DQUOTE
algo-list = "loss" / *(other-algo) algo-list = "loss" / *(other-algo)
other-algo = %x41-5A / %x61-7A / %x30-39 other-algo = %x41-5A / %x61-7A / %x30-39
delta-ms = 1*DIGIT delta-ms = 1*DIGIT
9. Design Considerations 10. Design Considerations
This section discusses specific design considerations for the This section discusses specific design considerations for the
mechanism described in this document. General design considerations mechanism described in this document. General design considerations
for SIP overload control can be found in [RFC6357]. for SIP overload control can be found in [RFC6357].
9.1. SIP Mechanism 10.1. SIP Mechanism
A SIP mechanism is needed to convey overload feedback from the A SIP mechanism is needed to convey overload feedback from the
receiving to the sending SIP entity. A number of different receiving to the sending SIP entity. A number of different
alternatives exist to implement such a mechanism. alternatives exist to implement such a mechanism.
9.1.1. SIP Response Header 10.1.1. SIP Response Header
Overload control information can be transmitted using a new Via Overload control information can be transmitted using a new Via
header field parameter for overload control. A SIP server can add header field parameter for overload control. A SIP server can add
this header parameter to the responses it is sending upstream to this header parameter to the responses it is sending upstream to
provide overload control feedback to its upstream neighbors. This provide overload control feedback to its upstream neighbors. This
approach has the following characteristics: approach has the following characteristics:
o A Via header parameter is light-weight and creates very little o A Via header parameter is light-weight and creates very little
overhead. It does not require the transmission of additional overhead. It does not require the transmission of additional
messages for overload control and does not increase traffic or messages for overload control and does not increase traffic or
skipping to change at page 25, line 5 skipping to change at page 24, line 47
the transmission of overload feedback to inactive senders, which the transmission of overload feedback to inactive senders, which
do not contribute traffic. If an inactive sender starts to do not contribute traffic. If an inactive sender starts to
transmit while the receiver is in overload it will receive transmit while the receiver is in overload it will receive
overload feedback in the first response and can adjust the amount overload feedback in the first response and can adjust the amount
of traffic forwarded accordingly. of traffic forwarded accordingly.
o A SIP server can limit the distribution of overload control o A SIP server can limit the distribution of overload control
information by only inserting it into responses to known upstream information by only inserting it into responses to known upstream
neighbors. A SIP server can use transport level authentication neighbors. A SIP server can use transport level authentication
(e.g., via TLS) with its upstream neighbors. (e.g., via TLS) with its upstream neighbors.
9.1.2. SIP Event Package 10.1.2. SIP Event Package
Overload control information can also be conveyed from a receiver to Overload control information can also be conveyed from a receiver to
a sender using a new event package. Such an event package enables a a sender using a new event package. Such an event package enables a
sending entity to subscribe to the overload status of its downstream sending entity to subscribe to the overload status of its downstream
neighbors and receive notifications of overload control status neighbors and receive notifications of overload control status
changes in NOTIFY requests. This approach has the following changes in NOTIFY requests. This approach has the following
characteristics: characteristics:
o Overload control information is conveyed decoupled from SIP o Overload control information is conveyed decoupled from SIP
signaling. It enables an overload control manager, which is a signaling. It enables an overload control manager, which is a
skipping to change at page 26, line 5 skipping to change at page 25, line 45
implemented in all servers these request will pass through. implemented in all servers these request will pass through.
o As overload feedback is sent to all senders in separate messages, o As overload feedback is sent to all senders in separate messages,
this mechanism is not suitable when frequent overload control this mechanism is not suitable when frequent overload control
feedback is needed. feedback is needed.
o A SIP server can limit the set of senders that can receive o A SIP server can limit the set of senders that can receive
overload control information by authenticating subscriptions to overload control information by authenticating subscriptions to
this event package. this event package.
o This approach requires each proxy to implement user agent o This approach requires each proxy to implement user agent
functionality (UAS and UAC) to manage the subscriptions. functionality (UAS and UAC) to manage the subscriptions.
9.2. Backwards Compatibility 10.2. Backwards Compatibility
An new overload control mechanism needs to be backwards compatible so An new overload control mechanism needs to be backwards compatible so
that it can be gradually introduced into a network and functions that it can be gradually introduced into a network and functions
properly if only a fraction of the servers support it. properly if only a fraction of the servers support it.
Hop-by-hop overload control (see [RFC6357]) has the advantage that it Hop-by-hop overload control (see [RFC6357]) has the advantage that it
does not require that all SIP entities in a network support it. It does not require that all SIP entities in a network support it. It
can be used effectively between two adjacent SIP servers if both can be used effectively between two adjacent SIP servers if both
servers support overload control and does not depend on the support servers support overload control and does not depend on the support
from any other server or user agent. The more SIP servers in a from any other server or user agent. The more SIP servers in a
skipping to change at page 26, line 31 skipping to change at page 26, line 23
overload control mechanism, only those that support it would reduce overload control mechanism, only those that support it would reduce
traffic. Others would keep sending at the full rate and benefit from traffic. Others would keep sending at the full rate and benefit from
the throttling by the servers that support overload control. In the throttling by the servers that support overload control. In
other words, upstream neighbors that do not support overload control other words, upstream neighbors that do not support overload control
would be better off than those that do. would be better off than those that do.
A SIP server should therefore follow the behaviour outlined in A SIP server should therefore follow the behaviour outlined in
Section 5.10.2 to handle clients that do not support overload Section 5.10.2 to handle clients that do not support overload
control. control.
10. Security Considerations 11. Security Considerations
Overload control mechanisms can be used by an attacker to conduct a Overload control mechanisms can be used by an attacker to conduct a
denial-of-service attack on a SIP entity if the attacker can pretend denial-of-service attack on a SIP entity if the attacker can pretend
that the SIP entity is overloaded. When such a forged overload that the SIP entity is overloaded. When such a forged overload
indication is received by an upstream SIP client, it will stop indication is received by an upstream SIP client, it will stop
sending traffic to the victim. Thus, the victim is subject to a sending traffic to the victim. Thus, the victim is subject to a
denial-of-service attack. denial-of-service attack.
An attacker can create forged overload feedback by inserting itself To better understand the threat model, consider the following
into the communication between the victim and its upstream neighbors. diagram:
The attacker would need to add overload feedback indicating a high
load to the responses passed from the victim to its upstream Pa ------- ------ Pb
neighbor. Proxies can prevent this attack by communicating via TLS. \ /
Since overload feedback has no meaning beyond the next hop, there is : ------ +-------- P1 ------+------ :
no need to secure the communication over multiple hops. / L1 L2 \
: ------- ------ :
-----> Downstream (requests)
<----- Upstream (responses)
Here, requests travel downstream from the left-hand side, through
Proxy P1, towards the right-hand side, and responses travel upstream
from the right-hand side, through P1, towards the left hand side.
Proxies Pa, Pb and P1 support overload control. L1 and L2 are labels
for the links connecting P1 to the upstream clients and downstream
servers.
If an attacker is able to modify traffic between Pa and P1 on link
L1, it can cause denial of service attack on P1 by having Pa not send
any traffic to P1. Such an attack can proceed by the attacker
modifying the response from P1 to Pa such that Pa's Via header is
changed to indicate that all requests destined towards P1 should be
dropped. Conversely, the attacker can simply remove any "oc", "oc-
validity" and "oc-seq" markings added by P1 in a response to Pa. In
such a case, the attacker will force P1 into overload control by
denying request quenching at Pa even though Pa is capable of
performing overload control.
Similarly, if an attacker is able to modify traffic between P1 and Pb
on link L2, it can change the Via header associated with P1 in a
response from Pb to P1 such that all subsequent requests destined
towards Pb from P1 are dropped. In essence, the attacker mounts a
denial of service attack on Pb by indicating false overload control.
Note that it is immaterial whether Pb supports overload control or
not, the attack will succeed as long as the attacker is able to
control L2. Conversely, an attacker can suppress a genuine overload
condition at Pb by simply remove any "oc", "oc-validity" and "oc-seq"
markings added by Pb in a response to P1. In such a case, the
attacker will force P1 into sending requests to Pb even under
overload conditions because P1 would not be aware aware that Pb
supports overload control.
Attacks that indicate false overload control can be mitigated by
using TCP or Websockets [RFC6455], or better yet, TLS in conjunction
with applying BCP 38 [RFC2827]. Attacks that are mounted to suppress
genuine overload conditions can be avoided by using TLS on the
connection.
Another way to conduct an attack is to send a message containing a Another way to conduct an attack is to send a message containing a
high overload feedback value through a proxy that does not support high overload feedback value through a proxy that does not support
this extension. If this feedback is added to the second Via headers this extension. If this feedback is added to the second Via header
(or all Via headers), it will reach the next upstream proxy. If the (or all Via headers), it will reach the next upstream proxy. If the
attacker can make the recipient believe that the overload status was attacker can make the recipient believe that the overload status was
created by its direct downstream neighbor (and not by the attacker created by its direct downstream neighbor (and not by the attacker
further downstream) the recipient stops sending traffic to the further downstream) the recipient stops sending traffic to the
victim. A precondition for this attack is that the victim proxy does victim. A precondition for this attack is that the victim proxy does
not support this extension since it would not pass through overload not support this extension since it would not pass through overload
control feedback otherwise. control feedback otherwise.
A malicious SIP entity could gain an advantage by pretending to A malicious SIP entity could gain an advantage by pretending to
support this specification but never reducing the amount of traffic support this specification but never reducing the amount of traffic
skipping to change at page 27, line 25 skipping to change at page 28, line 14
overload control, the malicious SIP entity would benefit since all overload control, the malicious SIP entity would benefit since all
other sources to its downstream neighbor would reduce load. other sources to its downstream neighbor would reduce load.
The solution to this problem depends on the overload control The solution to this problem depends on the overload control
method. For rate-based and window-based overload control, it is method. For rate-based and window-based overload control, it is
very easy for a downstream entity to monitor if the upstream very easy for a downstream entity to monitor if the upstream
neighbor throttles traffic forwarded as directed. For percentage neighbor throttles traffic forwarded as directed. For percentage
throttling this is not always obvious since the load forwarded throttling this is not always obvious since the load forwarded
depends on the load received by the upstream neighbor. depends on the load received by the upstream neighbor.
11. IANA Considerations To prevent such attacks, servers should monitor client behavior to
determine whether they are complying with overload control policies.
If a client is not conforming to such policies, then the server
should treat it as a non-supporting client (see Section 5.10.2).
12. IANA Considerations
This specification defines four new Via header parameters as detailed This specification defines four new Via header parameters as detailed
below in the "Header Field Parameter and Parameter Values" sub- below in the "Header Field Parameter and Parameter Values" sub-
registry as per the registry created by [RFC3968]. The required registry as per the registry created by [RFC3968]. The required
information is: information is:
Header Field Parameter Name Predefined Values Reference Header Field Parameter Name Predefined Values Reference
__________________________________________________________ __________________________________________________________
Via oc Yes RFCXXXX Via oc Yes RFCXXXX
Via oc-validity Yes RFCXXXX Via oc-validity Yes RFCXXXX
Via oc-seq Yes RFCXXXX Via oc-seq Yes RFCXXXX
Via oc-algo Yes RFCXXXX Via oc-algo Yes RFCXXXX
RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC RFC XXXX [NOTE TO RFC-EDITOR: Please replace with final RFC
number of this specification.] number of this specification.]
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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
skipping to change at page 28, line 23 skipping to change at page 29, line 16
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority [RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session (IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968, Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004. December 2004.
[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, February 2006. RFC 4412, February 2006.
12.2. Informative References 13.2. Informative References
[I-D.ietf-soc-load-control-event-package] [I-D.ietf-soc-load-control-event-package]
Shen, C., Schulzrinne, H., and A. Koike, "A Session Shen, C., Schulzrinne, H., and A. Koike, "A Session
Initiation Protocol (SIP) Load Control Event Package", Initiation Protocol (SIP) Load Control Event Package",
draft-ietf-soc-load-control-event-package-08 (work in draft-ietf-soc-load-control-event-package-10 (work in
progress), March 2013. progress), November 2013.
[I-D.ietf-soc-overload-rate-control] [I-D.ietf-soc-overload-rate-control]
Noel, E. and P. Williams, "Session Initiation Protocol Noel, E. and P. Williams, "Session Initiation Protocol
(SIP) Rate Control", (SIP) Rate Control",
draft-ietf-soc-overload-rate-control-04 (work in draft-ietf-soc-overload-rate-control-06 (work in
progress), April 2013. progress), October 2013.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in [RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008. the Session Initiation Protocol", RFC 5390, December 2008.
[RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design [RFC6357] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
Considerations for Session Initiation Protocol (SIP) Considerations for Session Initiation Protocol (SIP)
Overload Control", RFC 6357, August 2011. Overload Control", RFC 6357, August 2011.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors acknowledge the contributions of Bruno Chatras, Keith The authors acknowledge the contributions of Bruno Chatras, Keith
Drage, Janet Gunn, Rich Terpstra, Daryl Malas, Eric Noel, R. Drage, Janet Gunn, Rich Terpstra, Daryl Malas, Eric Noel, R.
Parthasarathi, Antoine Roly, Jonathan Rosenberg, Charles Shen, Rahul Parthasarathi, Antoine Roly, Jonathan Rosenberg, Charles Shen, Rahul
Srivastava, Padma Valluri, Shaun Bharrat, Paul Kyzivat and Jeroen Van Srivastava, Padma Valluri, Shaun Bharrat, Paul Kyzivat and Jeroen Van
Bemmel to this document. Bemmel to this document.
Adam Roach and Eric McMurry helped flesh out the different cases for Adam Roach and Eric McMurry helped flesh out the different cases for
handling SIP messages described in the algorithm of Section 6.3. handling SIP messages described in the algorithm of Section 7.2.
Janet Gunn reviewed the algorithm and suggested changes that lead to Janet Gunn reviewed the algorithm and suggested changes that lead to
simpler processing for the case where "oc_value > cat1". simpler processing for the case where "oc_value > cat1".
Richard Barnes provided invaluable comments as part of area director
review of the draft.
Appendix B. RFC5390 requirements Appendix B. RFC5390 requirements
Table 1 provides a summary how this specification fulfills the Table 1 provides a summary how this specification fulfills the
requirements of [RFC5390]. A more detailed view on how each requirements of [RFC5390]. A more detailed view on how each
requirements is fulfilled is provided after the table. requirements is fulfilled is provided after the table.
+-------------+-------------------+ +-------------+-------------------+
| Requirement | Meets requirement | | Requirement | Meets requirement |
+-------------+-------------------+ +-------------+-------------------+
| REQ 1 | Yes | | REQ 1 | Yes |
skipping to change at page 31, line 21 skipping to change at page 33, line 4
REQ 5: The mechanism should not assume that it will only be deployed REQ 5: The mechanism should not assume that it will only be deployed
in environments with completely trusted elements. It should seek to in environments with completely trusted elements. It should seek to
operate as effectively as possible in environments where other operate as effectively as possible in environments where other
elements are malicious; this includes preventing malicious elements elements are malicious; this includes preventing malicious elements
from obtaining more than a fair share of service. from obtaining more than a fair share of service.
Meeting REQ 5: Partially. Since overload control information is Meeting REQ 5: Partially. Since overload control information is
shared between a pair of communicating entities, a confidential and shared between a pair of communicating entities, a confidential and
authenticated channel can be used for this communication. However, authenticated channel can be used for this communication. However,
if such a channel is not available, then the security ramifications if such a channel is not available, then the security ramifications
outlined in Section 10 apply. outlined in Section 11 apply.
REQ 6: When overload is signaled by means of a specific message, the REQ 6: When overload is signaled by means of a specific message, the
message must clearly indicate that it is being sent because of message must clearly indicate that it is being sent because of
overload, as opposed to other, non overload-based failure conditions. overload, as opposed to other, non overload-based failure conditions.
This requirement is meant to avoid some of the problems that have This requirement is meant to avoid some of the problems that have
arisen from the reuse of the 503 response code for multiple purposes. arisen from the reuse of the 503 response code for multiple purposes.
Of course, overload is also signaled by lack of response to requests. Of course, overload is also signaled by lack of response to requests.
This requirement applies only to explicit overload signals. This requirement applies only to explicit overload signals.
Meeting REQ 6: Not applicable. Overload control information is Meeting REQ 6: Not applicable. Overload control information is
skipping to change at page 33, line 29 skipping to change at page 35, line 15
Meeting REQ 16: Yes, overload control messages are sent in the Meeting REQ 16: Yes, overload control messages are sent in the
topmost Via header, which is always processed by the SIP elements. topmost Via header, which is always processed by the SIP elements.
REQ 17: The overload mechanism must not provide an avenue for REQ 17: The overload mechanism must not provide an avenue for
malicious attack, including DoS and DDoS attacks. malicious attack, including DoS and DDoS attacks.
Meeting REQ 17: Partially. Since overload control information is Meeting REQ 17: Partially. Since overload control information is
shared between a pair of communicating entities, a confidential and shared between a pair of communicating entities, a confidential and
authenticated channel can be used for this communication. However, authenticated channel can be used for this communication. However,
if such a channel is not available, then the security ramifications if such a channel is not available, then the security ramifications
outlined in Section 10 apply. outlined in Section 11 apply.
REQ 18: The overload mechanism should be unambiguous about whether a REQ 18: The overload mechanism should be unambiguous about whether a
load indication applies to a specific IP address, host, or URI, so load indication applies to a specific IP address, host, or URI, so
that an upstream element can determine the load of the entity to that an upstream element can determine the load of the entity to
which a request is to be sent. which a request is to be sent.
Meeting REQ 18: Yes, please see discussion in Section 5.5. Meeting REQ 18: Yes, please see discussion in Section 5.5.
REQ 19: The specification for the overload mechanism should give REQ 19: The specification for the overload mechanism should give
guidance on which message types might be desirable to process over guidance on which message types might be desirable to process over
 End of changes. 42 change blocks. 
138 lines changed or deleted 191 lines changed or added

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