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]