Network Working Group Y. Chadli Internet-Draft X. Marjou Intended status: Standards Track France Telecom Expires: June 6, 2008 December 04, 2007 An overload control package for the Session Initiation Protocol (SIP). draft-chadli-sipping-overload-sub-not-00 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 June 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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 retrieve overload control information from an 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. Chadli & Marjou Expires June 6, 2008 [Page 1] Internet-Draft Overload control package December 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations for using Subscribe/Notify mechanism . . . . . . . 4 3.1. Implementation on servers 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . 8 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. Additional considerations . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative references . . . . . . . . . . . . . . . . . . . 10 9.2. Informative references . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Chadli & Marjou Expires June 6, 2008 [Page 2] Internet-Draft Overload control package December 2007 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] demonstrates 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] and RFC3265 [3], and specifies the usage of the following terms: Downstream entity: Network element that sends flows toward network Chadli & Marjou Expires June 6, 2008 [Page 3] Internet-Draft Overload control package December 2007 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 servers farm configuration SIP servers farms are often implemented as a cluster of servers with one or more front-end servers. The frond-end server interfaces to the other network nodes and performs load balancing on the different servers of the cluster. In such a case, the load control mechanism can be implemented and managed only by front-end servers as only th/ ose 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 configurations 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 Record-Route for a server acting as a stateful 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 Chadli & Marjou Expires June 6, 2008 [Page 4] Internet-Draft Overload control package December 2007 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 frond-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, susceptible to carry this information, in order to extract it. Chadli & Marjou Expires June 6, 2008 [Page 5] Internet-Draft Overload control package December 2007 |---------------------------------| | +----------+ +----------+ | | | 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. Provided that 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 sensible and a server may want to restrict the access to this information only to the trusted elements. 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 status information. 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. Exchanging 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 which is connected through an outbound proxy. This allows to Chadli & Marjou Expires June 6, 2008 [Page 6] Internet-Draft Overload control package December 2007 throttle the traffic from the source and thus to avoid loading the outbound proxy uselessly. In addition, this feature would allow centralizing overload control management on nodes that have a wide visibility on the overall network traffic. In the example given above, the home proxy also knows the traffic following 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. 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 Chadli & Marjou Expires June 6, 2008 [Page 7] Internet-Draft Overload control package December 2007 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 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]. Chadli & Marjou Expires June 6, 2008 [Page 8] Internet-Draft Overload control package December 2007 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. Additional considerations 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 Chadli & Marjou Expires June 6, 2008 [Page 9] Internet-Draft Overload control package December 2007 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 and Nick Stewart 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. 9.2. Informative references [4] Rosenberg, Jonathan., "Requirements for Management of Overload in the Session Initiation Protocol", draft-ietf-sipping-overload-reqs-01 (work in progress), November 2006. Chadli & Marjou Expires June 6, 2008 [Page 10] Internet-Draft Overload control package December 2007 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 June 6, 2008 [Page 11] Internet-Draft Overload control package December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Chadli & Marjou Expires June 6, 2008 [Page 12]