Network Working Group Y. Chadli Internet-Draft X. Marjou Intended status: Standards Track France Telecom Expires: August 29, 2009 February 25, 2009 An overload control package for the Session Initiation Protocol (SIP). draft-chadli-sipping-overload-sub-not-02 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), 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 August 29, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies an event package for the notification of overload control using the Session Initiation Protocol (SIP) events framework. The overload control package allows an upstream server to Chadli & Marjou Expires August 29, 2009 [Page 1] Internet-Draft Overload control package February 2009 retrieve overload control information from a downstream server and to be notified when this information changes. This information is used by the upstream server to adapt its flow toward the downstream server and thus to avoid overloading it. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations for using SUBSCRIBE/NOTIFY mechanism . . . . . . . 4 3.1. Implementation on server farm configuration . . . . . . . 4 3.2. Prioritization of overload control information . . . . . . 6 3.3. Securing overload control information . . . . . . . . . . 6 3.4. Exchanging Overload Information between Non-Neighbours Elements . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Implementation on non-SIP servers . . . . . . . . . . . . 7 4. Event Package Definition . . . . . . . . . . . . . . . . . . . 7 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7 4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 7 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8 4.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 8 4.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 4.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 4.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9 4.10. Handling of Forked Requests . . . . . . . . . . . . . . . 9 4.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 4.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 4.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 9 5. Application examples . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative references . . . . . . . . . . . . . . . . . . . 12 9.2. Informative references . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Chadli & Marjou Expires August 29, 2009 [Page 2] Internet-Draft Overload control package February 2009 1. Introduction This document specifies an event package for the management of overload control between nodes of a given network using the Session Initiation Protocol (SIP) events framework. The overload control package allows an upstream server to retrieve the load status of a downstream server and to be notified when this status changes. This information is used by the upstream server to adapt its flow toward the receiving server to avoid overloading it. [4] discusses the overload problem within SIP and provides requirements for a solution. [5] discusses models and design considerations for a SIP overload control mechanism. Both [4] and [5] demonstrate the necessity to exchange explicit overload control information between SIP entities in order to avoid network congestion. This document neither specifies the procedures and syntax for reporting overload status information nor the rules for processing this information. In fact, the nature of the overload control information to be exchanged and the processing of this information by both the upstream and the downstream entities may depend on the nature of the network and on the provided services. There are two approaches. In one approach, the upstream entity signals its current load to the downstream entity and this latter uses this information to adapt its traffic. In the other approach, the upstream entity dictates explicit rules to be applied by the sending entity. In this latter solution, different types of rules exist in the literature. Even when only the load status is reported, different syntax may be used. Under overload conditions, in order to limit the amount of signalling traffic and processing capacity used by the notification mechanism, a downstream entity may decide to notify only a subset of the upstream entities having subscribed to the overload events. How this subset is determined is outside the scope of this document. A typical criteria would be to send notifications to the upstream entities that have been active during a pre-defined period before the overload conditions are met. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1]. This document also reuses the SIP terminology defined in RFC3261 [2] Chadli & Marjou Expires August 29, 2009 [Page 3] Internet-Draft Overload control package February 2009 and RFC3265 [3], and specifies the usage of the following terms: Downstream entity: Network element that sends flows toward network element, upstream entity. The nature of the sent flows depends on the related network. Upstream entity: Network element that receives flows coming from another element entity, downstream entity. The nature of the received flows depends on the related network.. 3. Motivations for using SUBSCRIBE/NOTIFY mechanism This section discusses the advantages of using a new SIP event package to carry overload control information. The use of a dedicated SIP subscription allows separating transport of this information from the normal applicative traffic. This separation is necessary to allow: o The overload mechanism to be supported on SIP servers implemented as a cluster of servers. o Prioritizing overload control messages over normal signalling traffic. o Applying different security policies to overload control messages and normal signalling traffic. o Exchanging overload information between non-neighbours Elements o The possibility to use the same mechanism by entities that do not use SIP for their applications. 3.1. Implementation on server farm configuration SIP server farms are often implemented as a cluster of servers with one or more front-end servers. The front-end server interfaces to the other network nodes and performs load balancing on the different servers of the cluster. Support of such configuration is required in [4]/ REQ 23. In such a case, the load control mechanism can be implemented and managed only by front-end servers as only those servers can know the overall load of the cluster. In case more than one front-end server is used, we assume that each of them knows the overall load of the cluster. The way each front-end server knows this information is out of the scope of this document. When SIP servers are implemented as a cluster of servers, two kinds of configuration are possible, regarding the handling of SIP messages: o The front-end server only dispatches out-of-dialog SIP requests to the server farms and the subsequent SIP messages related to the same SIP transaction or SIP dialogs do not go through the front- end server (see Figure 1). In that case, the server of the farm chosen to handle the initial SIP request modifies routing information before forwarding the SIP request (e.g. Via and Chadli & Marjou Expires August 29, 2009 [Page 4] Internet-Draft Overload control package February 2009 Record-Route headers for a server acting as a SIP proxy) so that the subsequent SIP messages of the related SIP transaction or dialogs are directly routed to it. Supporting such configuration requires to carry overload control information separately and independently from normal signalling traffic. |---------------------------------| | +----------+ +----------+ | | | Server 1 | | Server n |............................ | +----------+ +----------+ | . | | | | |------.------| | |..+----------+ | | | Adjacent SIP| | |--| Front-End|----| | | server | | | Server |=============================| | | +----------+ | |-------------| |---------------------------------| ==== Initial SIP requests of "normal" SIP traffic and Subsribe/ Notify(overload-control event) .... SIP responses and in-dialog requests of "normal" SIP traffic Figure 1: SIP Server implemented as cluster of servers: only initial SIP requests go through the Front-End. o All the SIP messages go through the front-end server. In such configuration, the use of SUBSCRIBE/NOTIFY to carry overload control information has the following advantages: * Overload control information is sent asynchronously from the normal SIP traffic. Thus, compared to transporting the overload control information embedded into the normal traffic, this information may be sent even when there is no normal traffic to be sent to the downstream entity. Moreover, the front-end server does not need to parse outgoing traffic in order to insert this information. * Identification of received messages carrying overload information is easy. Compared to transporting the overload control information embedded into the normal traffic, the front-end server does not need to parse all the received messages, able to carry this information, in order to extract it. Chadli & Marjou Expires August 29, 2009 [Page 5] Internet-Draft Overload control package February 2009 |---------------------------------| | +----------+ +----------+ | | | Server 1 | | Server n | | | +----------+ +----------+ | | | | | | | | | |-------------| | | +----------+ | | | Adjacent SIP| | |--| Front-End|----| | | server | | | Server |=============================| | | +----------+ | |-------------| |---------------------------------| ====== All "Normal" SIP traffic & Sub/Not (overload-control event) Figure 2: SIP Server implemented as cluster of servers: all SIP messages go through the Front-End. 3.2. Prioritization of overload control information In situation where the server is overloaded it's necessary that a downstream entity is able to treat SIP messages carrying status information with a high priority. Since the overload information is carried within a dedicated SIP subscription, prioritization of such messages is possible. 3.3. Securing overload control information The overload status information of a server is sensitive and a server may want to restrict the access to this information only to the trusted elements. [4], in REQ 22, states that the mechanism must allow disabling the reporting of load information towards upstream targets based on the identity of those targets. In addition, REQ 5 of [4] states that the mechanism should not assume that it will only be deployed in environments with completely trusted elements. Moreover, overload information flow may represent a denial of service attack vector. For example, false load information or bogus restriction rules may be introduced into the signalling stream by a third party in order to disrupt the application work flow. The use of subscription mechanism allows a server to authenticate the network element asking for this information. Moreover, in order to avoid interception of this information by intermediary elements, it is possible to apply a suitable and dedicated security mechanism to the SIP messages transporting overload information. Chadli & Marjou Expires August 29, 2009 [Page 6] Internet-Draft Overload control package February 2009 3.4. Exchanging Overload Information between Non-Neighbours Elements The use of SUBSCRIBE/NOTIFY mechanism within a SIP-based network allows exchanging overload control information between network elements that do not exchange directly normal signalling traffic. Compared to encapsulating the overload control information into the normal traffic, identification of the sending and receiving of overload control information is naturally carried within Subscribe/ Notify messages. Exchange of overload control information between non-adjacent elements may be useful in some configurations. For instance, a home proxy may need to throttle the traffic coming from a PBX that is connected through an outbound proxy. Throttling the traffic directly from the PBX allows to avoid loading the outbound proxy uselessly. In addition, this feature would allow centralizing overload control management on nodes that have a wide visibility of the overall network traffic. In the example given above, the home proxy also knows the traffic flowing through the other outbound proxies. 3.5. Implementation on non-SIP servers Separating the transport of overload control information form normal traffic makes the implementation of the mechanism possible on network elements that are not in the path of normal SIP traffic, provided that they implement a SIP user agent. 4. Event Package Definition 4.1. Event Package Name The name of this package is "overload-control". As defined in [3], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests for this package. 4.2. Event Package Parameters No parameters are defined for this event package. 4.3. SUBSCRIBE Bodies This package defines no use of the SUBSCRIBE request body. If present, it MUST be ignored. 4.4. Subscription Duration The duration of a subscription is specific to SIP deployments and no specific recommendation is made by this Event Package. Chadli & Marjou Expires August 29, 2009 [Page 7] Internet-Draft Overload control package February 2009 It is to be noted that a one-time fetch of an overload control information, especially in case this information is the load status of the server, can be accomplished by setting the 'Expires' parameter to a value of zero, as specified in [3]. 4.5. NOTIFY Bodies The NOTIFY body MUST contain overload control information. This document does not does not define any specific contents and syntax for overload control information and delegates specification of utilised MIME types for representing overload control information to other documents. The overload control information to be carried depends on the overload control mechanism in use. The NOTIFY body MUST include a content corresponding to a MIME type specified in the 'Accept' header of the SUBSCRIBE. 4.6. Subscriber Generation of SUBSCRIBE Requests The subscribe message MUST contain the Event header set to overload control and the Accept header indicating the supported MIME types. 4.7. Notifier Processing of SUBSCRIBE Requests A successful SUBSCRIBE request results in a NOTIFY. The SUBSCRIBE request for the overload control event SHOULD be either authenticated or transmitted over an integrity protected SIP communication channels. If the identity of the entity sending the SUBSCRIBE message is not allowed to receive overload control information, the notifier MUST return a 403 "Forbidden" response. If none of MIME types specified in the Accept header of the SUBSCRIBE is supported, the Notifier SHOULD return 406 "Not Acceptable" response. 4.8. Notifier Generation of NOTIFY Requests As specified in [3], the Notifier MUST always send a NOTIFY request upon accepting a subscription. Depending on the used overload control mechanism, this MAY contain a body. For instance, if the overload mechanism is based on reporting the load status, the first NOTIFY SHOULD contain a body reporting the current load status. If the SUBSCRIBE was received over an integrity protected SIP communications channel, the Notifier SHOULD send the NOTIFY over the Chadli & Marjou Expires August 29, 2009 [Page 8] Internet-Draft Overload control package February 2009 same channel. If an Accept header was received in the SUBSCRIBE message, the body type of the NOTIFY request MUST correspond to one of the ones that were indicated in this header. 4.9. Subscriber Processing of NOTIFY Requests A Subscriber to this event package MUST adhere to the NOTIFY request processing behaviour specified in[3]. If the NOTIFY contains several bodies, only the supported ones MUST be considered. If no supported body type is present, the subscriber SHOULD unsubscribe. The subscriber MUST also be prepared to receive a NOTIFY request with no body. The subscriber MUST NOT reject the NOTIFY request with no body. The subscription dialog MUST NOT be terminated by a NOTIFY with no body. Processing of supported bodies is outside the scope of this document. 4.10. Handling of Forked Requests This Event package allows the creation of only one dialog as a result of an initial SUBSCRIBE request as described in section 4.4.9 of [3]. It does not support the creation of multiple subscriptions using forked SUBSCRIBE requests. 4.11. Rate of Notifications The rate of notifications for overload control information will depend on the overload mechanism in use. Hence, the event package specification does not specify a throttling or minimum period between NOTIFY requests. 4.12. State Agents State agents are not applicable to this Event Package. 4.13. Behavior of a Proxy Server There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP. However, Proxies SHOULD allow non-SIP URLs. 5. Application examples The SUBSCRIBE/NOTIFY mechanism described in this document may be used Chadli & Marjou Expires August 29, 2009 [Page 9] Internet-Draft Overload control package February 2009 to implement any overload control mechanism that requires explicit exchange of overload information. [5] discusses two implemention models of an explicit overload control mechanism: hop-by-hop and end- to-end. Moreover, different types of information may be exchanged between network elements depending on the used overload mechanism. [5] discusses five types of overload control mechanism based on the type of information conveyed between network elements: o Rate-based Overload Control o Loss-based Overload Control o Window-based Overload Control o Signal-based Overload Control o On-/Off Overload Control The SUBSCRIBE/NOTIFY based mechanism described in this document may be used to implement all of the overload control mechanisms listed . Although signal-based and On/Off overload mechanisms may be easily implemented using 503 "Server Unavailable", the use of SUBSCRIBE/ NOTIFY may be justified in case these mechanisms are used in conjunction with other mechanisms that require exchange of more complex overload information or when there is a need to send the overload information to a particular network element in the signalling path Hereafter, an example of XML schema for a Rate-Based Overload Control mechanism: Chadli & Marjou Expires August 29, 2009 [Page 10] Internet-Draft Overload control package February 2009 Application layer address, e.g. SIP URI, phone number. Some addresses may be wildcarded using a delimited regular expression. Chadli & Marjou Expires August 29, 2009 [Page 11] Internet-Draft Overload control package February 2009 6. IANA Considerations This specification registers a new event package as defined in [3]. The following information required for this registration: Package Name: overload-control Type: package Published specification: This document Persons to Contact: Youssef CHADLI, Youssef.chadli@orange-ftgroup.com 7. Security Considerations Overload information is particularly sensitive and access to this information by malicious elements may increase the risk of security attacks. At a minimum, subscriptions to this event package SHOULD be authenticated and properly authorized. Furthermore, notifications SHOULD be encrypted and integrity protected using either end-to-end mechanisms, or the hop-by-hop protection afforded messages sent to SIPS URIs. 8. Acknowledgements The authors would like to thank Bruno Chatras (Orange) and Nick Stewart (BT) for their contributions to this document. 9. References 9.1. Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 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. [3] Roach, Alan., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Chadli & Marjou Expires August 29, 2009 [Page 12] Internet-Draft Overload control package February 2009 9.2. Informative references [4] Rosenberg, Jonathan., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, May 2008. [5] Rosenberg, Jonathan., "Design Considerations for Session Initiation Protocol (SIP) Overload Control", draft-ietf-sipping-overload-design-00 (work in progress), May 2008. Authors' Addresses Youssef Chadli France Telecom 38, avenue General Leclerc Issy les Moulineaux 92130 France Email: youssef.chadli@orange-ftgroup.com Xavier Marjou France Telecom 2, rue Pierre Marzin Lannion 22307 France Email: xavier.marjou@orange-ftgroup.com Chadli & Marjou Expires August 29, 2009 [Page 13]