Dispatch Working Group Parthasarathi. Ravindran Internet-Draft Sheshadri. Shalya Intended status: Standards Track Cisco Systems, Inc. Expires: March 3, 2011 August 30, 2010 Session Initiation Protocol (SIP) Resource availability Event package draft-partha-dispatch-resource-availability-00 Abstract Collecting Resource availability information in Session Initiation Protocol (SIP) devices in real time helps in better managebility of resources in the SIP network. Resource availability monitoring in SIP devices helps administrator to take informed decision and corrective measures to tackle under or over resource utilization in the network. Resource availability information can also be used for SIP overload control in SIP based Media servers by passing resource demand vector between devices. This document defines resource availability XML document and the mechanisms that can be used to exchange the document between SIP entities. 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 March 3, 2011. Copyright Notice Copyright (c) 2010 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 Ravindran & Shalya Expires March 3, 2011 [Page 1] Internet-Draft SIP Resource availability Event package August 2010 carefully, as they describe your rights and restrictions with respect 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. Ravindran & Shalya Expires March 3, 2011 [Page 2] Internet-Draft SIP Resource availability Event package August 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Resource availability indication mechanism . . . . . . . . . . 4 4. Resource availability Event package definition . . . . . . . . 5 4.1. Event Package name . . . . . . . . . . . . . . . . . . . . 5 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5 4.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 5 4.4. SUBSCRIBE duration . . . . . . . . . . . . . . . . . . . . 6 4.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Notifier processing of SUBSCRIBE Requests . . . . . . . . 6 4.7. Notifier generation of NOTIFY Requests . . . . . . . . . . 7 4.8. Subscriber processing of NOTIFY requests . . . . . . . . . 7 4.9. Handling of forked requests . . . . . . . . . . . . . . . 7 4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 7 4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 4.12. Behavior of SIP Proxy . . . . . . . . . . . . . . . . . . 8 4.13. Refresh SUBSCRIBE mechanism for failure handling . . . . . 8 5. Resource availability Indication (RAI) document format . . . . 8 5.1. Contents . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. XML data format . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. Resource-Availability . . . . . . . . . . . . . . . . 9 5.3. Resource . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Resource-subtype . . . . . . . . . . . . . . . . . . . . . 10 5.4.1. Almost-out-of-resource . . . . . . . . . . . . . . . . 10 5.5. Total & Available . . . . . . . . . . . . . . . . . . . . 10 5.6. Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.7. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 11 5.8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Use Case for Resource Availability mechanism . . . . . . . . . 12 6.1. Subscriber acts as resource monitor only . . . . . . . . . 12 6.2. Subscriber pools for resource status . . . . . . . . . . . 12 6.3. Subscriber acts as overload protection . . . . . . . . . . 12 7. XML Schema definition for Resource availability . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Resource availability package Registration . . . . . . . . 14 9.2. application/rai+xml MIME Registration . . . . . . . . . . 14 9.3. Resource availability indication Schema Registration . . . 15 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Ravindran & Shalya Expires March 3, 2011 [Page 3] Internet-Draft SIP Resource availability Event package August 2010 1. Introduction In Voice/Video over IP (VoIP) network, Session Initiation protocol (SIP) [RFC3261] is widely deployed as a signaling protocol. Resource availability information from SIP devices improves the managebility of SIP devices by providing a framework for multiple applications like Resource utilization monitoring, overload handling in SIP based media servers. Monitoring the resource utilization pattern at any given time helps VoIP administrator to decide whether the VoIP network resources need to be expanded or it is under utilized. SIP based resource utilization is preferred within SIP network and removes the need for using any other management protocol for resource monitoring purpose. Overload requirements for SIP are explained in [RFC5390]. In case of using Resource availability information for overload protection mechanism, SIP server indicates its resource capability and resource demand vector to the prior SIP server by which prior SIP server will be able to perform intelligent routing. The resouce demand vector provides the consumption of resources for the specific type of dialog (audio, video, telepresence, etc.,). As SIP is used for overload protection, it is easy to relate the overload protection information to specific SIP entity within the SIP network without having any separate naming or addressing scheme. 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. Resource availability indication mechanism Resource availability indication mechanism by UA helps resource statistics collector to collect the data and act upon them accordingly. The solution is targeted for SIP trunks or between SIP servers. By the proposed mechanism, the individual devices indicate their current resource availability information through XML document defined in this draft. Load Balancer or resource statistics collector acts as a subscriber and subscribe to the resource in the individual UA. Individual devices acts as Notifier and inform the resource information in XML. Ravindran & Shalya Expires March 3, 2011 [Page 4] Internet-Draft SIP Resource availability Event package August 2010 In the resource monitor, the periodic resource information is collected from all the devices and the reports are formed. These statistics provide effective resource utilization indication for any given resource at any point of time. This information helps administrator to take informed decision and corrective measures to tackle under or over resource utilization in the network. In the load balancing scenario, the load balancer subscribes to all the relevant SIP servers and is informed about the current resource information. Based on the resource availability indication, the call is routed to the appropriate SIP servers. In case one of the devices is reached almost out of the resource, the device notifies the load balancer immediately. This helps load balancer to decide where to route the dialog when multiple routes are available for the given dialog. The algorithm of using resource availability to achieve load balancing and resource demand vector for the individual call type is kept out of scope of this document. The threshold for the resource has to be decided by administrator by keep in mind that NOTIFY message has to be formed and send out to the external server and also resource priority dialog has to be processed without any interruption. OPTIONS response message MAY be used for exchange resource availability information. (Using OPTIONS for this package is TBD). 4. Resource availability Event package definition This document defines the details of the SIP event package for Resource availability based routing according to [RFC3265] 4.1. Event Package name The name of the event package is resource-availability. This event name has to be mentioned in the Event and allow-event header as mentioned in [RFC3265] 4.2. Event Package Parameters There is no specific event package parameter specified for this event package. 4.3. SUBSCRIBE bodies A SUBSCRIBE request for resource availability policy MAY contain a body to request the specific resources availability notification. For example, a subscriber is interested in some specific resources only. The details of the subscription filter specification are not Ravindran & Shalya Expires March 3, 2011 [Page 5] Internet-Draft SIP Resource availability Event package August 2010 yet defined. A SUBSCRIBE request sent without a body implies the default subscription behavior as specified in the sec 4.7. 4.4. SUBSCRIBE duration Subscription duration depends upon the deployment. The default duration for this package is 300 sec. It is not recommended to have the refresh timer less than 180 sec. Refresh of subscription ensures that the next hop is up before new dialog request is forwarded. Refresh subscription should be triggered 32 sec before the expiry time of the package. This keepalive mechanism is useful to decide whether Notifier trunk is reachable or not. The user defined value shall be used depending on the deployment scenario. In case of SUBSCRIBE refresh failure, it is recommended that new SUBSCRIBE is initiated after the expiry of user mentioned timer. 4.5. NOTIFY bodies The body of a NOTIFY message in this event package contains resource information of a device. The format of the NOTIFY body MUST be in one of the formats defined in the Accept header field of the SUBSCRIBE request or be the default format as specified in [RFC3265]. The default data format for the NOTIFY body of this event package is "application/rai+xml" (defined in Section 7). This means that if no Accept header field is specified to a SUBSCRIBE request, the NOTIFY will contain a body in the "application/rai+xml" format. If the Accept header field is present in SUBSCRIBE request, it MUST include "application/rai+xml" and MAY include any other types. 4.6. Notifier processing of SUBSCRIBE Requests Notifier has to provide the sensitive device resource information to the subscriber in the notification mechanism. The entire subscriber has to be authenticated before providing the package details. The existing authentication SIP mechanism like DIGEST, TLS, and S/MIME shall be used. In the trusted domain, the authentication may not be required and the administrator has to decide the trusted domain and non-trusted domain. The requested SUBSCRIBER is not allowed to receive the requested information, 403 response MUST be sent by Notifier. Ravindran & Shalya Expires March 3, 2011 [Page 6] Internet-Draft SIP Resource availability Event package August 2010 4.7. Notifier generation of NOTIFY Requests NOTIFY has to be formatted as per [RFC3265], it has to contain resource availability information. NOTIFY has to be sent immediately after SUBSCRIBE is received for initial dialog or refresh and responded with 200 OK. Notifier MUST notify SUBSCRIBER whenever any of the resource reaching almost out of the resource state or going below the configured threshold. Almost out of the resource value for the given resource or system will be decided by the administrator. The threshold notification helps SUBSCRIBER to decide whether the dialog shall be forwarded or not based on SUBSCRIBER policy. Notifier shall notify the resource information in the periodic manner. When any of the resource is reaching almost out of the resource, NOTIFY will be send which contain only the resource which reached almost out of the resource. 4.8. Subscriber processing of NOTIFY requests Subscriber updates the dialog routing logic based on the incoming NOTIFY message. In case NOTIFY message contains almost out of the resource for the specific resource or the whole system, the dialog routing logic in the subscriber has to be updated with appropriate information by which any further dialog SHOULD NOT be routed to Notifier till getting further notification with resource available indication from Notifier. In case NOTIFY is received in the periodic manner, the resource based routing and statistics for the individual device usage at a given time is updated with the received NOTIFY message body information. 4.9. Handling of forked requests Forking of SUBSCRIBE request is not supported for this package. In case of forking happened, forked response has to be handled as mentioned in Sec 4.4.9 of [RFC3265]. 4.10. Rate of Notifications Rate of Notification SHOULD NOT be less than once every 32 sec as the notification itself will be observed as an overhead otherwise. It is recommended that the rate of notification happens once every 120 sec. The administrator is the best person to decide the notification time based on the network topology. The rate of notification MAY be reduced or stopped when almost out of the resource is attained for the critical resources like CPU, Memory and the critical resource list is based on device. Ravindran & Shalya Expires March 3, 2011 [Page 7] Internet-Draft SIP Resource availability Event package August 2010 4.11. State Agents The resource availability indications are generated by SIP entity directly and there is no need of explicit state agent for this package. As load balancing based on the resource availability indication has to be done in the real time, the aggregation done by any state agent will introduce delay and hence defeat overload requirements. 4.12. Behavior of SIP Proxy This subscription mechanism is recommended for neighboring SIP entities as it provides more control on overload mechanism. In case the network topology requires to pass this resource information through proxy, Proxy has to forward SUBSCRIBE/NOTIFY messages and this may be required when intermediate proxy is interworking and load balancing is decided by entity sitting behind the proxy. 4.13. Refresh SUBSCRIBE mechanism for failure handling Apart from refresh subscription as explained in sec 4.4, Refresh subscription shall be triggered in the following network error scenarios as well: o ICMP message received during dialog creation from the Notifying entity o TCP connection failure from the Notifying entity o Dialog creation timeout Refresh Subscription shall be started whenever 503 is received for any dialog creation request from Notifying entity. Till this refresh subscription succeeds, new dialog MUST NOT be forwarded to the Notifying entity. In case of refresh SUBSCRIBE failure, new SUBSCRIBE has to be started as mentioned in sec 4.4 and no further dialog has to be forwarded till new SUBSCRIBE dialog is created. 5. Resource availability Indication (RAI) document format 5.1. Contents Resource availability indication (RAI) document is a XML document which will be embedded as message body in NOTIFY message of resource- availability package. The document contains Ravindran & Shalya Expires March 3, 2011 [Page 8] Internet-Draft SIP Resource availability Event package August 2010 o Entity parameter in Resource-availability to specify the entity whose resource information is available as part of this message o Resource Tuple indicates the individual resources total and available capabilities, and also whether the resource is available for further new dialog processing (Optional) o Resource Subtype provides the granular information within the particular resource. (Optional) 5.2. XML data format RAI object is a XML document. It MUST have the XML declaration and it SHOULD contain an encoding declaration in the XML declaration, e.g., "". If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence. Every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability. 5.2.1. Namespace The namespace URI for elements defined by this specification is a Uniform Resource Namespace (URN) [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. The URN is as follows: urn:ietf:params:xml:ns:rai 5.2.2. Resource-Availability Resource-Availability element MUST contain an xmlns namespace attribute with value as urn:ietf:params:xml:ns:rai. Resource-availability MUST have entity attribute which contains SIP/ SIPS URI to identify the device which provides the resource information. The entity attribute SIP/SIPS URI FQDN or IP address represents the device and may not have user part. 5.3. Resource This element indicates the individual resource status at the given time. This is an optional element wherein the resources type like CPU, Memory, DSP, DS0, available bandwidth, disk storage are mentioned in type attribute. Each resource element shall have almost out of resource status, total and available resource usage. This resource information helps in routing or load balancing or resource monitoring based on the individual resource availability. Available bandwidth mentioned in this element is the indicator of how many bits Ravindran & Shalya Expires March 3, 2011 [Page 9] Internet-Draft SIP Resource availability Event package August 2010 of data the system can process per second session(audio/video). 5.4. Resource-subtype This element comes within a particular resource element to provide an internal division within a given resource. For example, Memory shall be divided into processor memory, IO memory and provides the individual status. This division helps in load balancing in case routing entity aware of the resource capability required for the specified call. This is an optional element. 5.4.1. Almost-out-of-resource Almost-out-of-resource is a Boolean element to indicate whether system or resource is reached the threshold or not. This threshold is decided by Notifier or subscriber shall send it through other mechanism. Almost-out-of-resource value true indicates that the threshold is reached. To avoid the back-forth movement in the threshold range, it is preferred to provide the upper watermark value which decides the above threshold limit and lower watermark value is used when the above threshold is back to normal. True value is set for almost out of resource when upper watermark is reached and when lower watermark is reached, almost out of resource is set with false. Above Threshold <---------> Upper Watermark | | <---------> Lower Watermark Below Threshold Watermark mechanism for Threshold handling 5.5. Total & Available Total and Available elements provide absolute value or the value specified as per unit element. These are optional element. 5.6. Unit Unit is a string which indicates unit for the given resource or resource subtype. The default value of unit is absolute value. Ravindran & Shalya Expires March 3, 2011 [Page 10] Internet-Draft SIP Resource availability Event package August 2010 5.7. Timestamp Timestamp element contains a string indicating the date and time of the status change of this tuple. The value of this element MUST follow the IMPP datetime format [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the capitalized forms. As a security measure, the timestamp element SHOULD be included in all tuples unless the exact time of the status change cannot be determined. 5.8. Example The example provides all the tuples involved in rai xml body. 100 50 percentage 256 153 mb 100 50 percentage 32 10 true 30 10 2010-06-13T09:00:00Z RAI Example XML body Ravindran & Shalya Expires March 3, 2011 [Page 11] Internet-Draft SIP Resource availability Event package August 2010 6. Use Case for Resource Availability mechanism 6.1. Subscriber acts as resource monitor only This is the simple scenario wherein subscriber simply collects the Notifier statistics and store or display. This is useful when Administrator is interested in the usage of the VoIP network resource. Total and available element will be used by subscriber. In this scenario, subscriber will not honor the almost out of resource information from the notifier. 6.2. Subscriber pools for resource status In this mode, Subscriber is interested in the resource status at a given time, and one shot subscription shall be used for this mechanism. 6.3. Subscriber acts as overload protection In this deployment, subscriber stop/start the load based on the almost out of resource parameter of the body. System&aposs almost out of resource is set to true whenever any one of the resource is reached almost out of the resource. In case the subscriber is aware that the new dialog does not require the set of resource which reached almost out resource, the new dialog shall be forwarded. For example, DS0 is almost out of the resource and the new dialog does not require DS0 resource, the new dialog shall be forwarded to Notifier. The resource requirement of Notifier for the specific dialog shall be intimated to Subscriber through other protocol mechanism or provisioning mechanism which is outside the scope of this document. 7. XML Schema definition for Resource availability This section defines XML schema for resource availability document. Ravindran & Shalya Expires March 3, 2011 [Page 12] Internet-Draft SIP Resource availability Event package August 2010 Ravindran & Shalya Expires March 3, 2011 [Page 13] Internet-Draft SIP Resource availability Event package August 2010 8. Security Considerations Security consideration for event based framework as specified in [RFC3265] has to be considered for this draft as well. As the resource information is sensitive information, Subscribe/Notify shall use TLS transport in case subscriber and Notifier are in the public domain. In case subscriber is a untrusted entity, subscriber will be authenticated by responding with 401. The administrator provides authorization mechanism by which different entity will be provided with different level of information. For example, all SIP entity within enterprise could be provided complete resource information and only system level information could be provided towards service provider network. The resource information provided in this mechanism is more critical. If the above specified mechanism is not secure enough, there is a scope for coming up with addition security measures (TBD). 9. IANA Considerations This specification registers a SIP event package, a new MIME type, a new XML namespace, and a new XML schema. 9.1. Resource availability package Registration This section registers an event package based on the registration procedures defined in [RFC3265]. Package name: resource-availability Type: package Published specification: This document Person to contact: R.Parthasarathi, partr@cisco.com 9.2. application/rai+xml MIME Registration This section registers a new MIME type based on the procedures defined in [RFC4288] and guidelines in [RFC3023]. MIME media type name: application Ravindran & Shalya Expires March 3, 2011 [Page 14] Internet-Draft SIP Resource availability Event package August 2010 MIME subtype name: rai+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml in [RFC3023] Encoding considerations: Same as encoding considerations of application/xml in [RFC3023] Security considerations: See Section 10 of [RFC3023] and Section 8 of this specification Interpretability considerations: None Published Specification: This document Applications which use this media type: Load balancing SIP entities, Resource statistics collecting SIP entities Additional information: Magic number: None File extension: .xml Macintosh file type code: 'TEXT' Personal and email address for further information: Parthasarathi.R, partr@cisco.com Intended usage: COMMON Author/Change Controller: IETF Dispatch Working Group , as designated by the IESG iesg@ietf.org 9.3. Resource availability indication Schema Registration URI: urn:ietf:params:xml:schema:rai Registrant Contact: IETF Dispatch working group, Parthasarathi.R (partr@cisco.com) XML: the XML schema to be registered is contained in Section 7. Its first line is and its last line is TBD: Adding registry for resourceType and resourceSubtype tuples Ravindran & Shalya Expires March 3, 2011 [Page 15] Internet-Draft SIP Resource availability Event package August 2010 10. Acknowledgement We wish to thank Paul Kyzivat, Muthu Arul Mozhi, Paul Jones, Sanjay Sinha, Dale worley for the valuable comments. We also wish to thank Vipin Palawat, Vinay Pande, Darryl sladden, Janet Bryon for providing the initial idea on the resource availability information exchange using SIP. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [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. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. 11.2. Informative References [RFC5390] Rosenberg, J., "Requirements for Management of Overload in the Session Initiation Protocol", RFC 5390, December 2008. Ravindran & Shalya Expires March 3, 2011 [Page 16] Internet-Draft SIP Resource availability Event package August 2010 Authors' Addresses Parthasarathi R Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: partr@cisco.com Sheshadri Shalya Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: svshesha@cisco.com Ravindran & Shalya Expires March 3, 2011 [Page 17]