Internet DRAFT - draft-malas-sipping-congestion-header
draft-malas-sipping-congestion-header
Network Working Group D. Malas
Internet Draft Level 3
Expires: November 2006 R.Terpstra
Level 3
May 4, 2006
The Session Initiation Protocol (SIP) CONGESTION Header Field
draft-malas-sipping-congestion-header-01.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 4, 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
malas, terpstra Expires November 4, 2006 [Page 1]
Internet-Draft SIP CONGESTION Header May 2006
congestion awareness functionality, to compensate for current limited
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. B2BUAs (Back-to-Back User Agents)........................17
6. Operations and Management.....................................17
7. Security Considerations.......................................17
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
malas, terpstra Expires November 4, 2006 [Page 2]
Internet-Draft SIP CONGESTION Header May 2006
failure response. This is very helpful in understanding how to adjust
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 November 4, 2006 [Page 3]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 4]
Internet-Draft SIP CONGESTION Header May 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 = sent-by
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 November 4, 2006 [Page 5]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 6]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 7]
Internet-Draft SIP CONGESTION Header May 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 <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;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 <sip:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sip:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sip:bob@client.biloxi.example.com>;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 November 4, 2006 [Page 8]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 9]
Internet-Draft SIP CONGESTION Header May 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 <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;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 November 4, 2006 [Page 10]
Internet-Draft SIP CONGESTION Header May 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: <sip:ss2.biloxi.example.com;lr>,
<sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 3848276298220188511@atlanta.example.com
Contact: <sip:bob@client.biloxi.example.com;transport=UDP>
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: <sip:ss2.biloxi.example.com;lr>,
<sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 3848276298220188511@atlanta.example.com
Contact: <sip:bob@client.biloxi.example.com;transport=UDP>
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 November 4, 2006 [Page 11]
Internet-Draft SIP CONGESTION Header May 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: <sip:ss2.biloxi.example.com;lr>,
<sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 2 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=UDP>
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: <sip:ss2.biloxi.example.com;lr>,
<sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;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: <sip:bob@client.biloxi.example.com;transport=UDP>
Content-Type: application/sdp
Content-Length: 147
v=0
malas, terpstra Expires November 4, 2006 [Page 12]
Internet-Draft SIP CONGESTION Header May 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: <sip:ss1.atlanta.example.com;lr>
From: Bob <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;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 November 4, 2006 [Page 13]
Internet-Draft SIP CONGESTION Header May 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 <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;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 <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;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 <sip:bob@biloxi.example.com>;tag=314159
To: Alice <sip:alice@atlanta.example.com>;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 November 4, 2006 [Page 14]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 15]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 16]
Internet-Draft SIP CONGESTION Header May 2006
mechanism for addressing overloaded states to avoid situations when
emergency services requests are delayed or denied due to congestion.
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. B2BUAs (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.
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
malas, terpstra Expires November 4, 2006 [Page 17]
Internet-Draft SIP CONGESTION Header May 2006
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 November 4, 2006 [Page 18]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 19]
Internet-Draft SIP CONGESTION Header May 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 November 4, 2006 [Page 20]
