Internet Draft Internet Engineering Task Force SIP WG Internet Draft Jonathan Rosenberg, Henning Schulzrinne draft-rosenberg-sip-sctp-00.txt dynamicsoft, Columbia U. June 23, 2000 Expires: December, 2000 SCTP as a Transport for SIP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document specifies a mechanism for usage of SCTP (the Stream Control Transmisson Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. 1 Introduction The Stream Control Transmission Protocol (SCTP) [1] has been designed as a new transport protocol for the Internet (or intranets), at the same layer as TCP and UDP. SCTP has been designed with the transport of legacy SS7 signaling messages in mind. We have observed that many Jonathan Rosenberg, Henning Schulzrinne [Page 1] Internet Draft SIP over SCTP June 23, 2000 of the features designed to support transport of such signaling are also useful for the transport of SIP (the Session Initiation Protocol) [2], which is used to initiate and manage interactive sessions on the Internet. SIP itself is transport-independent, and can run over any reliable or unreliable message or stream transport. However, procedures are only defined for transport over UDP and TCP. In order to encourage experimentation and evaluation of the appropriateness of SCTP for SIP transport, this document defines transport of SIP over SCTP. The primary aspect of this problem is determination that both sending entity and receiving entity support SCTP. This document defines new SRV procedures for such discovery. Note that this is not a proposal that SCTP be adopted as the primary or preferred transport for SIP; substantial evaluation of SCTP, deployment, and experimentation can take place before that happens. This draft is targeted at encouraging such experimentation by enabling it in SIP. 2 Potential Benefits Coene et. al. present some of the key benefits of SCTP [3]. We summarize some these benefits here: Multihoming: An SCTP connection can be associated with multiple IP addresses on the same host. Data is always sent over one of the addresses, but should it become unreachable, data sent to one can migrate to a different address. This improves fault tolerance; network failures making one interface of the server unavailable do not prevent the service from continuing to operate. SIP servers are likely to have substantial fault tolerance requirements. It is worth noting that because SIP is message-oriented, and not stream oriented, the existing SRV procedures defined in [2] can accomplish the same goal, even when SIP is run over TCP. In fact, SRV records allow the "connection" to fail over to a separate host. Since SIP proxies can run statelessly, failover can be accomplished without data synchronization between the primary and its backups. Thus, the multihoming capabilities of SCTP provide marginal benefits. Fast Retransmit: SCTP can quickly determine the loss of a packet, as a result of its usage of SACK and a mechanism which sends SACK messages faster than normal when losses are detected. The result is that losses of SIP messages can Jonathan Rosenberg, Henning Schulzrinne [Page 2] Internet Draft SIP over SCTP June 23, 2000 be detected much faster than when SIP is run over UDP (detection will take at least 500ms, if not more) or TCP (note that TCP SACK does exist as well, and TCP also has a fast retransmit option; it is yet to be determined how much faster SCTP's mechanism is compared to TCP). Over an existing connection, this results in faster call setup times under conditions of packet loss, which is very desirable. This is probably the most significant advantage to SCTP for SIP transport. Streams: Within a connection, SCTP can support multiple streams. Transmitted data can be associated with a particular stream. Ordering can be guaranteed within a stream, but is not enforced across streams. This avoids the head of line blocking problem in TCP, which occurs when multiple higher layer connections are multiplexed within a single TCP connection. A SIP transaction can be considered an application layer connection. Between proxies there are multiple transactions running. The loss of a message in one transaction should not adversely effect the ability of a different transaction to send a message. Thus, if SIP is run between entities with many transactions occuring in parallel, SCTP can provide improved performance over SIP over TCP (but not SIP over UDP; but SIP over UDP is not ideal from a congestion control standpoint, see below). Congestion Control: SCTP maintains congestion control over the entire connection. For SIP, this means that the aggregate rate of messages between two entities can be controlled. When SIP is run over TCP, the same advantages are afforded. However, when run over UDP, SIP provides less effective congestion control. That is because congestion state (measured in terms of the UDP retransmit interval) is computed on a transcation by transaction basis, rather than across all transactions. Congestion control performance is thus similar to opening N parallel TCP connections, as opposed to sending N messages over 1 TCP connection. It is important to note that most of the benefits of SCTP for SIP occur under loss conditions. Therefore, under a zero loss condition, SCTP transport of SIP should perform on par with TCP transport. Research is needed to evaluate under what loss conditions the improvements in setup times and throughput will be observed. The purpose of this draft is to enable such experimentation in order to provide concrete data on its applicability to SIP. Jonathan Rosenberg, Henning Schulzrinne [Page 3] Internet Draft SIP over SCTP June 23, 2000 3 Usage of SCTP Usage of SCTP requires no additional headers or syntax in SIP. The only possibility would be the addition of a transport token with value sctp in the SIP URL. But, this isn't required for operation. Rules for sending a request over SCTP are exactly identical to TCP. The primary issue is, when sending a request, determining whether the next hop server supports SCTP, so that a connection can be opened. If a connection is already opened, the issue is selection of a stream. This draft assumes that SRV records are the primary vehicle for such determinations. The text below on usage of SRV records replaces the text in Appendix D of RFC2543 [2]. When an entity (UAC or proxy) wishes to send a request to a particular URI, the following process is followed. The process consists of a number of steps. If a step elicits no addresses, the client continues to the next step. However if a step elicits one or more addresses, but no SIP server at any of those addresses responds, then the entity concludes the server is down and doesn't continue on to the next step. When SRV records are to be used, the protocol to use when querying for the SRV record is "sip". SRV records contain port numbers for servers, in addition to IP addresses; the entity always uses this port number when contacting the SIP server. Otherwise, the port number in the SIP URI is used, if present. If there is no port number in the URI, the default port, 5060, is used. 1. If the host portion of the Request-URI is an IP address, the entity contacts the server at the given address. If the host portion of the Request-URI is not an IP address, the entity proceeds to the next step. 2. The Request-URI is examined. If it contains an explicit port number, the next two steps are skipped. 3. The Request-URI is examined. If it does not specify a protocol (TCP or UDP), the entity queries the name server for SRV records for both UDP (if supported by the entity) and TCP (if supported by the entity) and SCTP (if supported by the entity) SIP servers. The format of these queries is Jonathan Rosenberg, Henning Schulzrinne [Page 4] Internet Draft SIP over SCTP June 23, 2000 defined in RFC 2782 [4]. The results of the query or queries are merged together and ordered based on priority. Then, the searching technique outlined in RFC 2782 [4] is used to select servers in order. If DNS doesn't return any records, the entity goes to the last step. Otherwise, the entity attempts to contact each server in the order listed. If no server is contacted, the entity gives up. 4. If the Request-URI specifies a protocol (TCP or UDP) that is supported by the entity, the entity queries the name server for SRV records for SIP servers of that protocol type only. If the entity does not support the protocol specified in the Request-URI, it gives up. The searching technique outlined in RFC 2782 [4] is used to select servers from the DNS response in order. If DNS doesn't return any records, the entity goes to the last step. Otherwise, the entity attempts to contact each server in the order listed. If no server is contacted, the entity gives up. 5. The entity queries the name server for address records for the host portion of the Request-URI. If there were no address records, the entity stops, as it has been unable to locate a server. By address record, we mean A RR's, AAAA RR's, or their most modern equivalent. In the process abvoe, the step of "contacting" the server consists of the following steps: 1. If the transport is UDP, simply send a request to the specific IP address and port. 2. If the transport is TCP, the entity SHOULD look for existing open connections to the given IP address and port, and then send the request over this connection if one is found. Otherwise, a new TCP connection is opened, and the request sent over it. 3. If the transport is SCTP, the entity SHOULD look for exising open SCTP connections to the given IP address and port. The number of streams within the connection, and the mapping of SIP requests to streams, are at the discretion of the entity. However, it is RECOMMENDED that some kind of stateless hash be used so that requests for the same call all be mapped into the same stream. If no SCTP connection is established, one is opened and the request sent over it. Jonathan Rosenberg, Henning Schulzrinne [Page 5] Internet Draft SIP over SCTP June 23, 2000 TCP and SCTP connections that were opened by proxies as the result of a successful SRV query SHOULD remain open after the transaction completes. The amount of time after completion of a transaction, before which the connection is closed, is configurable. The rule here for SRV provides a neat way to differentiate among connections between proxies, and between proxies and UAs and UAs and proxies. You really only want and need long lived connections between proxies. Its very likely that only proxies have SRV record entries. A entity MAY cache a successful DNS query result. A successful query is one which contained records in the answer, and a server was contacted at one of the addresses from the answer. When the entity wishes to send a request to the same host, it starts the search as if it had just received this answer from the name server. The server uses the procedures specified in RFC1035 [15] regarding cache invalidation when the time-to-live of the DNS result expires. If the entity does not find a SIP server among the addresses listed in the cached answer, it starts the search at the beginning of the sequence described above. 4 Conclusion This draft has presented a discussion on the applicability of SCTP to SIP transport, and provided an experimental mechanism for allowing two SCTP-capable entities to establish and use an SCTP connection. 5 Author's Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu Jonathan Rosenberg, Henning Schulzrinne [Page 6] Internet Draft SIP over SCTP June 23, 2000 6 Bibliography [1] R. Stewart et al. , "Simple control transmission protocol," Internet Draft, Internet Engineering Task Force, Apr. 2000. Work in progress. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [3] L. Coene, J. Loughney, I. Rytina, and L. Ong, "Simple control transmission Protocol(SCTP) applicability statement," Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in progress. [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)," Request for Comments 2782, Internet Engineering Task Force, Feb. 2000. Jonathan Rosenberg, Henning Schulzrinne [Page 7]