Dispatch Working Group Parthasarathi. Ravindran Internet-Draft Cisco Systems, Inc. Intended status: Informational January 24, 2011 Expires: July 28, 2011 Session Initiation Protocol (SIP) based Media overload control Requirement draft-partha-dispatch-sip-media-overload-control-00 Abstract Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. SIP based overload mechanism exists for dedicated SIP signaling servers. But there is a need for overload control solution of SIP based media servers like PSTN GW, Session border controllers (SBC), Session Recording Server(SRS). This document summarizes problem specific to SIP media servers, requirements for the solution of SIP based media overload control. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 28, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Ravindran Expires July 28, 2011 [Page 1] Internet-Draft SIP based Media overload control Req January 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Issues in Current SIP based Media server overload mechanism . . 3 4. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Media server Usecases . . . . . . . . . . . . . . . . . . . . . 4 6. Solution Requirements . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Ravindran Expires July 28, 2011 [Page 2] Internet-Draft SIP based Media overload control Req January 2011 1. Introduction In Voice/Video over IP (VoIP) network, Session Initiation protocol (SIP) [RFC3261] is widely deployed as a signaling protocol. There are two types SIP servers based on dedicated SIP signaling handling and SIP server with media (RTP, T.38) handling. [RFC5390] provides general SIP overload requirement for SIP servers based on User agent, Proxy. SIP overload design consideration [I-D.ietf-soc-overload-design] covers dedicated SIP signaling servers overload only. SIP server with media handling is termed as media servers in this document. Media servers include different application devices namely PSTN GW, Session border controllers (SBC), Session Recording Server(SRS). A Media server uses different resources like DSP, DSO, disk, memory for handling the media. Media servers MAY overload due to the scarcity of these resources apart from CPU, Memory resource. As SIP is used as signaling protocol in media server, the overload handling using SIP provides better performance, improved quality of service, more control over the media. This document summarizes problem specific to SIP media servers, requirements for the solution of SIP based media overload control. 2. Terminology 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 [RFC2119]. This document only uses these key words when referencing normative statements in existing RFCs. 3. Issues in Current SIP based Media server overload mechanism 488 response code [RFC4412] indicates that UA/B2BUA is not capable of handling the specific request. It does not indicates the overload status of the SIP server which leads to servers spend more CPU resources in forming negatives response rather than utilizing the resource effectively. As indicated in [RFC5390], 503 with retry-after header is not effective to handle overload. [I-D.ietf-soc-overload-design] is designed only for dedicated SIP servers and its design is based on number of SIP messages. The Ravindran Expires July 28, 2011 [Page 3] Internet-Draft SIP based Media overload control Req January 2011 capacity of media server mainly depends based on the negotiated media type, codec parameters in the session. For example, the device which capable of handling 750 audio calls will be able to handle only 5-10 telepresence calls. The overload mechanism based on the number of a SIP message is not suitable for media servers. 4. Topologies As mentioned in Sec 6 of [I-D.ietf-soc-overload-design], first three topology namely load balancing, multiple source, mesh are applicable for Media overload. In load balancing topology with media servers, lot of negative responses will lead media server to spend more time in generating the negative response rather than effectively using the resources. To overcome this issue, Media server has to indicate the overload status of the device to upstream entity. There is new topology namely Edge B2BUA with media server as follows: a--\ \ b--\ \--->+---+ \---->| | c-------->| D | | | ... /--->+---+ / z--/ Edge B2BUA with Mediaserver In case Edge B2BUA with mediaserver, B2BUA MUST rejects the new request by sending 503 response with retry-after header. 5. Media server Usecases PSTN GW: In case PSTN GW, Media servers generates RTP based on the incoming PSTN media information. DSP, DS0 are external resource constraints apart from CPU and memory resource for these devices. SBC: Session border controller has two components namely session border element (SBE) and data border element (DBE). DBE performs media address hiding, transcoding, transrating, transsizing,and media interworking like SRTP to RTP. DBE uses DSP resources apart from CPU & memory. Ravindran Expires July 28, 2011 [Page 4] Internet-Draft SIP based Media overload control Req January 2011 SRS: Session Recording Server is used record the session and its requirements are mentioned in [I-D.ietf-siprec-req]. SRS uses disk, dsp resources apart from CPU, Memory. Combination: The above mentioned functionality may be co-exist in the same physical device and share the resources. 6. Solution Requirements REQ 1: The mechanism MUST be based on SIP protocol. Overload occurs due to unavailability of any of the resources in the system. REQ 2: The mechanism MUST meet all the requirements of [RFC5390]. REQ 3: The mechanism MUST consider Media servers which supports simultaneouly multiple types of media, codec types for media. REQ 4: The mechanism MUST consider multiple types of resources which will be used for media handling. REQ 5: The mechanism MUST be efficient in all network topology like load balancing, multiple source, and mesh network as mentioned in [I-D.ietf-soc-overload-design]. REQ 6: The mechanism MUST be based on external feedback to the upstream entity. 7. Security Considerations Like all protocol mechanisms, a solution for overload handling must prevent against malicious side and outside attacks. Security requirements are TBD. Any mechanism that improves the behavior of SIP elements under load will result in more predictable performance in the face of application-layer denial-of-service attacks. 8. IANA Considerations There is no IANA consideration for this draft. 9. References Ravindran Expires July 28, 2011 [Page 5] Internet-Draft SIP based Media overload control Req January 2011 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. 9.2. Informative References [RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008. [I-D.ietf-soc-overload-design] Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design Considerations for Session Initiation Protocol (SIP) Overload Control", draft-ietf-soc-overload-design-04 (work in progress), December 2010. [I-D.ietf-siprec-req] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Requirements for SIP-based Media Recording (SIPREC)", draft-ietf-siprec-req-06 (work in progress), December 2010. Author's Address R Parthasarathi Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: partr@cisco.com Ravindran Expires July 28, 2011 [Page 6]