SIPPING Working Group D. Malas Internet Draft Level 3 Expires: October 2006 R. Terpstra Level 3 April 24, 2006 The Session Initiation Protocol (SIP) CONGESTION Header Field draft-malas-sipping-congestion-header-00.txt 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 October 24, 2006. Abstract This document defines a new header field for use with SIP. The CONGESTION header field is used to report insufficient resources to an upstream element. It provides a means for passing the congestion information, but does not dictate how the receiver of the information should react to the information. This header is intended to provide a mechanism for decreasing the dependence on the 503 response code for determining an overloaded state. In addition, it provides detailed congestion awareness functionality, to compensate for current limited malas, terpstra Expires October 24, 2006 [Page 1] Internet-Draft SIP CONGESTION Header April 2006 capabilities in SIP. This functionality can provide specific information regarding the cause of the congestion for custom application treatment policies. Conventions used in this document 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 RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Requirements...................................................3 3. The Congestion Header..........................................5 4. Usage Examples.................................................6 4.1. SIP Registration Congestion Notification..................7 4.2. Session Establishment through Two Proxies.................8 5. SIP Application Considerations................................15 5.1. How to Calculate Congestion Levels.......................15 5.2. Responding to a Congestion Level Message.................15 5.3. Emergency Services Requests..............................16 5.4. Downstream Server Failures...............................17 5.5. B2BUA’s (Back-to-Back User Agents).......................17 6. Operations and Management.....................................17 7. Security Considerations.......................................18 8. IANA Considerations...........................................18 8.1. Registration of Congestion SIP header field..............18 9. Conclusions...................................................18 10. Acknowledgments..............................................18 11. References...................................................19 11.1. Normative References....................................19 11.2. Informative References..................................19 Author's Addresses...............................................19 Intellectual Property Statement..................................19 Disclaimer of Validity...........................................20 Copyright Statement..............................................20 Acknowledgment...................................................20 1. Introduction This document defines a new SIP [2] header field: Congestion. The Congestion header field is used as a mechanism to notify an upstream element of the present elements overloaded state. The header is an optional header, which can be included in a SIP successful, redirect or failure response. This is very helpful in understanding how to adjust malas, terpstra Expires October 24, 2006 [Page 2] Internet-Draft SIP CONGESTION Header April 2006 message directions, why a call may have been redirected, or why a call failed to be processed by a downstream element. Although this will not eliminate 503 responses, it should decrease the number by proactively responding to overload situations. The issues relating to the current, limited methods for overload control within SIP have been well documented in the work in progress “draft- rosenberg-sipping-overload-reqs-00” [3]. The congestion header provides a mechanism to address the majority of requirements identified within this draft. 2. Requirements This method is intended for all SIP user agents and application servers to respond to upstream elements of their congested state. This is not intended for the originating user agents to provide to upstream user agent servers, proxies, or similar. Originating user agents may respond to these messages, but they must not include congestion headers in responding to SIP requests. The requirements for this header are included here for the sake of convenience and continuity. Requirements referenced from work in progress “draft-rosenberg-sipping- overload-reqs-00” [3]: REQ 1: The overload mechanism shall strive to maintain the throughput of a SIP at reasonable levels even when the incoming load on the network is far in excess of its capacity. The overall throughput under load is the ultimate measure of the value of an overload control mechanism. REQ 2: The failure reduced processing capacity or overload of a single network element should be isolated from the remainder of the network, preventing a small-scale failure from becoming a widespread outage. REQ 3: The mechanism should seek to minimize the amount of configuration required in order to work. For example, it is better to avoid needing to configure a server with its SIP message throughput, as these kinds of quantities are hard to determine. REQ 4: The mechanism must be capable of dealing with elements which do not support it, so that a network can consist of a mix of ones which do and don't support it. Ideally, there should be incremental improvements in overall network throughput as increasing numbers of elements in the network support the mechanism. malas, terpstra Expires October 24, 2006 [Page 3] Internet-Draft SIP CONGESTION Header April 2006 REQ 5: The mechanism should function in an environment where an upstream element is malicious and attempting to fool the system into believing it is overloaded when its not, and vice a versa. REQ 6: The mechanism shall provide a way to unambiguously inform an upstream element that it is overloaded, as distinct from other temporary failure conditions. REQ 7: The mechanism shall provide a way for an element to throttle the amount of traffic it receives from an upstream element. This throttling shall provide the ability to reduce the traffic in incremental percentages from 0 to 100%. This recognizes the fact that "overload" is not a binary state, and there are degrees of overload. REQ 8: The mechanism shall ensure that, when a request has been rejected from an overloaded element, it is not sent to another overloaded element for processing. This requirement derives from REQ 1. REQ 9: When a request has been rejected from an overloaded element, it is not sent to another overloaded element for processing, but can be sent to one that is known to be available (i.e., not overloaded). This requirement derives from REQ 1. REQ 10: The mechanism should support servers that receive requests from a large number of different upstream elements, where the set of upstream elements is not enumerable. REQ 11: The mechanism should support servers that receive requests from a finite set of upstream elements, where the set of upstream elements is enumerable. REQ 12: The mechanism should work between servers in different domains. REQ 13: The mechanism must allow a proxy to prioritize requests, so that certain ones, such as call for emergency services, are still processed. REQ 14: The mechanism should provide unambiguous directions to client on when they should retry a request, and when they should not. This especially applies to TCP connection establishment and SIP registrations, in order to mitigate against avalanche restart. REQ 15: The mechanism shall take into account failures of downstream elements, detected either through SIP or through out-of-band means, in which case congestion indications will not be sent. REQ 16: The mechanism should attempt to minimize the overhead of the overload control messaging. malas, terpstra Expires October 24, 2006 [Page 4] Internet-Draft SIP CONGESTION Header April 2006 REQ 17: The overload mechanism must not provide an avenue for malicious attack. 3. The Congestion Header The Congestion header field MAY appear in any SIP response within a dialog, and in any response explicitly allowing the presence of this header field. In addition, the Congestion header field MAY appear in a BYE request. The syntax of the header field follows the standard SIP parameter syntax. Congestion = "Congestion" HCOLON congestion-value CRLF congestion-value = congestion-param [SEMI server-ID][SEMI system-descr] [SEMI reason-text] *(COMMA congestion-param SEMI server-ID [SEMI system- descr] [SEMI reason-text]) congestion-param = congestion-level | generic-param server-ID = “Server” EQUAL token system-descr = "CPU" | "Application" | “Network” | “Memory” | “Disk” | “TG” | token reason-text = “text” EQUAL quoted-string congestion-level = "level" EQUAL level level = “0” | “1” | “2” | “3” | “4” [SEMI “Retry-After” HCOLON delta- seconds [comment] *( SEMI retry-param)] The following values for the protocol field have been defined: CPU: The level parameter contains a CPU congestion level code. Application: The level parameter contains an Application congestion level code. Network: The level parameter contains a Network congestion level code. Memory: The level parameter contains a Memory utilization level code. Disk: The level parameter contains a Disk utilization level code. TG: The level parameter contains a Trunk Group utilization level code. Trunk Group is a loosely defined term. TG could mean a PSTN TG or a TDM Resource, such as DS-1 or PRI connection. For an IP interconnect, TG may represent a pair of IP addresses between two servers. An optional Retry-After value may be used when a congestion level 4 is set. Examples are: malas, terpstra Expires October 24, 2006 [Page 5] Internet-Draft SIP CONGESTION Header April 2006 Congestion: Server = abcd; CPU; level = 2; text= "60% Utilization Threshold" Congestion: Server = 10.10.10.164; Application; level = 4; text="Application core/restart" Congestion: Server = ss2.biloxi.example.com; Disk; level = 0; text="Normal" Congestion: Server = proxy1.nyc.example.com; Network; level = 4; text="80% Utilization Threshold" Congestion: Server = proxy1.nyc.example.com; Application; level = 0, Server = ss1.nyc.example.com; Application; level = 1; TG 1234; level = 3 Congestion: level = 2 Congestion: level = 2, Server = proxy1.nyc.example.com; level = 4 This document adds the following entry to Table 2 of [2]: Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Congestion amdr o o - - - - SUB NOT REF INF UPD PRA --- --- --- --- --- --- - - - - - - 4. Usage Examples This document does not prescribe the flows precisely as they are shown, but rather the flows illustrate the principles for best practice. They are best practices usages (orderings, syntax, selection of features for the purpose, handling of error) of SIP methods, headers and parameters. IMPORTANT: The exact flows here must not be copied as is by an implementer due to specific incorrect characteristics that were introduced into the document for convenience and are listed below. To sum up, the basic flows represent well-reviewed examples of SIP usage, which are best common practice according to IETF consensus. malas, terpstra Expires October 24, 2006 [Page 6] Internet-Draft SIP CONGESTION Header April 2006 For simplicity in reading and editing the document, there are a number of differences between some of the examples and actual SIP messages. For example, the HTTP Digest responses are not actual MD5 encodings. Call-IDs are often repeated, and CSeq counts often begin at 1. Header fields are usually shown in the same order. Usually only the minimum required header field set is shown; others that would normally be present such as Accept, Supported, Allow, etc are not shown. The following examples will focus primarily on the Congestion header response. As demonstrated in the following examples, downstream congestion level is maintained within the congestion header for multiple hop upstream SIP element information. Actors: Element Display Name URI IP Address ------- ------------ --- ---------- User Agent Alice alice@atlanta.example.com 192.0.2.101 User Agent Bob bob@biloxi.example.com 192.0.2.201 User Agent bob@chicago.example.com 192.0.2.100 Proxy Server ss1.atlanta.example.com 192.0.2.111 Proxy/Registrar ss2.biloxi.example.com 192.0.2.222 Proxy Server ss3.chicago.example.com 192.0.2.233 4.1. SIP Registration Congestion Notification Bob SIP Registrar | | | REGISTER F1 | |------------------------------>| | 401 Unauthorized F2 | |<------------------------------| | REGISTER F3 | |------------------------------>| | 200 OK F4 | |<------------------------------| | | Bob sends a SIP REGISTER request to the SIP server. A normal authentication challenge occurs between Bob and the SIP server. During the authentication challenge, the congestion header is included in the malas, terpstra Expires October 24, 2006 [Page 7] Internet-Draft SIP CONGESTION Header April 2006 401 response. After the challenge dialog is completed, it registers the user in its contact database and returns a response (200 OK) to Bob's SIP client. In addition to the contact headers, the response also includes a Congestion header that relays the congestion level of the SIP Registrar. Message Details F1 REGISTER Bob -> SIP Server F2 401 Unauthorized SIP Server -> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP ss2.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=a73kszlfl To: Bob ;tag=1410948204 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359",opaque="", stale=FALSE, SBCorithm=MD5 Congestion: Server = ss2.biloxi.example.com; Application; level = 1; Content-Length: 0 F3 REGISTER Bob -> SIP Server F4 200 OK SIP Server -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201 From: Bob ;tag=ja743ks76zlflH To: Bob ;tag=37GkEhwl6 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER Contact: ;expires=3600 Congestion: Server = ss2.biloxi.example.com; Application; level = 1; Content-Length: 0 4.2. Session Establishment through Two Proxies Alice Proxy 1 Proxy 2 Bob | | | | | INVITE F1 | | | |--------------->| | | malas, terpstra Expires October 24, 2006 [Page 8] Internet-Draft SIP CONGESTION Header April 2006 | 407 F2 | | | |<---------------| | | | ACK F3 | | | |--------------->| | | | INVITE F4 | | | |--------------->| INVITE F5 | | | 100 F6 |--------------->| INVITE F7 | |<---------------| 100 F8 |--------------->| | |<---------------| | | | | 180 F9 | | | 180 F10 |<---------------| | 180 F11 |<---------------| | |<---------------| | 200 F12 | | | 200 F13 |<---------------| | 200 F14 |<---------------| | |<---------------| | | | ACK F15 | | | |--------------->| ACK F16 | | | |--------------->| ACK F17 | | | |--------------->| | Both Way RTP Media | |<================================================>| | | | BYE F18 | | | BYE F19 |<---------------| | BYE F20 |<---------------| | |<---------------| | | | 200 F21 | | | |--------------->| 200 F22 | | | |--------------->| 200 F23 | | | |--------------->| | | | | In this scenario, Alice completes a call to Bob using two proxies Proxy 1 and Proxy 2. The initial INVITE (F1) contains a pre-loaded Route header with the address of Proxy 1 (Proxy 1 is configured as a default outbound proxy for Alice). The request does not contain the Authorization credentials Proxy 1 requires, so a 407 Proxy Authorization response is sent containing the challenge information. A new INVITE (F4) is then sent containing the correct credentials and the call proceeds. The call terminates when Bob disconnects by initiating a BYE message. The following example highlights the usage of the Congestion header in a multiple proxy environment. malas, terpstra Expires October 24, 2006 [Page 9] Internet-Draft SIP CONGESTION Header April 2006 Proxy 1 inserts a Record-Route header into the INVITE message to ensure that it is present in all subsequent message exchanges. Proxy 2 also inserts itself into the Record-Route header. The ACK (F15) and BYE (F18) both have a Route header. Message Details F1 INVITE Alice -> Proxy 1 /* Proxy 1 challenges Alice for authentication */ F2 407 Proxy Authorization Required Proxy 1 -> Alice SIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74b43 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=3flal12sf Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Proxy-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, SBCorithm=MD5 Congestion: Server = ss1.atlanta.example.com; Application; level = 0 Content-Length: 0 F3 ACK Alice -> Proxy 1 /* Alice responds by re-sending the INVITE with authentication credentials in it. */ F4 INVITE Alice -> Proxy 1 /* Proxy 1 accepts the credentials and forwards the INVITE to Proxy Client for Alice prepares to receive data on port 49172 from the network. */ F5 INVITE Proxy 1 -> Proxy 2 F6 100 Trying Proxy 1 -> Alice F7 INVITE Proxy 2 -> Bob malas, terpstra Expires October 24, 2006 [Page 10] Internet-Draft SIP CONGESTION Header April 2006 F8 100 Trying Proxy 2 -> Proxy 1 F9 180 Ringing Bob -> Proxy 2 F10 180 Ringing Proxy 2 -> Proxy 1 SIP/2.0 180 Ringing Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: , From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com Contact: CSeq: 2 INVITE Congestion: Server = ss2.biloxi.example.com; Application; level = 0 Content-Length: 0 F11 180 Ringing Proxy 1 -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: , From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com Contact: CSeq: 2 INVITE Congestion: Server = ss2.biloxi.example.com; Application; level = 0, Server = ss1.atlanta.example.com; Application; level = 0 Content-Length: 0 F12 200 OK Bob -> Proxy 2 F13 200 OK Proxy 2 -> Proxy 1 malas, terpstra Expires October 24, 2006 [Page 11] Internet-Draft SIP CONGESTION Header April 2006 SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: , From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Contact: Congestion: Server = ss2.biloxi.example.com; Application; level = 0 Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F14 200 OK Proxy 1 -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: , From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Congestion: Server = ss2.biloxi.example.com; Application; level = 0, Server = ss1.atlanta.example.com; Application; level = 0 Contact: Content-Type: application/sdp Content-Length: 147 v=0 malas, terpstra Expires October 24, 2006 [Page 12] Internet-Draft SIP CONGESTION Header April 2006 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F15 ACK Alice -> Proxy 1 F16 ACK Proxy 1 -> Proxy 2 F17 ACK Proxy 2 -> Bob /* RTP streams are established between Alice and Bob */ /* Bob Hangs Up with Alice. */ /* Again, note that the CSeq is NOT 3. Alice and Bob maintain their own separate CSeq counts */ F18 BYE Bob -> Proxy 2 F19 BYE Proxy 2 -> Proxy 1 BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 Max-Forwards: 69 Route: From: Bob ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Congestion: Server = ss2.biloxi.example.com; Application; level = 0 Content-Length: 0 F20 BYE Proxy 1 -> Alice BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 malas, terpstra Expires October 24, 2006 [Page 13] Internet-Draft SIP CONGESTION Header April 2006 ;received=192.0.2.222 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 Max-Forwards: 68 From: Bob ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Congestion: Server = ss2.biloxi.example.com; Application; level = 0, Server = ss1.atlanta.example.com; Application; level = 0 Content-Length: 0 F21 200 OK Alice -> Proxy 1 F22 200 OK Proxy 1 -> Proxy 2 SIP/2.0 200 OK Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 ;received=192.0.2.222 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.101 From: Bob ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Congestion: Server = ss1.atlanta.example.com; Application; level = 0 Content-Length: 0 F23 200 OK Proxy 2 -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=314159 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Congestion: Server = ss1.atlanta.example.com; Application; level = 0, Server = ss2.biloxi.example.com; Application; level = 0 Content-Length: 0 malas, terpstra Expires October 24, 2006 [Page 14] Internet-Draft SIP CONGESTION Header April 2006 5. SIP Application Considerations 5.1. How to Calculate Congestion Levels Calculating an element’s congestion level is dependent on the limiting resource for the element. There can be several contributing factors, such as CPU, Memory, Queue depth, calls per second, application threads, etc. However, the underlying result is that the element has reached a limit such that it cannot reliably process any more calls. If the element knows what its limiting resource is, it should be able to report different levels of congestion based on this resource. In some instances, it could be a combination of resources. Regardless, if the element knows what that resource is and the limit at which the element becomes 100% congested, then the element should also be able to recognize percentages of congestion prior to hitting 100%. The element should have configuration parameters that map the percent of congestion to a defined Congestion Level as described by this document. The element can now report its congestion level in SIP Responses. In some instances, the element itself is not congested, but one of its resources is, such as a Trunk Group on a Media Gateway Controller (MGC) or a next hop IP address to which a proxy sends. In this case, the element may still want to report the congestion on the resource, so that the sending element may be able to limit the sending of future requests to that same resource until that resource alleviates its congestion. 5.2. Responding to a Congestion Level Message When an element receives a Congestion header with a Level other than 0, the receiving element should use an algorithm to try to reduce the amount of future traffic it sends to the congested element or resource on that element. The algorithm may vary by sending element and by congestion type, e.g., element level congestion versus resource level congestion. If the egress element is congested, the ingress element can start call gapping to the congested element. Depending on the network configuration, this may result in sending a percentage of future calls that would have gone to the congested element to a different destination. In other instances, call gapping means rejecting a percentage of calls from coming into the network. If a resource on the egress element is congested, then ingress element may alter its load-balancing algorithm to lower the percentage of calls it will offer to the congested resource. This may be important, as there may be multiple egress points for reaching this same congested resource. malas, terpstra Expires October 24, 2006 [Page 15] Internet-Draft SIP CONGESTION Header April 2006 The type of gapping algorithm is open to element and vendor implementation. (Note: Call gapping is not specifying the quantity of SIP messages or calls allowed by the proxy server, it is simply specifying a treatment of new call attempts based on a specified congestion level.) However, the algorithm should provide for tunable parameters to allow the network operator to optimize over time. The settings for these parameters could be different for a carrier network versus an enterprise or VSP network. The goal of the algorithm is to alleviate congestion throughout the network. This means avoidance of propagating congestion from one element to another. This also means trying to keep the network as full as possible without reaching 100% on any given element, except when all elements approach 100%. This may not always be possible on all elements, because of the physical resources associated with the element. For example, Media Gateway (MG) and MGC may be tied directly to physical trunks in a given city or region. If that MGC or MG becomes congested, there may not be a way to spread the load across the network, because the physical resources on those elements are the only path into or out of the network in that city or region. However, for SIP resources, the network should be able to spread the load evenly across all elements as long as it does not result in quality issues. Balancing load across a network is the responsibility of the operator, but the Congestion parameter may help the operator to adjust the balancing in a more dynamic fashion by allowing the load- balancing algorithm to react to bursts or outages. 5.3. Emergency Services Requests It is generally recommended UAS’s and proxy servers should attempt to balance all SIP requests, and relative resources, to a maximum congested value level of 3. In doing so, the servers are proactively tuned to allow an emergency services request attempt to be placed to any available upstream or downstream SIP device for immediate processing and delivery to the intended emergency services provider. In some cases, a congestion level of 3 is simply impossible or difficult to maintain due to extraneous situations. Since, the upstream proxy server is providing congestion information to the downstream originating elements; the originating elements may use this data to begin alleviation treatments such as call gapping. When the UAS or proxy server receives an emergency services request, it should not be treated by the methods described and processed immediately. In the worse case, an emergency services request should be attempted immediately regardless of SIP device congested state. The Congestion header is designed to proactively communicate and provide a common malas, terpstra Expires October 24, 2006 [Page 16] Internet-Draft SIP CONGESTION Header April 2006 mechanism for addressing overloaded states to avoid situations when emergency services requests are delayed or denied due to congestion. (In the rare case when a proxy is dedicated to emergency services and fully congested, would you want to notify upstream proxies of a congestion level of 4 with retry-after?) 5.4. Downstream Server Failures In some cases, the downstream proxy is too congested to respond with a congestion level or any SIP message. When this occurs, the proxy server attempting to contact the downstream server may indicate a congestion level of the specified server with server id, trunk group, or other parameters specified in the congestion header to upstream proxy servers. The proxy would accomplish this by specifying its congestion level, and then specifying the questionable downstream proxy as described in a multi-server inclusive congestion header. Optional text may describe a questionable downstream congested server for the application to respond as necessary in retries or future attempts. 5.5. B2BUA’s (Back-to-Back User Agents) Since, B2BUA’s tend to perform a function of topology hiding, it is probably undesirable to forward congestion level information of “hidden” proxies. A B2BUA may remove “hidden” congestion information from the congestion value, but it may also indicate a congestion level on behalf of the “hidden” proxies. This will allow topology hiding while limiting the potential of external message overloading. 6. Operations and Management This header can provide a valuable tool for element operators. If it becomes necessary to “bleed” off traffic from an element for either maintenance or removal, the congestion level value within the header could be manually manipulated by the application. This will communicate to upstream elements the necessity to try alternative downstream elements for new call attempts. In accomplishing this, the element will have a graceful method removing itself as a preferred route choice. In addition, the Congestion header information can be captured within Call Detail Records (CDRs) and SNMP traps for use in service reports. These service reports could be used for network optimization. malas, terpstra Expires October 24, 2006 [Page 17] Internet-Draft SIP CONGESTION Header April 2006 7. Security Considerations A notable concern would be an external manipulation of a response, such as a man-in-the-middle attack, which includes false congestion level indicators. This would cause the upstream element to assume false information regarding the downstream element’s overloaded state. Since the Congestion header is simply an additional header in the standard SIP dialog, security should be considered in reference to suggestions included within RFC 3261. In following specified security methods as described above, manipulation of the congestion level should not be considered with any more or less of concern than manipulation of any other header within the SIP message by SIP elements within the session dialog. 8. IANA Considerations 8.1. Registration of Congestion SIP header field This document defines a new SIP header field name. Header Name: Congestion Compact Form: none Normative description: RFC xxxx 9. Conclusions The Congestion header provides a simplistic manner of an overload notification. It uses a common method of being inclusive utilizing the SIP. It allows applications, elements, vendors, and operators the opportunity to take steps associated with the information in the manner that is most appropriate for their end-to-end SIP application. Comments related to this draft are solicited and should be addressed to the working group’s mailing list at sipping@ietf.org and/or the authors. 10. Acknowledgments This document is a collaborative product of the SIPPING working group. malas, terpstra Expires October 24, 2006 [Page 18] Internet-Draft SIP CONGESTION Header April 2006 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 11.2. Informative References [3] Rosenberg, J., “Requirements for Management of Overload in the Session Initiation Protocol”, draft-rosenberg-sipping-overload- reqs-00, February 2006. Author's Addresses Daryl Malas Level 3 Communications 1025 Eldorado Blvd. Broomfield, CO USA Email: daryl.malas@level3.com Rich Terpstra Level 3 Communications 1025 Eldorado Blvd. Broomfield, CO USA Email: rich.terpstra@level3.com 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. malas, terpstra Expires October 24, 2006 [Page 19] Internet-Draft SIP CONGESTION Header April 2006 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. malas, terpstra Expires October 24, 2006 [Page 20]