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]