idnits 2.17.00 (12 Aug 2021) /tmp/idnits19667/draft-jones-sip-options-ping-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2010) is 4335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet Draft V. Bhargava 4 Intended status: Standards Track G. Salgueiro 5 Expires: January 1, 2011 Cisco Systems 6 July 1, 2010 8 Using OPTIONS to Query for Operational Status 9 in the Session Initiation Protocol (SIP) 10 draft-jones-sip-options-ping-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 1, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. 47 Abstract 49 This document describes a procedure for using the Session Initiation 50 Protocol (SIP) OPTIONS method in order to allow one SIP entity to 51 query the operational status of another SIP entity. Through 52 discovery of the status of a SIP entity, it is possible to expedite 53 session establishment or provide diagnostic information to network 54 administrators. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Conventions used in this document..............................3 60 3. Required Support...............................................3 61 4. Problem Statement..............................................3 62 5. Procedure for Using OPTIONS to Query for Operational Status....4 63 5.1. Transmitting OPTIONS messages.............................4 64 5.2. Processing OPTIONS messages...............................5 65 6. SIP Response Codes Handling....................................5 66 7. Frequency of Message Transmission..............................6 67 8. Security Considerations........................................6 68 9. IANA Considerations............................................6 69 10. Acknowledgments...............................................7 70 11. References....................................................7 71 11.1. Normative References.....................................7 72 Author's Addresses................................................7 74 1. Introduction 76 In order to build efficient and robust networks that utilize the 77 Session Initiation Protocol (SIP) [1], it is sometimes necessary for 78 one SIP entity to know the status of another SIP entity. Having 79 this knowledge can better enable intelligent routing of messages 80 when establishing a dialog. This knowledge may also be used to 81 alert network administrators to potential problems with SIP entities 82 so that corrective action can be taken to maintain healthy SIP 83 infrastructure with expected service performance and experience. 85 The SIP specification defines the REGISTER method that enables a SIP 86 user agent to register with a registrar and to send periodic 87 registration ("refresh") messages. The purpose for the REGISTER 88 message is to add and remove bindings, though it may also serve as a 89 type of "keep-alive" mechanism to assist in determining whether a 90 user agent is presently available. However, a REGISTER message is 91 not the appropriate method to communicate SIP entity status between 92 any two SIP entities, such as between two SIP proxy servers or 93 between a back-to-back user agent (B2BUA) and any number of peer 94 B2BUAs that help facilitate communication between administrative 95 domains. 97 One use of the OPTIONS method is to enable a SIP entity to query for 98 the capabilities of a remote SIP entity in advance of establishing a 99 dialog, which may help in selecting an appropriate target user 100 agent. By extending the scope of this method it is possible to 101 enable any SIP entity to query for the operational status of another 102 SIP entity, thereby achieving the objective of equipping SIP 103 entities with more knowledge about the operational status of peer 104 entities. Presently, there is no other means to determine the 105 operational status of a peer SIP entity. 107 This document defines the usage of the OPTIONS message in order to 108 determine the operational status of any SIP entity. 110 It is worth noting that OPTIONS is widely used today by numerous 111 equipment manufacturers to determine operational status. 112 Unfortunately, use of OPTIONS in this way is not always implemented 113 consistently from one manufacturer to another. It is for this 114 reason that the IETF should define a formal procedure to ensure 115 interoperability. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [2]. 123 3. Required Support 125 Transmission of the OPTIONS message between any two entities is 126 optional. 128 The SIP specification requires that all user agents support the 129 OPTIONS message. To comply with procedures described in this 130 document, all SIP entities, including SIP user agents and proxy 131 servers, MUST support the OPTIONS message when received outside of a 132 dialog in accordance with this memo. 134 4. Problem Statement 136 A SIP-based communication network relies on call signaling messages 137 exchanged between communicating SIP entities. A robust 138 communications network provides for redundancy such that failure of 139 no one entity will interrupt communications through the network. SIP 140 provides a way to find the next hop entity and redirect messages 141 dynamically through the use of DNS. Each SIP entity may query DNS 142 for a list of addresses of next hop entities to which to forward a 143 message. 145 In cases where DNS is not used, a SIP entity may be statically 146 provisioned with information relating to next hop entities. 148 Either with the use of DNS or through static provisioning, there are 149 no mechanisms to prevent delays that may result from messages sent 150 to unresponsive SIP entities. To prevent unnecessary delay due to 151 timeouts and subsequent message re-transmissions, a method by which 152 each entity may discover the operational status of its communicating 153 peers is needed. Note that communication delays may still exist due 154 to network congestion, but such issues are outside the scope of this 155 memo. 157 This memo proposes the use of OPTIONS to determine the operational 158 status of peer SIP entities to reduce delays and improve overall 159 operational efficiency. 161 This memo does not replace the use of OPTIONS as described in 162 RFC 3261, namely to discover the communicating entity's 163 capabilities, but does further expand on use of OPTIONS to determine 164 the basic state of a SIP entity as per RFC 3261 Section 11.2. The 165 use of OPTIONS as described in this document is strictly as a 166 mechanism to determine the operational status of a neighboring 167 entity. This memo also does not impose any new requirements on the 168 underlying transport protocol. 170 5. Procedure for Using OPTIONS to Query for Operational Status 172 All SIP entities are required to respond to OPTIONS messages, though 173 not all SIP entities are required to transmit OPTIONS messages. 174 Implementations that adhere to this specification MUST transmit 175 OPTIONS messages for the purpose of determining operational status 176 as described in subsequent sections. Further, implementations that 177 adhere to this specification MUST respond to OPTIONS messages that 178 query for operational status as defined below. 180 These procedures are often informally referred to as an "OPTIONS 181 ping". 183 5.1. Transmitting OPTIONS Messages 185 A SIP entity transmits an OPTIONS message outside of a dialog 186 periodically or as desired in order to determine the status of 187 another SIP entity. For the purposes of this memo, the transmitting 188 and receiving SIP entities may be SIP User Agents, including B2BUAs, 189 or SIP proxy servers. The syntax of the OPTIONS message is 190 described in RFC 3261. 192 The reason for sending OPTIONS messages as per this memo is to 193 discover whether one or more neighboring SIP entities are presently 194 operable and able to process signaling messages. This includes 195 basic IP reachability, SIP application-level reachability, ability 196 to deliver advanced SIP-based services (e.g., video), and so on. 197 Having this information in advance can help reduce the time required 198 to establish a SIP session and might help avoid session 199 establishment failures. 201 While any addressing mechanism might be used to transmit OPTIONS 202 messages, use of IP addresses is RECOMMENDED in this memo. When a 203 SIP entity is configured to send OPTIONS messages to peer SIP 204 entities and is configured with a hostname, the transmitting SIP 205 entity MUST first resolve the name using DNS, looking for both 206 multiple address records and SRV records, which may in turn be 207 associated with multiple address records. 209 The OPTIONS message SHOULD be addressed to a peer SIP entity using a 210 SIP URI of the form "sip:hostport" (see Section 25.1 of RFC 3261 for 211 definitions). For example, "sip:192.168.1.5" is preferred, whereas 212 "sip:bob@example.com" is not preferred for the purpose of this memo. 213 The request URI required when addressing a proxy is described in 214 Section 11 of RFC 3261. 216 The OPTIONS message MUST be transmitted directly to the peer's IP 217 address and not to an intermediary SIP entity. Further, SIP entities 218 SHOULD set the Max-Forwards header field value to 1. 220 To avoid unduly taxing a receiving SIP entity, transmitters of 221 OPTIONS messages MUST honor the Retry-After header field if 222 received. 224 A SIP entity MAY transmit an OPTIONS message to a peer SIP entity, 225 even when there is other ongoing message exchanges. The reason is 226 that, though a receiving SIP entity may be responsive to other SIP 227 messages, it may have been put into a maintenance state, meaning it 228 should not facilitate the establishment of new SIP sessions. Use of 229 OPTIONS messages as per this memo can help facilitate the graceful 230 shutdown of equipment. 232 5.2. Processing OPTIONS messages 234 A SIP entity that receives an OPTIONS message MUST respond with a 235 status code indicative of its present ability to process SIP 236 signaling messages. Refer to Section 6 for response codes. 238 6. SIP Response Codes Handling 240 A SIP entity MUST respond to an OPTIONS method with a 200 response 241 code when it is willing and able to process SIP messages, unless one 242 of the following response codes is more appropriate. 244 When a receiving SIP entity is unable to process additional SIP 245 messages, it SHOULD respond with a 503 response code. A 503 246 response code is also used when a SIP entity is placed into a 247 maintenance mode to indicate that it SHOULD NOT accept new SIP 248 dialogs. A receiving SIP entity MAY include a Retry-After header in 249 a response to the OPTIONS message to avoid further requests for a 250 desired period of time. 252 When a receiving SIP entity is experiencing heavy load, but still 253 willing to accept new dialogs, it SHOULD return a 486 response code. 254 In receipt of a 486, the querying SIP entity SHOULD make an effort 255 to avoid establishing new dialogs with the heavily loaded server 256 until it receives a 200 response code to a subsequent OPTIONS 257 message sent to that server. 259 Note that a SIP entity MAY respond with other 5xx or 4xx error codes 260 as appropriate and as recommended in RFC 3261. 262 7. Frequency of Message Transmission 264 Any two entities that communicate with each other on a regular basis 265 MAY be configured to transmit an OPTIONS message from time to time 266 as provisioned by the network administrator. The frequency with 267 which an OPTIONS message is transmitted is outside the scope of this 268 document. Having said that, the frequency with which OPTIONS 269 messages are transmitted SHOULD NOT place an undue burden on SIP 270 entities. 272 Transmission of an OPTIONS message for the purpose of learning the 273 operational status of a remote SIP entity may seem unnecessary if 274 there is already active communications with the remote entity. 275 However, using OPTIONS, even when there is already active 276 communication, allows a querying SIP entity to learn when another 277 SIP entity is reaching an overload state or when it has been put 278 into a maintenance mode. 280 If a requesting entity fails to receive a response to an OPTIONS 281 message, it MAY retransmit that message following the procedures 282 defined in RFC 3261. If a requesting SIP entity receives a 486 or 283 503 response code, it can send a subsequent OPTIONS messages in 284 order to detect a change in operational status, but it SHOULD, as 285 per RFC 3261, honor the Retry-After header field received in the 286 previous response. 288 8. Security Considerations 290 All security considerations applicable to RFC 3261 apply to this 291 RFC. 293 Since an OPTIONS message transmitted outside of a dialog might be 294 used to probe the network for active SIP user agents or proxy 295 servers in preparation for an attack, network administrators SHOULD 296 consider methods that would prevent the reception of OPTIONS 297 messages from hosts or networks that are not trusted. 299 9. IANA Considerations 301 There are no IANA considerations associated with this document. 303 10. Acknowledgments 305 We would like to thank all of those who provided input, including 306 Paul Kyzivat, James Polk, Vipin Palawat, Sanjay Sinha, 307 Darryl Sladden, Toleti Danayya Naidu, Reddy Rachumallu, 308 David Daiker, Jerry Ziyi Lu, Vinay Pande, Sunila Ainapure, 309 Andy West, Arunachalam Venkatraman, Tasvir Shah, Parthasarathi R., 310 Piu Ong, Hadriel Kaplan, Kevin Fleming, and Mohamed Boucadair. 312 This document was prepared using 2-Word-v2.0.template.dot. 314 11. References 316 11.1. Normative References 318 [1] Rosenberg, J., et al, "SIP: Session Initiation Protocol", RFC 319 3261, June 2002. 321 [2] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 Author's Addresses 326 Vivek Bhargava 327 Cisco Systems, Inc. 328 7025 Kit Creek Rd. 329 Research Triangle Park, NC 27709 331 Phone: +1 919 476 2223 332 Email: vbharga@cisco.com 333 Paul E. Jones 334 Cisco Systems, Inc. 335 7025 Kit Creek Rd. 336 Research Triangle Park, NC 27709 338 Phone: +1 919 476 2048 339 Email: paulej@packetizer.com 341 Gonzalo Salgueiro 342 Cisco Systems, Inc. 343 7025 Kit Creek Rd. 344 Research Triangle Park, NC 27709 345 USA 347 Phone: +1 919 392 3266 348 Email: gsalguei@cisco.com