Internet DRAFT - draft-hilt-sipping-hopbyhop-overload
draft-hilt-sipping-hopbyhop-overload
SIPPING Working Group V. Hilt
Internet-Draft I. Widjaja
Expires: December 20, 2006 Bell Labs/Lucent Technologies
June 18, 2006
Hop-by-Hop Overload Control for the Session Initiation Protocol (SIP)
draft-hilt-sipping-hopbyhop-overload-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This specification defines a mechanism for reporting the load status
of a Session Initiation Protocol (SIP) entity to its upstream
neighbor.
Hilt & Widjaja Expires December 20, 2006 [Page 1]
Internet-Draft Hop-by-Hop Overload Control June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Reporting Load Status Information . . . . . . . . . . . . . . 5
4. Processing Load Status Information . . . . . . . . . . . . . . 6
5. Computing the Load Status Value . . . . . . . . . . . . . . . 7
6. Using the Load Status Value . . . . . . . . . . . . . . . . . 7
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Hilt & Widjaja Expires December 20, 2006 [Page 2]
Internet-Draft Hop-by-Hop Overload Control June 2006
1. Introduction
Overload of a SIP [2] server can be a significant problem for a SIP
network. The draft [3] provides a detailed discussion of the SIP
overload problem and analyzes why existing mechanisms such as the 503
response are not sufficient to resolve overload conditions. These
techniques are likely to introduce an oscillatory behavior and cannot
avoid a congestion collapse, i.e. a condition in which the message
throughput of a network degrades to a point far below its original
capacity in an overload situation. We have confirmed this behavior
in a series of simulations we have conducted.
In this draft we propose a new mechanism that enables a SIP entity to
advertise its current load status to its direct upstream neighbor.
The mechanism is based on the idea of allowing SIP entities to insert
load status reports in SIP responses and making sure this information
is used by the direct upstream neighbors. The load status of a SIP
entity is effectively only forwarded one hop to the next upstream
entity, implementing a hop-by-hop overload control scheme. The load
status reports contain values that range from 0 to 100 (a higher
value indicates a higher load) and reflect the current load measure
of the SIP entity.
The motivation for hop-by-hop overload control is that the upstream
neighbor of a SIP entity can easily and effectively control the load
a SIP entity receives. By reporting its current load status to the
direct upstream neighbors (i.e. the SIP entities it currently
receives requests from) a SIP entity enables its neighbors to take
action if overload occurs. They can, for example, divert traffic to
an alternative proxy that is operating at a lower load level or
reject excess messages.
There is no need for the upstream neighbors of a SIP entity to
forward the load status they receive further upstream, since they can
act on this information and resolve the overload condition if needed
(e.g. by re-routing or rejecting traffic). If the upstream neighbor
becomes congested itself, it reports its own high level of load to
its own upstream neighbors, which then again can take action to
resolve the situation. Thus, overload of a SIP entity is resolved by
its direct neighbors without the need to involve entities that are
located multiple SIP hops away.
Since load status reports continuously advertise the current level of
load (ranging from 0 to 100) to upstream neighbors, this mechanism
does not have the on-off semantics that can lead to traffic
oscillation. In fact, SIP proxies can use the load status
information to balance load between alternative proxies. Thus, this
mechanism can help to evenly load downstream proxies, making best use
Hilt & Widjaja Expires December 20, 2006 [Page 3]
Internet-Draft Hop-by-Hop Overload Control June 2006
of available resources. However, this mechanism it is not intended
to replace specialized load balancing mechanisms. If downstream
proxies are getting close to becoming saturated, a proxy can
gradually lower the amount of traffic it is forwarding to them, e.g.,
by re-directing or rejecting messages on behalf of the saturated
proxy. If the proxy itself runs out of processing resources and
becomes overloaded, it will report the high load upstream, causing
the upstream proxy to lower the load.
Hop-by-hop overload control can effectively reduce the impact of
overload on a SIP network and, in particular, avoids the signaling
congestion collapse. This is achieved by enabling proxies to
gradually lower the amount of traffic forwarded to a proxy that
reaches a high level of load and by enabling a proxy that is reaching
overload to offload the task of redirecting and rejecting messages to
the upstream neighbors.
Hop-by-hop overload control can be gradually introduced into a
network and does not require that all entities support it. It can be
used effectively between two proxies if both proxies support this
extension and does not depend on the support from any other proxy or
the user agent in the network. The more proxies in a network support
this extension, the more effective it is since it includes more
proxies in the reporting and offloading process.
The approach of hop-by-hop overload control is simple and scales well
to networks with many SIP proxies. It does not require a proxy to
aggregate a large number of load values or to keep track of the load
status of proxies it is not communicating with. A proxy only needs
to observe the load status of the downstream neighbors it is
currently forwarding traffic to.
An advantage of using a SIP response to report overload status
information as opposed to a SIP method is that it causes very little
overhead, which is important for an overload control mechanism.
Having a proxy report overload status to all potential upstream
neighbors by sending separate overload report requests is much more
expensive and may not be feasible if a proxy is in an overload
condition.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
Hilt & Widjaja Expires December 20, 2006 [Page 4]
Internet-Draft Hop-by-Hop Overload Control June 2006
3. Reporting Load Status Information
A proxy compliant to this specification SHOULD frequently report its
current load status to upstream neighbors by inserting this
information into the responses it is processing. It may choose to
insert the load status into every or every x-th suitable response,
depending on the number of messages it processes and the variability
of the load measure.
Sending load status reports to the next hop upstream neighbor can be
implemented in different ways. The this section discusses two
alternatives, one based on a new response header and one based on a
Via header parameter.
(a) In the first approach, a proxy uses a new Load-Status header
field to report overload status. In this approach, it is RECOMMENDED
that proxies only insert Load-Status headers into 100 (Trying)
responses. The reason is that 100 (Trying) responses are not
forwarded by a stateful proxy, even if it does not support this
extension. Thus, the upstream propagation of load status information
is limited by the next stateful proxy even if the upstream proxies do
not support this extension.
There are scenarios in which a proxy only rarely generates 100
(Trying) responses. For example, a proxy serving a presence server
will typically not generate 100 (Trying) responses. In these
scenarios, a proxy MAY insert a Load-Status header into non-100
(Trying) responses (e.g. in 200 OK responses). Since non-100
(Trying) responses are forwarded by upstream proxies, a Load-Status
header may be propagated beyond the next hop if the next hop does not
support this specification.
A proxy MUST insert the address of its upstream neighbor into the
"next-hop" parameter of the Load-Status header. The content of the
"next-hop" parameter is typically the address found in the topmost
Via header of the response. This enables the proxy that processes
the Load-Status header to determine if the header was generated by
its direct neighbor or by a proxy further downstream and simply
passed along.
(b) An alternative approach is to insert load status information in a
new "load-status" parameter of the Via header. In this approach, a
proxy adds a "load-status" parameter to the topmost Via header in a
response (of course, after removing its own Via header).
An advantage of using a Via header parameter is that the topmost Via
header is removed by every proxy when processing a response. Thus,
the load status information will be removed from the response after
Hilt & Widjaja Expires December 20, 2006 [Page 5]
Internet-Draft Hop-by-Hop Overload Control June 2006
one hop no matter if the proxy supports this extension or not. The
load status information is therefore never forwarded beyond the next
upstream hop. Proxies that do not understand the "load-status"
parameter will silently ignore it (as they would ignore any other
unknown header parameter). The Via header parameter can be used on
all responses. A drawback of using a new Via header parameter is
that it may overload the Via mechanism.
OPEN ISSUE: both mechanisms seem to be able to provide hop-by-hop
semantics. Need some discussion about the two approaches.
A proxy SHOULD return responses containing load status information
over TLS.
A SIP entity that has reached a load of 100 (i.e. overload) MAY
return a 503 response in addition to reporting overload using this
extension. If the proxy has reached a load of 100, it is very likely
that the upstream proxy has ignored the increasing load status
reports and thus does not support this extension. By sending a 503
response, an upstream proxy is enabled to use the traditional SIP
overload control mechanisms.
4. Processing Load Status Information
A proxy compliant to this specification MUST remove all load status
values from the SIP messages it receives after processing this
information and before forwarding the message. A proxy MUST ignore
load status values that were not generated by its direct neighbor.
(a) In the first approach, load status information is contained in
the Load-Status header of a response. A proxy MUST remove Load-
Status headers from the responses it receives. Since 100 (Trying)
responses are not forwarded by stateful proxies, there is no need for
these proxies to explicitly remove the Load-Status header from 100
(Trying) responses.
A proxy that has received a 100 (Trying) response with a Load-Status
header from a stateful proxy can skip the following test. In all
other cases, a proxy MUST verify that the Load-Status header was
created by its direct downstream neighbor. To do so, the proxy
compares the address in the "next-hop" parameter with its own
addresses. If they don't match, the header MUST be ignored.
(b) In the second approach, load status is reported in a parameter in
the topmost Via header. Since this Via header is removed by a proxy,
there is no need to explicitly remove the parameter.
Hilt & Widjaja Expires December 20, 2006 [Page 6]
Internet-Draft Hop-by-Hop Overload Control June 2006
OPEN ISSUE: some discussion of the two approaches is needed.
5. Computing the Load Status Value
The load status value indicates to which degree the resources a SIP
entity needs to process incoming messages are utilized. Load status
values range from 0 to 100. 0 indicates that resources are used the
least, 100 indicates that the resources are fully utilized.
The algorithm used to determine the load status of a SIP entity
depends on the type of resources needed by this entity to process SIP
messages. Different SIP entities may have different resource
requirements and constrains and therefore may use different
algorithms to compute the load status value.
A common mechanism is to use the processor utilization to derive the
load status. However, other metrics such as memory usage or queue
length may also be used.
6. Using the Load Status Value
The actions taken by a proxy in response to a given level of load
reported are specific to an implementation and network configuration
and not subject to standardization. This includes the mechanisms
used to reduce traffic (e.g. routing the traffic along an alternate
path or rejecting messages).
The following thresholds provide some guidance for using the load
status value. Other behaviors may be implemented as well. A load
status value of 70 indicates that the proxy is under heavy load. The
upstream neighbor of this proxy may start to reduce traffic forwarded
to this proxy at that point. A load status value of 95 indicates
that the proxy is overloaded. The upstream neighbor should stop
forwarding traffic to the overloaded proxy. However, it may still
occasionally forward a request in order to get an updated load status
report in a response. At a load status of 100, no requests should be
forwarded to the overloaded proxy as long as this value is valid.
A reasonable approach for processing the load status value may be the
following: a proxy stores the load status value received from a
downstream neighbor for a short period of time or as indicated in the
valid parameter. Before forwarding a message to a downstream
neighbor, the proxy checks if it has a valid load status for this
neighbor. If the load status value of this proxy exceeds 70 the
proxy starts to divert a fraction of the traffic for this proxy
elsewhere. The fraction of traffic that is diverted away from the
Hilt & Widjaja Expires December 20, 2006 [Page 7]
Internet-Draft Hop-by-Hop Overload Control June 2006
proxy under load is increased as the load status value increases
until the load status reaches 95. At this point, the proxy stops
forwarding traffic to this downstream neighbor, except for occasional
requests to get an updated load status report.
7. Syntax
This section defines the syntax of a new Load-Status header. An
alternative approach is to use a Via header field parameter. The
syntax of this parameter can be defined analogously.
The Load-Status header field is used to advertise the current load
status information of a SIP entity to its upstream neighbor.
The value of the load status is an integer between 0 and 100 with the
value of 0 indicating that the proxy is least overloaded and the
value of 100 indicating that the proxy is most overloaded.
The "valid" parameter is optional and contains an indication of how
long the reporting proxy is likely to remain in the given load
status. This parameter is particularly important if a proxy reports
overload and wants to indicate when an upstream proxy may want try
sending another request.
The "next-hop" parameter contains the URI of the next hop SIP entity,
i.e. the SIP entity the response is forwarded to. This is the entity
that processes the load status information.
The syntax of the Load-Status header field is:
Load-Status = "Load-Status" HCOLON loadStatus
loadStatus = 0-100 [ SEMI validMS ] SEMI originatorURI
validMS = "valid" EQUAL delta-ms
originatorURI = "next-hop" EQUAL absoluteURI
delta-ms = 1*DIGIT
The BNF for absoluteURI is defined in [2].
Table 1 is an extension of Tables 2 and 3 in [2].
Header field where proxy ACK BYE CAN INV OPT REG
________________________________________________________
Load-Status r ar - o o o o o
Table 1: Load-Status Header Fields
Example:
Hilt & Widjaja Expires December 20, 2006 [Page 8]
Internet-Draft Hop-by-Hop Overload Control June 2006
Load-Status: 20;valid=500;next-hop=proxy.example.com
8. Security Considerations
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.
An attacker can create forged load status reports by inserting itself
into the communication between the victim and its upstream neighbors.
The attacker would need to add status reports 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 load
status reports have no meaning beyond the next hop, there is no need
to secure the communication over multiple hops.
Another way to conduct an attack is to send a message containing a
high load status value through a proxy that does not support this
extension. Since this proxy does not remove the load status
information, it will reach the next upstream proxy. If the attacker
can make the recipient believe that the load 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 load status
information otherwise. The attack also does not work if there is a
stateful proxy between the attacker and the victim and only 100
(Trying) responses are used to convey the Load-Status header.
OPEN ISSUE: They way this attack is prevented depends on whether a
header or a Via parameter is used to report load status.
9. IANA Considerations
[TBD.]
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Hilt & Widjaja Expires December 20, 2006 [Page 9]
Internet-Draft Hop-by-Hop Overload Control June 2006
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
10.2. Informative References
[3] Rosenberg, J., "Requirements for Management of Overload in the
Session Initiation Protocol",
draft-rosenberg-sipping-overload-reqs-00 (work in progress),
February 2006.
Hilt & Widjaja Expires December 20, 2006 [Page 10]
Internet-Draft Hop-by-Hop Overload Control June 2006
Authors' Addresses
Volker Hilt
Bell Labs/Lucent Technologies
101 Crawfords Corner Rd
Holmdel, NJ 07733
USA
Email: volkerh@bell-labs.com
Indra Widjaja
Bell Labs/Lucent Technologies
600-700 Mountain Avenue
Murray Hill, NJ 07974
USA
Email: iwidjaja@lucent.com
Hilt & Widjaja Expires December 20, 2006 [Page 11]
Internet-Draft Hop-by-Hop Overload Control June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hilt & Widjaja Expires December 20, 2006 [Page 12]
