idnits 2.17.1 draft-hilt-sipping-hopbyhop-overload-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 339 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 18, 2006) is 6519 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-rosenberg-sipping-overload-reqs-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft I. Widjaja 4 Expires: December 20, 2006 Bell Labs/Lucent Technologies 5 June 18, 2006 7 Hop-by-Hop Overload Control for the Session Initiation Protocol (SIP) 8 draft-hilt-sipping-hopbyhop-overload-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 20, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This specification defines a mechanism for reporting the load status 42 of a Session Initiation Protocol (SIP) entity to its upstream 43 neighbor. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Reporting Load Status Information . . . . . . . . . . . . . . 5 50 4. Processing Load Status Information . . . . . . . . . . . . . . 6 51 5. Computing the Load Status Value . . . . . . . . . . . . . . . 7 52 6. Using the Load Status Value . . . . . . . . . . . . . . . . . 7 53 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 55 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 58 10.2. Informative References . . . . . . . . . . . . . . . . . 10 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 60 Intellectual Property and Copyright Statements . . . . . . . . . . 12 62 1. Introduction 64 Overload of a SIP [2] server can be a significant problem for a SIP 65 network. The draft [3] provides a detailed discussion of the SIP 66 overload problem and analyzes why existing mechanisms such as the 503 67 response are not sufficient to resolve overload conditions. These 68 techniques are likely to introduce an oscillatory behavior and cannot 69 avoid a congestion collapse, i.e. a condition in which the message 70 throughput of a network degrades to a point far below its original 71 capacity in an overload situation. We have confirmed this behavior 72 in a series of simulations we have conducted. 74 In this draft we propose a new mechanism that enables a SIP entity to 75 advertise its current load status to its direct upstream neighbor. 76 The mechanism is based on the idea of allowing SIP entities to insert 77 load status reports in SIP responses and making sure this information 78 is used by the direct upstream neighbors. The load status of a SIP 79 entity is effectively only forwarded one hop to the next upstream 80 entity, implementing a hop-by-hop overload control scheme. The load 81 status reports contain values that range from 0 to 100 (a higher 82 value indicates a higher load) and reflect the current load measure 83 of the SIP entity. 85 The motivation for hop-by-hop overload control is that the upstream 86 neighbor of a SIP entity can easily and effectively control the load 87 a SIP entity receives. By reporting its current load status to the 88 direct upstream neighbors (i.e. the SIP entities it currently 89 receives requests from) a SIP entity enables its neighbors to take 90 action if overload occurs. They can, for example, divert traffic to 91 an alternative proxy that is operating at a lower load level or 92 reject excess messages. 94 There is no need for the upstream neighbors of a SIP entity to 95 forward the load status they receive further upstream, since they can 96 act on this information and resolve the overload condition if needed 97 (e.g. by re-routing or rejecting traffic). If the upstream neighbor 98 becomes congested itself, it reports its own high level of load to 99 its own upstream neighbors, which then again can take action to 100 resolve the situation. Thus, overload of a SIP entity is resolved by 101 its direct neighbors without the need to involve entities that are 102 located multiple SIP hops away. 104 Since load status reports continuously advertise the current level of 105 load (ranging from 0 to 100) to upstream neighbors, this mechanism 106 does not have the on-off semantics that can lead to traffic 107 oscillation. In fact, SIP proxies can use the load status 108 information to balance load between alternative proxies. Thus, this 109 mechanism can help to evenly load downstream proxies, making best use 110 of available resources. However, this mechanism it is not intended 111 to replace specialized load balancing mechanisms. If downstream 112 proxies are getting close to becoming saturated, a proxy can 113 gradually lower the amount of traffic it is forwarding to them, e.g., 114 by re-directing or rejecting messages on behalf of the saturated 115 proxy. If the proxy itself runs out of processing resources and 116 becomes overloaded, it will report the high load upstream, causing 117 the upstream proxy to lower the load. 119 Hop-by-hop overload control can effectively reduce the impact of 120 overload on a SIP network and, in particular, avoids the signaling 121 congestion collapse. This is achieved by enabling proxies to 122 gradually lower the amount of traffic forwarded to a proxy that 123 reaches a high level of load and by enabling a proxy that is reaching 124 overload to offload the task of redirecting and rejecting messages to 125 the upstream neighbors. 127 Hop-by-hop overload control can be gradually introduced into a 128 network and does not require that all entities support it. It can be 129 used effectively between two proxies if both proxies support this 130 extension and does not depend on the support from any other proxy or 131 the user agent in the network. The more proxies in a network support 132 this extension, the more effective it is since it includes more 133 proxies in the reporting and offloading process. 135 The approach of hop-by-hop overload control is simple and scales well 136 to networks with many SIP proxies. It does not require a proxy to 137 aggregate a large number of load values or to keep track of the load 138 status of proxies it is not communicating with. A proxy only needs 139 to observe the load status of the downstream neighbors it is 140 currently forwarding traffic to. 142 An advantage of using a SIP response to report overload status 143 information as opposed to a SIP method is that it causes very little 144 overhead, which is important for an overload control mechanism. 145 Having a proxy report overload status to all potential upstream 146 neighbors by sending separate overload report requests is much more 147 expensive and may not be feasible if a proxy is in an overload 148 condition. 150 2. Terminology 152 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 153 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 154 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 155 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 156 compliant implementations. 158 3. Reporting Load Status Information 160 A proxy compliant to this specification SHOULD frequently report its 161 current load status to upstream neighbors by inserting this 162 information into the responses it is processing. It may choose to 163 insert the load status into every or every x-th suitable response, 164 depending on the number of messages it processes and the variability 165 of the load measure. 167 Sending load status reports to the next hop upstream neighbor can be 168 implemented in different ways. The this section discusses two 169 alternatives, one based on a new response header and one based on a 170 Via header parameter. 172 (a) In the first approach, a proxy uses a new Load-Status header 173 field to report overload status. In this approach, it is RECOMMENDED 174 that proxies only insert Load-Status headers into 100 (Trying) 175 responses. The reason is that 100 (Trying) responses are not 176 forwarded by a stateful proxy, even if it does not support this 177 extension. Thus, the upstream propagation of load status information 178 is limited by the next stateful proxy even if the upstream proxies do 179 not support this extension. 181 There are scenarios in which a proxy only rarely generates 100 182 (Trying) responses. For example, a proxy serving a presence server 183 will typically not generate 100 (Trying) responses. In these 184 scenarios, a proxy MAY insert a Load-Status header into non-100 185 (Trying) responses (e.g. in 200 OK responses). Since non-100 186 (Trying) responses are forwarded by upstream proxies, a Load-Status 187 header may be propagated beyond the next hop if the next hop does not 188 support this specification. 190 A proxy MUST insert the address of its upstream neighbor into the 191 "next-hop" parameter of the Load-Status header. The content of the 192 "next-hop" parameter is typically the address found in the topmost 193 Via header of the response. This enables the proxy that processes 194 the Load-Status header to determine if the header was generated by 195 its direct neighbor or by a proxy further downstream and simply 196 passed along. 198 (b) An alternative approach is to insert load status information in a 199 new "load-status" parameter of the Via header. In this approach, a 200 proxy adds a "load-status" parameter to the topmost Via header in a 201 response (of course, after removing its own Via header). 203 An advantage of using a Via header parameter is that the topmost Via 204 header is removed by every proxy when processing a response. Thus, 205 the load status information will be removed from the response after 206 one hop no matter if the proxy supports this extension or not. The 207 load status information is therefore never forwarded beyond the next 208 upstream hop. Proxies that do not understand the "load-status" 209 parameter will silently ignore it (as they would ignore any other 210 unknown header parameter). The Via header parameter can be used on 211 all responses. A drawback of using a new Via header parameter is 212 that it may overload the Via mechanism. 214 OPEN ISSUE: both mechanisms seem to be able to provide hop-by-hop 215 semantics. Need some discussion about the two approaches. 217 A proxy SHOULD return responses containing load status information 218 over TLS. 220 A SIP entity that has reached a load of 100 (i.e. overload) MAY 221 return a 503 response in addition to reporting overload using this 222 extension. If the proxy has reached a load of 100, it is very likely 223 that the upstream proxy has ignored the increasing load status 224 reports and thus does not support this extension. By sending a 503 225 response, an upstream proxy is enabled to use the traditional SIP 226 overload control mechanisms. 228 4. Processing Load Status Information 230 A proxy compliant to this specification MUST remove all load status 231 values from the SIP messages it receives after processing this 232 information and before forwarding the message. A proxy MUST ignore 233 load status values that were not generated by its direct neighbor. 235 (a) In the first approach, load status information is contained in 236 the Load-Status header of a response. A proxy MUST remove Load- 237 Status headers from the responses it receives. Since 100 (Trying) 238 responses are not forwarded by stateful proxies, there is no need for 239 these proxies to explicitly remove the Load-Status header from 100 240 (Trying) responses. 242 A proxy that has received a 100 (Trying) response with a Load-Status 243 header from a stateful proxy can skip the following test. In all 244 other cases, a proxy MUST verify that the Load-Status header was 245 created by its direct downstream neighbor. To do so, the proxy 246 compares the address in the "next-hop" parameter with its own 247 addresses. If they don't match, the header MUST be ignored. 249 (b) In the second approach, load status is reported in a parameter in 250 the topmost Via header. Since this Via header is removed by a proxy, 251 there is no need to explicitly remove the parameter. 253 OPEN ISSUE: some discussion of the two approaches is needed. 255 5. Computing the Load Status Value 257 The load status value indicates to which degree the resources a SIP 258 entity needs to process incoming messages are utilized. Load status 259 values range from 0 to 100. 0 indicates that resources are used the 260 least, 100 indicates that the resources are fully utilized. 262 The algorithm used to determine the load status of a SIP entity 263 depends on the type of resources needed by this entity to process SIP 264 messages. Different SIP entities may have different resource 265 requirements and constrains and therefore may use different 266 algorithms to compute the load status value. 268 A common mechanism is to use the processor utilization to derive the 269 load status. However, other metrics such as memory usage or queue 270 length may also be used. 272 6. Using the Load Status Value 274 The actions taken by a proxy in response to a given level of load 275 reported are specific to an implementation and network configuration 276 and not subject to standardization. This includes the mechanisms 277 used to reduce traffic (e.g. routing the traffic along an alternate 278 path or rejecting messages). 280 The following thresholds provide some guidance for using the load 281 status value. Other behaviors may be implemented as well. A load 282 status value of 70 indicates that the proxy is under heavy load. The 283 upstream neighbor of this proxy may start to reduce traffic forwarded 284 to this proxy at that point. A load status value of 95 indicates 285 that the proxy is overloaded. The upstream neighbor should stop 286 forwarding traffic to the overloaded proxy. However, it may still 287 occasionally forward a request in order to get an updated load status 288 report in a response. At a load status of 100, no requests should be 289 forwarded to the overloaded proxy as long as this value is valid. 291 A reasonable approach for processing the load status value may be the 292 following: a proxy stores the load status value received from a 293 downstream neighbor for a short period of time or as indicated in the 294 valid parameter. Before forwarding a message to a downstream 295 neighbor, the proxy checks if it has a valid load status for this 296 neighbor. If the load status value of this proxy exceeds 70 the 297 proxy starts to divert a fraction of the traffic for this proxy 298 elsewhere. The fraction of traffic that is diverted away from the 299 proxy under load is increased as the load status value increases 300 until the load status reaches 95. At this point, the proxy stops 301 forwarding traffic to this downstream neighbor, except for occasional 302 requests to get an updated load status report. 304 7. Syntax 306 This section defines the syntax of a new Load-Status header. An 307 alternative approach is to use a Via header field parameter. The 308 syntax of this parameter can be defined analogously. 310 The Load-Status header field is used to advertise the current load 311 status information of a SIP entity to its upstream neighbor. 313 The value of the load status is an integer between 0 and 100 with the 314 value of 0 indicating that the proxy is least overloaded and the 315 value of 100 indicating that the proxy is most overloaded. 317 The "valid" parameter is optional and contains an indication of how 318 long the reporting proxy is likely to remain in the given load 319 status. This parameter is particularly important if a proxy reports 320 overload and wants to indicate when an upstream proxy may want try 321 sending another request. 323 The "next-hop" parameter contains the URI of the next hop SIP entity, 324 i.e. the SIP entity the response is forwarded to. This is the entity 325 that processes the load status information. 327 The syntax of the Load-Status header field is: 329 Load-Status = "Load-Status" HCOLON loadStatus 330 loadStatus = 0-100 [ SEMI validMS ] SEMI originatorURI 331 validMS = "valid" EQUAL delta-ms 332 originatorURI = "next-hop" EQUAL absoluteURI 333 delta-ms = 1*DIGIT 335 The BNF for absoluteURI is defined in [2]. 337 Table 1 is an extension of Tables 2 and 3 in [2]. 339 Header field where proxy ACK BYE CAN INV OPT REG 340 ________________________________________________________ 341 Load-Status r ar - o o o o o 342 Table 1: Load-Status Header Fields 344 Example: 346 Load-Status: 20;valid=500;next-hop=proxy.example.com 348 8. Security Considerations 350 Overload control mechanisms can be used by an attacker to conduct a 351 denial-of-service attack on a SIP entity if the attacker can pretend 352 that the SIP entity is overloaded. When such a forged overload 353 indication is received by an upstream SIP entity, it will stop 354 sending traffic to the victim. Thus, the victim is subject to a 355 denial-of-service attack. 357 An attacker can create forged load status reports by inserting itself 358 into the communication between the victim and its upstream neighbors. 359 The attacker would need to add status reports indicating a high load 360 to the responses passed from the victim to its upstream neighbor. 361 Proxies can prevent this attack by communicating via TLS. Since load 362 status reports have no meaning beyond the next hop, there is no need 363 to secure the communication over multiple hops. 365 Another way to conduct an attack is to send a message containing a 366 high load status value through a proxy that does not support this 367 extension. Since this proxy does not remove the load status 368 information, it will reach the next upstream proxy. If the attacker 369 can make the recipient believe that the load status was created by 370 its direct downstream neighbor (and not by the attacker further 371 downstream) the recipient stops sending traffic to the victim. A 372 precondition for this attack is that the victim proxy does not 373 support this extension since it would not pass through load status 374 information otherwise. The attack also does not work if there is a 375 stateful proxy between the attacker and the victim and only 100 376 (Trying) responses are used to convey the Load-Status header. 378 OPEN ISSUE: They way this attack is prevented depends on whether a 379 header or a Via parameter is used to report load status. 381 9. IANA Considerations 383 [TBD.] 385 10. References 387 10.1. Normative References 389 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 390 Levels", BCP 14, RFC 2119, March 1997. 392 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 393 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 394 Session Initiation Protocol", RFC 3261, June 2002. 396 10.2. Informative References 398 [3] Rosenberg, J., "Requirements for Management of Overload in the 399 Session Initiation Protocol", 400 draft-rosenberg-sipping-overload-reqs-00 (work in progress), 401 February 2006. 403 Authors' Addresses 405 Volker Hilt 406 Bell Labs/Lucent Technologies 407 101 Crawfords Corner Rd 408 Holmdel, NJ 07733 409 USA 411 Email: volkerh@bell-labs.com 413 Indra Widjaja 414 Bell Labs/Lucent Technologies 415 600-700 Mountain Avenue 416 Murray Hill, NJ 07974 417 USA 419 Email: iwidjaja@lucent.com 421 Intellectual Property Statement 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at 443 ietf-ipr@ietf.org. 445 Disclaimer of Validity 447 This document and the information contained herein are provided on an 448 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 449 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 450 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 451 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 452 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 453 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 455 Copyright Statement 457 Copyright (C) The Internet Society (2006). This document is subject 458 to the rights, licenses and restrictions contained in BCP 78, and 459 except as set forth therein, the authors retain all their rights. 461 Acknowledgment 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society.