One document matched: draft-rosenberg-sip-sctp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 20:25:32 |