Network Working Group P. Jones Internet Draft V. Bhargava Intended status: Standards Track G. Salgueiro Expires: November 4, 2010 Cisco Systems May 4, 2010 Using OPTIONS to Query for Operational Status in the Session Initiation Protocol (SIP) draft-jones-sip-options-ping-01.txt 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 November 4, 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. Jones, et al. Expires November 4, 2010 [Page 1] Internet-Draft OPTIONS to Query for Status May 2010 Abstract This document describes a procedure for using the OPTIONS method defined for the Session Initiation Protocol (SIP) in order to allow one SIP entity to query the status of another SIP entity. Through discovery of the status of a SIP entity, it is possible to expedite session establishment or provide diagnostic information to network administrators. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Required Support...............................................3 4. Problem Statement..............................................3 5. Procedure for Using OPTIONS to Query for Operational Status....4 5.1. Transmitting OPTIONS messages.............................4 5.2. Processing OPTIONS messages...............................5 6. SIP Response Codes Handling....................................5 7. Frequency of Message Transmission..............................6 8. Security Considerations........................................6 9. IANA Considerations............................................6 10. Acknowledgments...............................................7 11. References....................................................7 11.1. Normative References.....................................7 Author's Addresses................................................7 1. Introduction In order to build efficient and robust networks that utilize the Session Initiation Protocol (SIP) [1], it is sometimes necessary for one SIP entity to know the status of another SIP entity. Having this knowledge can better enable intelligent routing of messages when establishing a dialog. This knowledge may also be used to alert network administrators to potential problems with SIP entities so that corrective action can be taken to maintain healthy network and system performance. The SIP specification defines a REGISTER method that enables a SIP user agent to register with a registrar and to send periodic registration messages. The purpose for the REGISTER message is to add and remove bindings, though it may also serve as a type of "keep-alive" mechanism to assist in determining whether a user agent is presently available. However, a REGISTER message is not the appropriate method to communicate SIP entity status between any two SIP entities, such as between two SIP proxies or between a B2BUA and any number of peer B2BUAs that help facilitate communication between administrative domains. Jones, et al. Expires November 4, 2010 [Page 2] Internet-Draft OPTIONS to Query for Status May 2010 One use of the OPTIONS method is to enable a SIP entity to query for the capabilities of a remote SIP entity in advance of establishing a dialog, which may help in selecting an appropriate target user agent. By extending the scope of this method it is possible to enable any SIP entity to query for the operational status of another SIP entity, thereby achieving the objective of equipping SIP entities with more knowledge about the operational status of peer entities. This document defines the usage of the OPTIONS message in order to determine the operational status of any SIP entity. It is worth noting that OPTIONS is widely used today by numerous equipment manufacturers to determine operational status. Unfortunately, use of OPTIONS in this way is not always implemented consistently from one manufacturer to another. It is for this reason that the IETF should define a formal procedure to ensure interoperability. 2. Conventions used in this document 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 RFC 2119 [2]. 3. Required Support Transmission of the OPTIONS message between any two entities is optional. The SIP specification requires that all user agents support the OPTIONS message. To comply with procedures described in this document, all entities, including SIP user agents and proxy servers, MUST support the OPTIONS message when received outside of a dialog in accordance with this memo. 4. Problem Statement A SIP-based communication network relies on call signaling messages exchanged between communicating SIP entities. A robust communications network provides for redundancy such that failure of no one entity will interrupt communications through the network. SIP provides a way to find the next hop entity and redirect messages dynamically through the use of DNS. Each SIP entity may query DNS for a list of addresses of next hop entities to which to forward a message. In cases where DNS is not used, a SIP entity may be statically provisioned with information relating to next hop entities. Jones, et al. Expires November 4, 2010 [Page 3] Internet-Draft OPTIONS to Query for Status May 2010 Either with the use of DNS or through static provisioning, there are no mechanisms to prevent delays that may result from messages sent to unresponsive SIP entities. To prevent unnecessary delay due to timeouts and subsequent message re-transmissions, a method by which each entity may discover the operational status of its communicating peers is needed. Note that communication delays may still exist due to network congestion, but such issues are outside the scope of this memo. This memo proposes the use of OPTIONS to determine the operational status of peer SIP entities to reduce delays and improve overall operational efficiency. This memo does not replace the use of OPTIONS as described in RFC 3261, namely to discover the communicating entity's capabilities, but does further expand on use of OPTIONS to determine the basic state of a SIP entity as per RFC 3261 Section 11.2. The use of OPTIONS as described in this document is strictly as a mechanism to determine the operational status of a neighboring entity. This memo also does not impose any new requirements on the underlying transport protocol. 5. Procedure for Using OPTIONS to Query for Operational Status All SIP entities are required to respond to OPTIONS messages, though not all SIP entities are required to transmit OPTIONS messages. Implementations that adhere to this specification MUST transmit OPTIONS messages for the purpose of determining operational status as described in subsequent sections. Further, implementations that adhere to this specification must respond to OPTIONS messages that query for operational status as defined below. These procedures are often informally referred to as an "OPTIONS ping". 5.1. Transmitting OPTIONS messages SIP entities transmit an OPTIONS message outside of a dialog periodically or as desired in order to determine the status of another SIP entity. For the purposes of this memo, the transmitting and receiving SIP entities may be SIP User Agents, including B2BUAs, or SIP proxies. The syntax of the OPTIONS message is described in RFC 3261. The reason for sending OPTIONS messages as per this memo is to discover whether one or more neighboring SIP entities are presently operable and able to process signaling messages. Having this information in advance can help reduce the time required to Jones, et al. Expires November 4, 2010 [Page 4] Internet-Draft OPTIONS to Query for Status May 2010 establish a SIP session and might help avoid session establishment failures. While any addressing mechanism might be used to transmit OPTIONS messages, use of IP addresses is RECOMMENDED in this memo. When a SIP entity is configured to send OPTIONS messages to peer SIP entities and is configured with a hostname, the transmitting SIP entity MUST first resolve the name using DNS, looking for both multiple address records and SRV records, which may in turn be associated with multiple address records. The OPTIONS message SHOULD be addressed to a peer SIP entity using a SIP URI of the form "sip:hostport" (see Section 25.1 of RFC 3261 for definitions). For example, "sip:192.168.1.5" is preferred, whereas "sip:bob@example.com" is not preferred for the purpose of this memo. The OPTIONS message MUST be transmitted directly to the peer's IP address and not to an intermediary SIP entity. Further, SIP entities SHOULD set the Max-Forwards header field value to 1. To avoid unduly taxing a receiving SIP entity, transmitters of OPTIONS messages MUST honor the Retry-After header field if received. A SIP entity MAY transmit an OPTIONS message to a peer SIP entity, even when there is other ongoing message exchanges. The reason is that, though a receiving SIP entity may be responsive to other SIP messages, it may have been put into a maintenance state, meaning it should not facilitate the establishment of new SIP sessions. Use of OPTIONS messages as per this memo can help facilitate the graceful shutdown of equipment. 5.2. Processing OPTIONS messages A SIP entity that receives an OPTIONS message MUST respond with a status code indicative of its present ability to process SIP signaling messages. Refer to section 6 for response codes. 6. SIP Response Codes Handling A SIP entity MUST respond to an OPTIONS method with a 200 response code when it is willing and able to process SIP messages, unless one of the following response codes is more appropriate. When a receiving SIP entity is unable to process SIP messages, it SHOULD respond with a 503 response code. A 503 response code is also used when a SIP entity is placed into a maintenance mode to indicate that it SHOULD NOT accept new SIP dialogs. Jones, et al. Expires November 4, 2010 [Page 5] Internet-Draft OPTIONS to Query for Status May 2010 When a receiving SIP entity is experiencing heavy load, but still willing to accept new dialogs, it SHOULD return a 486 response code. In receipt of a 486, the querying SIP entity SHOULD make an effort to avoid establishing new dialogs with the heavily loaded server until it receives a 200 response code to a subsequent OPTIONS message sent to that server. Note that a SIP entity MAY respond with other 5xx or 4xx error codes as appropriate and as recommended in RFC 3261. 7. Frequency of Message Transmission Any two entities that communicate with each other on a regular basis MAY be configured to transmit an OPTIONS message from time to time as provisioned by the network administrator. The frequency with which an OPTIONS message is transmitted is outside the scope of this document. Transmission of an OPTIONS message for the purpose of learning the operational status of a remote entity may seem unnecessary if there is already active communication with the remote entity. However, using OPTIONS, even when there is already active communication, allows a querying SIP entity to learn when another SIP entity is reaching an overload state or when it has been put into a maintenance mode. If a requesting entity fails to receive a response to an OPTIONS message, it MAY retransmit that message following the procedures defined in RFC 3261. If a requesting entity receives a 486 or 503 response code, it can send a subsequent OPTIONS messages in order to detect a change in operational status, but it SHOULD, as per RFC 3261, honor the Retry-After header field received in the previous response. 8. Security Considerations All security considerations applicable to RFC 3261 apply to this RFC. Since an OPTIONS message transmitted outside of a dialog might be used to probe the network for active SIP user agents or proxy servers in preparation for an attack, network administrators SHOULD consider methods that would prevent the reception of OPTIONS messages from hosts or networks that are not trusted. 9. IANA Considerations There are no IANA considerations associated with this document. Jones, et al. Expires November 4, 2010 [Page 6] Internet-Draft OPTIONS to Query for Status May 2010 10. Acknowledgments We would like to thank all of those who provided input, including Paul Kyzivat, James Polk, Vipin Palawat, Sanjay Sinha, Darryl Sladden, Toleti Danayya Naidu, Reddy Rachumallu, David Daiker, Jerry Ziyi Lu, Vinay Pande, Sunila Ainapure, Andy West, Arunachalam Venkatraman, Tasvir Shah, Parthasarathi R., Piu Ong, Hadriel Kaplan, and Kevin Fleming. This document was prepared using 2-Word-v2.0.template.dot. 11. References 11.1. Normative References [1] Rosenberg, J., et al, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Addresses Vivek Bhargava Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Phone: +1 919 476 2223 Email: vbharga@cisco.com Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Phone: +1 919 476 2048 Email: paulej@packetizer.com Jones, et al. Expires November 4, 2010 [Page 7] Internet-Draft OPTIONS to Query for Status May 2010 Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 392 3266 Email: gsalguei@cisco.com Jones, et al. Expires November 4, 2010 [Page 8]