One document matched: draft-gurbani-soc-overload-control-01.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3263 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml'>
<!ENTITY rfc4412 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4412.xml'>
<!ENTITY rfc5390 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5390.xml'>
<!ENTITY i-d.ietf-soc-overload-design PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-soc-overload-design.xml'>]>
<rfc ipr='trust200902' category='std' docName="DOCNAME">
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc sortrefs='yes'?>
<?rfc symrefs="yes"?>
<front>
<title abbrev='Overload Control'>Session Initiation Protocol (SIP)
Overload Control</title>
<author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani" role="editor">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>1960 Lucent Lane, Rm 9C-533</street>
<city>Naperville</city> <region>IL</region>
<code>60563</code>
<country>USA</country>
</postal>
<email>vkg@bell-labs.com</email>
</address>
</author>
<author initials='V.H.' surname='Hilt' fullname='Volker Hilt'>
<organization>Bell Labs/Alcatel-Lucent</organization>
<address>
<postal>
<street>791 Holmdel-Keyport Rd</street>
<city>Holmdel</city> <region>NJ</region>
<code>07733</code>
<country>USA</country>
</postal>
<email>volkerh@bell-labs.com</email>
</address>
</author>
<author initials='H.S.' surname='Schulzrinne' fullname='Henning Schulzrinne'>
<organization abbrev='Columbia University'>Columbia University/Department
of Computer Science</organization>
<address>
<postal>
<street>450 Computer Science Building</street>
<city>New York</city> <region>NY</region>
<code>10027</code>
<country>USA</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<date year='2010' />
<area>RAI</area>
<workgroup>SOC Working Group</workgroup>
<keyword>SIP</keyword>
<keyword>Overload Control</keyword>
<abstract>
<t>Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document defines an overload control mechanism for SIP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As with any network element, a Session Initiation Protocol
(SIP) <xref target="RFC3261" /> server can suffer from overload
when the number of SIP messages it receives exceeds the number of
messages it can process. Overload can pose a serious problem for a
network of SIP servers. During periods of overload, the throughput
of a network of SIP servers can be significantly degraded. In
fact, overload may lead to a situation in which the throughput
drops down to a small fraction of the original processing
capacity. This is often called congestion collapse.</t>
<t>Overload is said to occur if a SIP server does not have
sufficient resources to process all incoming SIP messages. These
resources may include CPU processing capacity, memory,
network bandwidth, input/output, or disk resources.</t>
<t>For overload control, we only consider failure cases where SIP
servers are unable to process all SIP requests due to resource
constraints. There are other cases where a SIP server can
successfully process incoming requests but has to reject them due
to failure conditions unrelated to the SIP server being overloaded.
For example, a PSTN gateway that runs out of trunk lines but
still has plenty of capacity to process SIP messages should
reject incoming INVITEs using a 488 (Not
Acceptable Here) response <xref target="RFC4412" />. Similarly, a
SIP registrar that has lost connectivity to its registration
database but is still capable of processing SIP messages should
reject REGISTER requests with a 500 (Server Error) response <xref
target="RFC3261" />. Overload control does not apply to these
cases and SIP provides appropriate response codes for them.</t>
<t>The SIP protocol provides a limited mechanism for overload
control through its 503 (Service Unavailable) response
code. However, this mechanism cannot prevent overload of a SIP
server and it cannot prevent congestion collapse. In fact, the use
of the 503 (Service Unavailable) response code may cause traffic
to oscillate and to shift between SIP servers and thereby worsen
an overload condition. A detailed discussion of the SIP overload
problem, the problems with the 503 (Service Unavailable) response
code and the requirements for a SIP overload control mechanism can
be found in <xref target="RFC5390" />.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Overview of operations" anchor="sec:overview">
<t>We now explain the overview of how the overload control
mechanism operates by introducing the overload control parameters.
<xref target="sec:header"/> provides more details and
normative behavior on the parameters listed below.</t>
<t>Because overload control is best performed hop-by-hop, the
Via parameter is attractive since it allows two adjacent SIP
entities to indicate support for, and exchange information associated
with overload control. This document defines five new parameters
for the SIP Via header for overload control. These parameters provide
a SIP mechanism for conveying overload control information between
adjacent SIP entities.) These parameters are:</t>
<t><list style="numbers">
<t>oc-accept: Inserted by a SIP entity sending a request downstream.
This parameter indicates that the SIP entity inserting (or
removing) this parameter supports overload control as
specified by this document (c.f. <xref target="oc-accept"/>.
This parameter does not have an associated value.</t>
<t>oc: Inserted by the SIP entity sending a response upstream.
This parameter contains a value that indicates a loss rate
(in percentage) by which the load arriving at the SIP entity
should be reduced (c.f.
<xref target="oc-create"/>, <xref target="oc-determine"/>,
<xref target="oc-process"/> and <xref target="oc-use"/>.)</t>
<t>oc-validity: Inserted by the SIP entity sending a response
upstream. This parameter contains a value that indicates the time
(in ms) that the load reduction specified by the 'oc' parameter should
be in effect (c.f. <xref target="oc-create"/>.)</t>
<t>oc-seq: Inserted by the SIP entity sending a response upstream.
This is an optional parameter. This parameter contains a value
that indicates the sequence number associated with the "oc" parameter
defined above (c.f. Section <xref target="oc-create"/>).</t>
<t>oc-port: Inserted by the SIP entity sending a response upstream.
This is an optional parameter and does not have an associated value.
This parameter indicates that overload control should be
performed by the upstream SIP server only on subsequent
requests destined to the same port that the earlier request
carrying the "oc-accept" parameter was sent to. The absence of
this parameter in the response indicates that overload control
is to be applied to SIP traffic destined to the IP address
irrespective of any specific port on that IP address (c.f.
Section <xref target="oc-create"/>.)</t>
</list></t>
<t>Consider a proxy P1 that is sending requests to another
downstream proxy, P2. The following snippets of SIP messages
demonstrate how the overload control parameters work.</t>
<figure><artwork><![CDATA[
INVITE sips:user@example.com SIP/2.0
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;oc-accept
...
SIP/2.0 100 Trying
Via: SIP/2.0/TLS p1.example.net;
branch=z9hG4bK2d4790.1;received=192.0.2.111;
oc=20;oc-validity=500;oc-seq=87165
...
]]></artwork></figure>
<t>In the messages above, the first line is sent by P1 to P2.
This line is a SIP request; because P1 supports overload control,
it inserts the "oc-accept" parameter in the topmost Via header
that it created.</t>
<t>The second line --- a SIP response --- shows the topmost Via
header amended by P2 according to this specification and sent to
P1. Because P2 also supports overload control, it sends back further
overload control parameters towards P1 requesting that P1 reduce the
incoming traffic by 20% for 500ms.</t>
</section> <!-- sec:overview -->
<section title="Via Header Parameters for Overload Control"
anchor="sec:header">
<section title="The 'oc_accept' Parameter" anchor="oc-accept">
<t>A SIP server that supports this specification MUST add
an "oc_accept" parameter to the Via headers it inserts into SIP
requests. This provides an indication to downstream neighbors
that this server supports overload control.</t>
<t>A SIP server MUST remove the 'oc_accept' parameter from
the topmost Via header in a response before forwarding the
response. The topmost Via header is determined after the SIP
server has removed its own Via header. The topmost Via header
corresponds to the upstream neighbor of the SIP server
processing the response, and the 'oc-accept' parameter was
added by the upstream neighbor when the request was proxied
by the upstream neighbor.
<list style="hanging">
<t></t>
<t>Removing the 'oc-accept' parameter from the topmost
Via header before forwarding the response upstream has
the property that the upstream entity knows that the
downstream SIP server is capable of supporting overload
control as specified by this document. This is true even
if the downstream SIP server is currently not experiencing
an overload situation and therefore did not insert
other overload related parameters.</t>
</list>
</t>
<!--
<t><list>
<t>OPEN ISSUE: To throttle upstream neighbors in a fair way,
it is important that a SIP server can estimate the load each
upstream neighbor receives for this server before it is
throttled. This enables the server to throttle each upstream
neighbor in the same way and thus provides each request the
same chance of succeeding. In rate- and window-based overload
control systems, a SIP server does not know how many messages
each upstream neighbor had received for the server before
throttling took place. A solution to this problem is to allow
servers to report the unthrottled load for a downstream neighbor
in the 'oc_accept' parameter.</t>
</list></t>
-->
</section>
<section title="Creating the Overload Control Parameters"
anchor="oc-create">
<t>A SIP server can provide overload control feedback to its
upstream neighbors by adding the 'oc' parameter to the topmost
Via header field of a SIP response. The 'oc' parameter is a new
Via header parameter defined in this specification. When an 'oc'
parameter is added to a response, it MUST be inserted into the
topmost Via header. It MUST NOT be added to any other Via header
in the response. The topmost Via header is determined after the
SIP server has removed its own Via header; i.e., it is the Via
header that was generated by the upstream neighbor.</t>
<t>Since the topmost Via header of a response will be removed by
an upstream neighbor after processing it, overload control
feedback contained in the 'oc' parameter will not travel beyond
the upstream SIP server. A Via header parameter therefore provides
hop-by-hop semantics for overload control feedback (see <xref
target="I-D.ietf-soc-overload-design" />) even if the
next hop neighbor does not support this specification.</t>
<t>The 'oc' parameter can be used in all response types,
including provisional, success and failure responses. A SIP
server MAY add the 'oc' parameter to all responses it
is sending. A SIP server SHOULD add an 'oc' parameter to
responses, that contain an 'oc_accept' parameter in the topmost
Via header. A SIP server MUST add an 'oc' parameter to responses
when the transmission of overload control feedback is required
by the overload control algorithm to limit the traffic received
by the server. I.e., a SIP server MUST insert the 'oc' parameter
when the overload control algorithm sets the 'oc' parameter to a
value different than the default value.</t>
<t>A SIP server that has added an 'oc' parameter to Via header
SHOULD also add a 'oc_validity' parameter to the same Via
header. The 'oc_validity' parameter defines the time in
milliseconds during which the content (i.e., the overload
control feedback) of the 'oc' parameter is valid. The default
value of the 'oc_validity' parameter is 500. A SIP server SHOULD
use a shorter 'oc_validity' time if its overload status varies
quickly and MAY use a longer 'oc_validity' time if this status
is more stable. If the 'oc_validity' parameter is not present,
its default value is used. The 'oc_validity' parameter MUST NOT
be used in a Via header without an 'oc' parameter and MUST be
ignored if it appears in a Via header without 'oc' parameter.</t>
<t>When a SIP server retransmits a response, it SHOULD
use the 'oc' parameter value and 'oc-validity' parameter
value consistent with the overload state at the time the
retransmitted response is sent. This implies that the
values in the 'oc' and 'oc-validity' parameters may be
different then the ones used in previous retransmissions
of the response. Due to the fact that responses sent over
UDP may be subject to delays in the network and arrive
out of order, the 'oc-seq' parameter aids in detecting a
stale 'oc' parameter value.</t>
<t>Implementations that are capable of updating the 'oc'
and 'oc-validity' parameter values for retransmissions MUST
insert the 'oc-seq' parameter. The value of this parameter
MUST be a set of numbers drawn from an increasing sequence.
One way to achieve this is to use a monotonically increasing
sequence number that is less than 2**31 and wraps to 0 when
the maximum number is generated. Another way to generate the
value of the 'oc-seq' parameter is to use the current timestamp
with millisecond precision.</t>
<t>Implementations that are not capable of updating the 'oc'
and 'oc-validity' parameter values for retransmissions --- or
implementations that do not want to do so because they will
have to regenerate the message to be retransmitted --- MUST
still insert a 'oc-seq' parameter in the first response
associated with a transaction; however, they do not have to
update the value in subsequent retransmissions.</t>
<!-- Ed. note: The discussion that lead to the above is
captured in
http://www.ietf.org/mail-archive/web/sip-overload/
current/msg00250.html
-->
<t>The 'oc-port' parameter is inserted by a SIP server in
the response if it is only interested in throttling traffic
to a specific destination port. This is an optional parameter
and does not have any value associated with it.</t>
<t><list>
<t>A node identified by a certain
IP address may be hosting multiple SIP servers listening on
different ports. In some architectures, the same IP address
is shared by different blades and a SIP server listens on
a distinct port on a separate blade. In yet other architectures
with multi-core CPUs or multiple CPUs, an administrator may
assign a CPU to a specific SIP server, but the node itself has
more capacity in form of unused CPUs or unused blades.
Consequently, throttling traffic destined to a specific port
seems reasonable.</t>
</list></t>
<t>The semantics of the 'oc-port' parameter --- its absence
or presence in a SIP response --- on the upstream SIP server
are further outlined in <xref target="oc-use"/>.</t>
<t>The 'oc', 'oc_validity', 'oc-port' and 'oc-seq' Via header
parameters are only defined in SIP responses and MUST NOT be
used in SIP requests. These parameters are only useful to the
upstream neighbor of a SIP server (i.e., the entity that is
sending requests to the SIP server) since this is the entity
that can offload traffic by redirecting/rejecting new requests.
If requests are forwarded in both directions between two SIP
servers (i.e., the roles of upstream/downstream neighbors
change), there are also responses flowing in both
directions. Thus, both SIP servers can exchange overload
information.</t>
<t>While adding 'oc' and 'oc_validity' parameters to
requests may increase the frequency with which overload
information is exchanged in these scenarios, this increase will
rarely provide benefits and does not justify the added overhead
and complexity needed.</t>
<t>Since overload control protects a SIP server from overload,
it is RECOMMENDED that a SIP server generally inserts 'oc' and
'oc_validity' parameters into responses to all SIP servers.
However, if a SIP server wanted to limit its overload control
capability for privacy reasons, it MAY decide to add 'oc' and
'oc_validity' parameters only to responses that are sent via a
secured transport channel such as TLS. The SIP server can use
transport level authentication to identify the SIP servers, to which
responses with these parameters are sent. This enables a SIP
server to protect overload control information and ensure that
it is only visible to trusted parties. </t>
</section>
<section title="Determining the 'oc' Parameter Value"
anchor="oc-determine">
<t>The value of the 'oc' parameter is determined by an overload
control algorithm (see <xref
target="I-D.ietf-soc-overload-design" />). This
specification does not mandate the use of a specific overload
control algorithm. However, the output of an overload control
algorithm MUST be compliant to the semantics of this Via header
parameter.</t>
<t>The 'oc' parameter value specifies the percentage by which
the load forwarded to this SIP server should be
reduced. Possible values range from 0 (the traffic forwarded is
reduced by 0%, i.e., all traffic is forwarded) to 100 (the
traffic forwarded is reduced by 100%, i.e., no traffic
forwarded). The default value of this parameter is 0.</t>
<t><list>
<t>OPEN ISSUE 1: The 'oc' parameter value specified in this document
is defined to contain a loss rate. However, other types of
overload control feedback exist, for example, a target rate for
rate-based overload control or message confirmations and
window-size for window-based overload control. </t>
<t></t>
<t>While it would in theory be possible to allow multiple
types of overload control feedback to co-exist (e.g., by using
different parameters for the different feedback types) it is
very problematic for interoperability purposes and would
require SIP servers to implement multiple overload control
mechanisms.</t>
</list></t>
</section>
<section title="Processing the Overload Control Parameters"
anchor="oc-process">
<t>A SIP entity compliant to this specification SHOULD remove
'oc', 'oc_validity', 'oc-seq' and if present, the 'oc-port'
parameters from all Via headers of a
response received, except for the topmost Via header. This
prevents overload control parameters that were accidentally or
maliciously inserted into Via headers by a downstream SIP server
from traveling upstream.</t>
<t>A SIP server maintains the 'oc' parameter values received
along with the address and port number of the SIP servers from
which they were received for the duration specified in the
'oc_validity' parameter or the default duration. Each time a
SIP server receives a response with an 'oc' parameter from a
downstream SIP server, it overwrites the 'oc' value it has
currently stored for this server with the new value received.
The SIP server restarts the validity period of an 'oc' parameter
each time a response with an 'oc' parameter is received from
this server. A stored 'oc' parameter value MUST be discarded once
it has reached the end of its validity.</t>
</section>
<section title="Using the Overload Control Parameter Values"
anchor="oc-use">
<t>A SIP server compliant to this specification MUST honor 'oc'
parameter values it receives from downstream neighbors. The SIP
server MUST NOT forward more messages to a SIP server than
allowed by the current 'oc' and 'oc-port' parameter values from
this server.</t>
<t>When forwarding a SIP request, a SIP entity uses the SIP
procedures of <xref target="RFC3263"/> to determine the next
hop SIP server. The procedures of <xref target="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) 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 (the "Expected Output").</t>
<t>After selecting a specific SIP server from the Expected Output,
the SIP server MUST determine if it already has overload control
parameter values for the server chosen from the Expected Output.
If the SIP server has a non-expired 'oc' parameter value for
the server chosen from the Expected Output, and this chosen server
had restricted throttling to a specific port (by setting the
'oc-port' parameter earlier), then the SIP server MUST determine
if it can or cannot forward the current request within the
current conditions.</t>
<t>The SIP server SHOULD use the following algorithm to determine
if it can forward the request. The SIP server draws a random
number between 1 and 100 for the current request. If the random
number is less than or equal to the 'oc' parameter value, the
request is not forwarded. Otherwise, the request is
forwarded (note that this algorithm does not prioritize the
requests it is dropping --- c.f. OPEN ISSUE 3 in <xref target=
"msg-priority"/>.) Any other algorithms that
approximate the random number algorithm may be used as well.</t>
<!--
<t><list>
<t>OPEN ISSUE: the specific mechanisms to throttle traffic
depend on the type of feedback conveyed in the 'oc' parameter
value. It needs to be defined depending on whether a
loss-based, rate-based or window-based feedback is used.</t>
</list></t>
<t>The treatment of SIP requests that cannot be forwarded to the
selected SIP Server is a matter of local policy. A SIP entity
MAY try to find an alternative target or it MAY reject the
request (see <xref target="sec:5xx" />).</t>
-->
</section>
<section title="Forwarding the overload control parameters"
anchor="sec:forward">
<t>A SIP server MAY forward the content of an 'oc' parameter it
has received from a downstream neighbor on to its upstream
neighbor. However, forwarding the content of the 'oc' parameter
is generally NOT RECOMMENDED and should only be performed if
permitted by the configuration of SIP servers. For example, a
SIP server that only relays messages between exactly two SIP
servers may forward an 'oc' parameter. The 'oc' parameter is
forwarded by copying it from the Via in which it was received
into the next Via header (i.e., the Via header that will be on
top after processing the response). If an 'oc_validity'
parameter is present, MUST be copied along with the 'oc'
parameter.</t>
</section> <!-- sec:forward -->
<section title="Self-Limiting">
<t>In some cases, a SIP server may not receive a response from a
downstream neighbor when sending a request. <xref
target="RFC3261">RFC3261</xref> defines that when a timeout
error is received from the transaction layer, it MUST be treated
as if a 408 (Request Timeout) status code has been received. If
a fatal transport error is reported by the transport layer, it
MUST be treated as a 503 (Service Unavailable) status code.</t>
<t>In these cases, a SIP server MUST stop sending requests to
this server. The SIP server SHOULD occasionally forward a single
request to probe if the downstream neighbor is alive. Once a SIP
server has successfully transmitted a request to the downstream
neighbor, it can resume normal transmission of requests. It
should, of course, honor an 'oc' parameters it may receive. This
avoids that a SIP server, which is unable to respond to incoming
requests, is overloaded with additional requests. </t>
<t><list>
<t>OPEN ISSUE 2: If a downstream neighbor does not respond to
a request at all, the upstream SIP server will stop sending
requests to the downstream neighbor. The upstream SIP server
will periodically forward a single request to probe the
health of its downstream neighbor. It has been suggested ---
see
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00229.html
--- that we have a notification mechanism in place for the
downstream neighbor to signal to the upstream SIP server that it
is ready to receive requests. This notification scheme has
advantages, but comes with obvious disadvantages as well. Need
some more discussion around this.</t>
</list></t>
<!--
<t><list>
<t>OPEN ISSUE: waiting for a timeout to occur seems a long time
before starting to throttle back. It could make sense to
throttle back earlier if no response is received for requests
transmitted.</t>
</list></t>
-->
</section>
</section>
<section title="Responding to an Overload Indication">
<t>An element can receive overload control feedback indicating
that it needs to reduce the traffic it sends to its downstream
neighbor. An element can accomplish this task by sending some of
the requests that would have gone to the overloaded element to a
different destination. It needs to ensure, however, that this
destination is not in overload and capable of processing the
extra load. An element can also buffer requests in the hope that
the overload condition will resolve quickly and the requests
still can be forwarded in time. In many cases, however, it will
need to reject these requests.</t>
<section title="Message Prioritization" anchor="msg-priority">
<t>During an overload condition, a SIP server needs to
prioritize messages and select messages that need to be rejected
or redirected. While this selection is largely a matter of local
policy, certain heuristics can be suggested. One, during overload
control, the SIP server should preserve existing dialogs as much
as possible. This suggests that mid-dialog requests MAY be
given preferential treatment. Similarly, requests that result in
releasing resources (such as a BYE) MAY also be given
preferential treatment.</t>
<t>A SIP server SHOULD honor a request containing the
Resource-Priority header field <xref target="RFC4412">RFC4412</xref>.
Resource-Priority header field enables a proxy to identify
high-priority requests, such as emergency service requests, and
preserve them as much as possible during times of overload.</t>
<t><list>
<t>OPEN ISSUE 3: The process by which the upstream server
selects messages to be rejected to reduce load needs to be
discussed further. Clearly, SIP messages that contain the
Resource-Priority header should not be rejected. Also, mid-
dialog requests (re-INVITEs, UPDATEs, BYEs etc.) should be
honored, if possible. This can be left as a policy decision
with guidelines provided --- example, if a request has both
the To tag and From tag, do not drop it since it is a mid-
dialog request; do not drop requests with the Resource-Priority
header, etc. Some discussion on this is captured in
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00272.html.
</t>
<t></t>
<t>This issue also has a bearing on the algorithm outlined in
Section <xref target="oc-use"/>.</t>
</list></t>
</section>
<section title="Rejecting Requests" anchor="sec:5xx">
<t>A SIP server that rejects a request because of overload MUST
reject this request with a 503 (Service Unavailable) response
code. This response code indicates that the request did not
succeed because the SIP servers processing the request are under
overload.</t>
<t>A SIP server that is under overload and has started to
throttle incoming traffic SHOULD use 503 responses without
Retry-After header to reject a fraction of requests from
upstream neighbors that do not include the 'oc_accept' parameter
in their Via headers. These neighbors do not support this
specification and will not respond to overload control feedback
in the 'oc' parameter. If the upstream server does not
support "oc" then the downstream server must bear the cost
of rejecting some session requests as well as the cost of
processing other requests to completion. It would be fair to
devote the same amount of processing at the overloaded server
to the combination of rejection and processing, as the overloaded
server would devote to processing requests from an overload
compliant upstream server (note to editor: reword later.)
This is to ensure that SIP servers, which do not support this
specification, don't receive an unfair advantage over those that
do. </t>
<t>A SIP server that has reached overload (i.e., a load close to
100) SHOULD start using 503 responses in addition to using the
'oc' parameter for all upstream neighbors. If the proxy has
reached a load close to 100, it needs to protect itself against
overload. Also, it is likely that upstream proxies have ignored
overload feedback and do not support this specification. </t>
</section>
</section>
<section title="Syntax" anchor="sec:syntax">
<t>This section defines the syntax of new Via header
parameters: 'oc', 'oc_validity', 'oc_accept', 'oc-port' and
'oc-seq'. These Via header parameters are used to implement an
overload control feedback loop between neighboring SIP servers.</t>
<t>The 'oc', 'oc_validity', 'oc-port' and 'oc-seq' parameters are
only defined in the topmost Via header of a response. They MUST NOT
be used in the Via headers of requests and MUST NOT be used in
other Via headers of a response. The 'oc', 'oc_validity', 'oc-port'
and 'oc-seq' parameters MUST be ignored if received outside of
the topmost Via header of a response. The 'oc_accept' parameter
MAY appear in all Via headers.</t>
<t>The 'oc' Via header parameter contains a number between 0 and
100. It describes the percentage by which the traffic to the SIP
server from which the response has been received should be
reduced. The default value for this parameter is 0.</t>
<!--
<t><list>
<t>OPEN ISSUE: the syntax of the 'oc' Via header parameter
depends on the overload control method (i.e., loss-based,
rate-based or window-based) in use. The following syntax
definition defines a rate-based 'oc' header. This syntax needs
to be adjusted if rate-based or window-based overload control is
used.</t>
</list></t>
-->
<t>The 'oc_validity' Via header parameter contains the time during
which the corresponding 'oc' Via header parameter is valid. The
'oc_validity' parameter can only be present in a Via header in
conjunction with an 'oc' parameter.</t>
<t>The 'oc_accept' Via header parameter indicates that the SIP
server, which has created this Via header, supports overload
control.</t>
<t>The 'oc-port' Via header parameter does not contain a value.
It is used as placeholder to impart to the upstream entity the
specific port number on which overload control is desired (i.e.,
perform overload control only on requests destined for a specific
port.)</t>
<t>The 'oc-seq' Via header parameter contains a sequence number.
Those implementations that are capable of providing finer-grained
overload control information may do so, however, each response
that contains the updated overload control information MUST have
an increasing value in this parameter. This is to allow the
upstream server to properly order out-of-order responses that
contain overload control information.</t>
<t>This specification extends the existing definition of the Via
header field parameters of <xref target="RFC3261"/> as follows:</t>
<figure>
<artwork><![CDATA[
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ oc / oc-validity
/ oc-accept / oc-port
/ oc-seq / via-extension
]]></artwork>
</figure>
<t><list>
<t>oc = "oc" [EQUAL 0-100]</t>
</list></t>
<t><list>
<t>oc-validity = "oc_validity" [EQUAL delta-ms]</t>
</list></t>
<t><list>
<t>oc-accept = "oc_accept"</t>
</list></t>
<t><list>
<t>oc-port = "oc_port"</t>
</list></t>
<t><list>
<t>oc-seq = (1*DIGIT) /
(1*DIGIT "." 1*DIGIT) </t>
</list></t>
<t>Example:</t>
<figure>
<artwork><![CDATA[
Via: SIP/2.0/TCP ss1.atlanta.example.com:5060
;branch=z9hG4bK2d4790.1
;received=192.0.2.111
;oc=20;oc_validity=500;oc-seq=87165
]]></artwork>
</figure>
</section>
<section title="Design Considerations">
<t>This section discusses specific design considerations for the
mechanism described in this document. General design
considerations for SIP overload control can be found in
<xref target="I-D.ietf-soc-overload-design" />.</t>
<section title="SIP Mechanism">
<t>A SIP mechanism is needed to convey overload feedback from
the receiving to the sending SIP entity. A number of different
alternatives exist to implement such a mechanism.</t>
<section title="SIP Response Header">
<t>Overload control information can be transmitted using a new
Via header field parameter for overload control. A SIP server
can add this header parameter to the responses it is sending
upstream to provide overload control feedback to its upstream
neighbors. This approach has the following
characteristics:</t>
<t><list style='symbols'>
<t>A Via header parameter is light-weight and creates very
little overhead. It does not require the transmission of
additional messages for overload control and does not
increase traffic or processing burdens in an overload
situation. </t>
<t>Overload control status can frequently be reported to
upstream neighbors since it is a part of a SIP
response. This enables the use of this mechanism in
scenarios where the overload status needs to be adjusted
frequently. It also enables the use of overload control
mechanisms that use regular feedback such as window-based
overload control.</t>
<t>With a Via header parameter, overload control status is
inherent in SIP signaling and is automatically conveyed to
all relevant upstream neighbors, i.e., neighbors that are
currently contributing traffic. There is no need for a SIP
server to specifically track and manage the set of current
upstream or downstream neighbors with which it should
exchange overload feedback.</t>
<t>Overload status is not conveyed to inactive senders. This
avoids the transmission of overload feedback to inactive
senders, which do not contribute traffic. If an inactive
sender starts to transmit while the receiver is in overload
it will receive overload feedback in the first response and
can adjust the amount of traffic forwarded accordingly. </t>
<t>A SIP server can limit the distribution of overload
control information by only inserting it into responses to
known upstream neighbors. A SIP server can use transport
level authentication (e.g., via TLS) with its upstream
neighbors.</t>
</list></t>
</section>
<section title="SIP Event Package">
<t>Overload control information can also be conveyed from a
receiver to a sender using a new event package. Such an event
package enables a sending entity to subscribe to the overload
status of its downstream neighbors and receive notifications
of overload control status changes in NOTIFY requests. This
approach has the following characteristics:</t>
<t><list style='symbols'>
<t>Overload control information is conveyed decoupled from
SIP signaling. It enables an overload control manager, which
is a separate entity, to monitor the load on other servers
and provide overload control feedback to all SIP servers
that have set up subscriptions with the controller.</t>
<t>With an event package, a receiver can send updates to
senders that are currently inactive. Inactive senders will
receive a notification about the overload and can refrain
from sending traffic to this neighbor until the overload
condition is resolved. The receiver can also notify all
potential senders once they are permitted to send traffic
again. However, these notifications do generate additional
traffic, which adds to the overall load.</t>
<t>A SIP entity needs to set up and maintain overload
control subscriptions with all upstream and downstream
neighbors. A new subscription needs to be set up
before/while a request is transmitted to a new downstream
neighbor. Servers can be configured to subscribe at boot
time. However, this would require additional protection to
avoid the avalanche restart problem for overload
control. Subscriptions need to be terminated when they are
not needed any more, which can be done, for example, using a
timeout mechanism.</t>
<t>A receiver needs to send NOTIFY messages to all
subscribed upstream neighbors in a timely manner when the
control algorithm requires a change in the control variable
(e.g., when a SIP server is in an overload condition). This
includes active as well as inactive neighbors. These NOTIFYs
add to the amount of traffic that needs to be processed. To
ensure that these requests will not be dropped due to
overload, a priority mechanism needs to be implemented in
all servers these request will pass through.</t>
<t>As overload feedback is sent to all senders in separate
messages, this mechanism is not suitable when frequent
overload control feedback is needed.</t>
<t>A SIP server can limit the set of senders that can
receive overload control information by authenticating
subscriptions to this event package.</t>
<t>This approach requires each proxy to implement user agent
functionality (UAS and UAC) to manage the subscriptions.</t>
</list></t>
</section>
</section>
<section title="Backwards Compatibility">
<t>An new overload control mechanism needs to be backwards
compatible so that it can be gradually introduced into a network
and functions properly if only a fraction of the servers support
it.</t>
<t>Hop-by-hop overload control (see
<xref target="I-D.ietf-soc-overload-design" />) has the
advantage that 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 servers support overload control
and does not depend on the support from any other server or user
agent. The more SIP servers in a network support hop-by-hop
overload control, the better protected the network is against
occurrences of overload.</t>
<t>A SIP server may have multiple upstream neighbors from which
only some may support overload control. If a server would simply
use this overload control mechanism, only those that support it
would reduce traffic. Others would keep sending at the full rate
and benefit from the throttling by the servers that support
overload control. In other words, upstream neighbors that do not
support overload control would be better off than those that
do.</t>
<t>A SIP server should therefore use 5xx responses towards
upstream neighbors that do not support overload control. The
server should reject the same amount of requests with 5xx
responses that would be otherwise be rejected/redirected by the
upstream neighbor if it would support overload control. If the
load condition on the server does not permit the creation of 5xx
responses, the server should drop all requests from servers that
do not support overload control.</t>
</section>
</section>
<section anchor="sec:security" title="Security Considerations">
<t>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 that the SIP entity is overloaded. When such a forged
overload indication is received by an upstream SIP entity, it will
stop sending traffic to the victim. Thus, the victim is
subject to a denial-of-service attack.</t>
<t>An attacker can create forged overload feedback by inserting
itself into the communication between the victim and its
upstream neighbors. The attacker would need to add overload
feedback indicating a high load to the responses passed from the
victim to its upstream neighbor. Proxies can prevent this attack by
communicating via TLS. Since overload feedback has no meaning
beyond the next hop, there is no need to secure the communication
over multiple hops.</t>
<t>Another way to conduct an attack is to send a message
containing a high overload feedback value through a proxy that does not
support this extension. If this feedback is added to the second Via
headers (or all Via headers), it will reach the next upstream
proxy. If the attacker can make the recipient believe that the
overload status was created by its direct downstream neighbor (and
not by the attacker further downstream) the recipient stops
sending traffic to the victim. A precondition for this attack is
that the victim proxy does not support this extension since it
would not pass through overload control feedback otherwise.</t>
<t>A malicious SIP entity could gain an advantage by pretending to
support this specification but never reducing the amount of
traffic it forwards to the downstream neighbor. If its downstream
neighbor receives traffic from multiple sources which correctly
implement overload control, the malicious SIP entity would benefit
since all other sources to its downstream neighbor would reduce
load. </t>
<t><list>
<t>The solution to this problem depends on the
overload control method. For rate-based and window-based
overload control, it is very easy for a downstream entity to
monitor if the upstream neighbor throttles traffic forwarded as
directed. For percentage throttling this is not always obvious
since the load forwarded depends on the load received by the
upstream neighbor.</t>
</list></t>
</section>
<section anchor="sec:iana" title="IANA Considerations">
<t>[TBD.]</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3261;
&rfc3263;
&rfc4412;
</references>
<references title='Informative References'>
&rfc5390;
&i-d.ietf-soc-overload-design;
</references>
<section title="Acknowledgements">
<t>Many thanks to Rich Terpstra, Daryl Malas, Jonathan Rosenberg,
Charles Shen, Padma Valluri, Janet Gunn, Shaun Bharrat, and Paul
Kyzivat for their contributions to this specification.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:12:12 |