[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                          P. Jones
Internet Draft                                              V. Bhargava
Intended status: Standards Track                           G. Salgueiro
Expires: January 1, 2011                                  Cisco Systems
                                                           July 1, 2010



               Using OPTIONS to Query for Operational Status
                 in the Session Initiation Protocol (SIP)
                    draft-jones-sip-options-ping-02.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 January 1, 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
   carefully, as they describe your rights and restrictions with
   respect to this document.




Jones, et al.          Expires January 1, 2011                 [Page 1]


Internet-Draft       OPTIONS to Query for Status              July 2010


Abstract

   This document describes a procedure for using the Session Initiation
   Protocol (SIP) OPTIONS method in order to allow one SIP entity to
   query the operational 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 SIP
   infrastructure with expected service performance and experience.

   The SIP specification defines the REGISTER method that enables a SIP
   user agent to register with a registrar and to send periodic
   registration ("refresh") 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 proxy servers or
   between a back-to-back user agent (B2BUA) and any number of peer
   B2BUAs that help facilitate communication between administrative
   domains.


Jones, et al.          Expires January 1, 2011                 [Page 2]


Internet-Draft       OPTIONS to Query for Status              July 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.  Presently, there is no other means to determine the
   operational status of a peer SIP entity.

   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 SIP 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.




Jones, et al.          Expires January 1, 2011                 [Page 3]


Internet-Draft       OPTIONS to Query for Status              July 2010


   In cases where DNS is not used, a SIP entity may be statically
   provisioned with information relating to next hop entities.

   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

   A SIP entity transmits 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 proxy servers.  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


Jones, et al.          Expires January 1, 2011                 [Page 4]


Internet-Draft       OPTIONS to Query for Status              July 2010


   operable and able to process signaling messages.  This includes
   basic IP reachability, SIP application-level reachability, ability
   to deliver advanced SIP-based services (e.g., video), and so on.
   Having this information in advance can help reduce the time required
   to 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 request URI required when addressing a proxy is described in
   Section 11 of RFC 3261.

   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.


Jones, et al.          Expires January 1, 2011                 [Page 5]


Internet-Draft       OPTIONS to Query for Status              July 2010


   When a receiving SIP entity is unable to process additional 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.  A receiving SIP entity MAY include a Retry-After header in
   a response to the OPTIONS message to avoid further requests for a
   desired period of time.

   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.  Having said that, the frequency with which OPTIONS
   messages are transmitted SHOULD NOT place an undue burden on SIP
   entities.

   Transmission of an OPTIONS message for the purpose of learning the
   operational status of a remote SIP entity may seem unnecessary if
   there is already active communications 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 SIP 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.



Jones, et al.          Expires January 1, 2011                 [Page 6]


Internet-Draft       OPTIONS to Query for Status              July 2010


   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.

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, Kevin Fleming, and Mohamed Boucadair.

   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











Jones, et al.          Expires January 1, 2011                 [Page 7]


Internet-Draft       OPTIONS to Query for Status              July 2010


   Paul E. Jones
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709

   Phone: +1 919 476 2048
   Email: paulej@packetizer.com


   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 January 1, 2011                 [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/