Sipping Parthasarathi. Ravindran Internet-Draft Sheshadri. Shalya Intended status: Standards Track Cisco Systems, Inc. Expires: October 21, 2010 April 19, 2010 Session Initiation Protocol (SIP) Resource availability Event package draft-partha-sip-overload-resource-availability-00 Abstract Overload occurs in Session Initiation Protocol (SIP) networks when B2BUA, proxies, and user agents have insufficient resources like CPU, memory, DSP, or bandwidth to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. This document defines explicit SIP based resource monitoring and overload avoidance mechanism based on the resource availability of the entity. 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 October 21, 2010. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Ravindran & Shalya Expires October 21, 2010 [Page 1] Internet-Draft SIP Resource availability Event package April 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Resource availability indication mechanism . . . . . . . . . . 4 4. Resource availability Event package definition . . . . . . . . 5 4.1. Event Package name . . . . . . . . . . . . . . . . . . . . 6 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6 4.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 6 4.4. SUBSCRIBE duration . . . . . . . . . . . . . . . . . . . . 6 4.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Notifier processing of SUBSCRIBE Requests . . . . . . . . 7 4.7. Notifier generation of NOTIFY Requests . . . . . . . . . . 7 4.8. Subscriber processing of NOTIFY requests . . . . . . . . . 7 4.9. Handling of forked requests . . . . . . . . . . . . . . . 8 4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 8 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 . . . . 9 5.1. Contents . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. XML data format . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Namespace . . . . . . . . . . . . . . . . . . . . . . 9 5.2.2. Resource-Availability . . . . . . . . . . . . . . . . 10 5.2.3. System . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Resource . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Resource-subtype . . . . . . . . . . . . . . . . . . . . . 10 5.5. Almost-out-of-resource . . . . . . . . . . . . . . . . . . 10 5.6. Total & Available . . . . . . . . . . . . . . . . . . . . 11 5.7. Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.8. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 11 5.9. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Use Case for Resource Availability mechanism . . . . . . . . . 12 6.1. Subscriber acts as resource monitor only . . . . . . . . . 12 6.2. Subscriber acts as overload protection . . . . . . . . . . 13 6.3. Subscriber pools for resource status . . . . . . . . . . . 13 6.4. Subscriber in mixed mode . . . . . . . . . . . . . . . . . 13 7. XML Schema definition for Resource availability . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Resource availability package Registration . . . . . . . . 15 9.2. application/rai+xml MIME Registration . . . . . . . . . . 16 9.3. Resource availability indication Schema Registration . . . 17 Ravindran & Shalya Expires October 21, 2010 [Page 2] Internet-Draft SIP Resource availability Event package April 2010 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Ravindran & Shalya Expires October 21, 2010 [Page 3] Internet-Draft SIP Resource availability Event package April 2010 1. Introduction In Voice/Video over IP (VoIP) network, Session Initiation protocol (SIP) [RFC3261] is widely deployed as a signaling protocol and overload occurs in the SIP network has limited support using 503 response. Overload is said to occur if a SIP server does not have sufficient resources to process all incoming SIP messages. These resources include but not limited to CPU processing capacity, memory, DSP, DS0, network bandwidth, input/output, or disk resources. Overload requirements for SIP are explained in [RFC5390]. Overload occurs at any time and the duration of overload depends upon the resource overloaded. In case of CPU overload, when the number of incoming dialogs are reduced then the system comes to normal situation in a short span of time whereas DS0/DSP resource overload will come back to normal after the set of dialogs are terminated. It is necessary for the system to understand its current resource capability and indicate to the neighboring entity in right time to avoid congestion collapse. In this overload protection mechanism document, SIP server indicates its resource capability to the prior SIP server by which prior SIP server will be able to perform intelligent routing. 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. Apart from overload scenario, the administrator might be interested in monitoring the resource utilization pattern at any given time for deciding 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. 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 or Proxy helps load balancer, resource statistics collector to collect the data and act upon them accordingly. The solution is targeted for SIP trunks or Ravindran & Shalya Expires October 21, 2010 [Page 4] Internet-Draft SIP Resource availability Event package April 2010 between SIP servers. By the proposed mechanism, the individual devices indicate their current resource availability information through SIP event framework mechanism. 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. In case of hop-by-hop overload mechanism is required, SUBSCRIBE MAY include max-forward header with value as 1. In the load balancing scenario, the load balancer subscribes to all the relevant SIP trunks and informed about the current resource information. Based on the resource availability indication, the call is routed to the individual SIP trunk. In case one of the devices is reached almost out of the resource, the device notifies the load balancer immediately. The load balancer SHOULD NOT forward any new SIP dialog towards the notified device till further resource availability indication from the device. The threshold for each of the resource is decided based on the set of pre-configured values. This helps load balancer to decide where to route the dialog when multiple routes are available for the given dialog. In case the entire route for the given dialog in load balancer is overloaded, 500 internal error or 4xx response (response code is TBD) is sent out to incoming UAC. The algorithm of using resource availability to achieve load balancing 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. 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. The local policy has to be put in place in SIP Notifying entity to provide fair resource allocation algorithm to ensure that Non- SUBSCRIBE overloading entity may not have any unfair share of resources. 4. Resource availability Event package definition This document defines the details of the SIP event package for Resource availability based routing according to [RFC3265] Ravindran & Shalya Expires October 21, 2010 [Page 5] Internet-Draft SIP Resource availability Event package April 2010 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 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, Ravindran & Shalya Expires October 21, 2010 [Page 6] Internet-Draft SIP Resource availability Event package April 2010 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. 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. Ravindran & Shalya Expires October 21, 2010 [Page 7] Internet-Draft SIP Resource availability Event package April 2010 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. 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. Ravindran & Shalya Expires October 21, 2010 [Page 8] Internet-Draft SIP Resource availability Event package April 2010 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 o Entity parameter in Resource-availability to specify the entity whose resource information is available as part of this message o System Tuple to indicate whether the whole system is overloaded or not 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 Ravindran & Shalya Expires October 21, 2010 [Page 9] Internet-Draft SIP Resource availability Event package April 2010 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.2.3. System All resource-availability element have one System element. The system element represents the whole system as such. This element indicates how much load accepted by the system as such. In case the system is reached almost out of resource, it is expected that load balancing entity SHOULD NOT forward the request until otherwise load balancing entity knows the resource which shall be used by the new dialog without causing any impact to the current state of the system. 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, and DSO 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 based on the individual resource availability. 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.5. 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 Ravindran & Shalya Expires October 21, 2010 [Page 10] Internet-Draft SIP Resource availability Event package April 2010 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.6. Total & Available Total and Available elements provide absolute value or the value specified as per unit element. These are optional element. 5.7. Unit Unit is a string which indicates unit for the given resource or resource subtype. The default value of unit is absolute value. 5.8. 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.9. Example The example provides all the tuples involved in rai xml body. Ravindran & Shalya Expires October 21, 2010 [Page 11] Internet-Draft SIP Resource availability Event package April 2010 false false 100 50 percentage false 256 153 mb false 100 50 percentage false 32 10 true 30 10 RAI Example XML body 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. Ravindran & Shalya Expires October 21, 2010 [Page 12] Internet-Draft SIP Resource availability Event package April 2010 In this scenario, subscriber will not honor the almost out of resource information from the notifier. 6.2. 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. 6.3. 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.4. Subscriber in mixed mode Any of the above mentioned mechanism shall be combined together based on the deployment requirement. For example, Subscriber performs resource monitoring and threshold mechanism at the same time. Based on the availability of the resource, the flow of the new dialogs shall be decided. This requires tight understanding between subscriber and notifier about the resource information and utilization. Resource information of Notifier shall be provided to Subscriber through provisioning mechanism or other protocol 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 October 21, 2010 [Page 13] Internet-Draft SIP Resource availability Event package April 2010 Ravindran & Shalya Expires October 21, 2010 [Page 14] Internet-Draft SIP Resource availability Event package April 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 Ravindran & Shalya Expires October 21, 2010 [Page 15] Internet-Draft SIP Resource availability Event package April 2010 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 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 SIPPING Working Group , as designated by the IESG iesg@ietf.org Ravindran & Shalya Expires October 21, 2010 [Page 16] Internet-Draft SIP Resource availability Event package April 2010 9.3. Resource availability indication Schema Registration URI: urn:ietf:params:xml:schema:rai Registrant Contact: IETF SIPPING 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 10. Acknowledgement We wish to thank Muthu Arul Mozhi, Paul Kyzivat, Paul Jones, Sanjay Sinha for the valuable comments 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 Ravindran & Shalya Expires October 21, 2010 [Page 17] Internet-Draft SIP Resource availability Event package April 2010 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. 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 October 21, 2010 [Page 18]