Internet Engineering Task Force SIP WG
Internet Draft J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia U.
G. Camarillo
Ericsson
draft-ietf-sip-sctp-02.txt
May 28, 2002
Expires: November, 2002
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission 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.
J. Rosenberg et. al. [Page 1]
Internet Draft SCTP as a Transport for SIP May 28, 2002
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 3
3 Potential Benefits .................................. 3
3.1 Advantages over UDP ................................. 3
3.2 Advantages over TCP ................................. 4
4 Usage of SCTP ....................................... 5
4.1 Mapping of SIP Transactions into Streams ............ 6
4.1.1 Client Side ......................................... 7
4.1.2 Server Side ......................................... 8
4.1.3 Size of the stream ID space ......................... 9
5 Locating a SIP server ............................... 10
6 Conclusion .......................................... 10
7 Author's Addresses .................................. 10
8 Normative References ................................ 11
9 Informative References .............................. 11
J. Rosenberg et. al. [Page 2]
Internet Draft SCTP as a Transport for SIP May 28, 2002
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
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.
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 Terminology
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.
3 Potential Benefits
Coene et. al. present some of the key benefits of SCTP [4]. We
summarize some of these benefits here and analyze how they relate to
SIP:
3.1 Advantages over UDP
All the advantages that SCTP has over UDP regarding SIP transport are
also shared by TCP. Below there is a list of the general advantages
that a connection-oriented transport protocol such as TCP or SCTP has
over a connection-less transport protocol such as UDP.
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
be detected much faster than when SIP is run over UDP
(detection will take at least 500ms, if not more). Note
J. Rosenberg et. al. [Page 3]
Internet Draft SCTP as a Transport for SIP May 28, 2002
that TCP SACK does exist as well, and TCP also has a fast
retransmit option. 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.
Congestion Control: SCTP maintains congestion control over the
entire association. 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 transaction 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.
Transport layer fragmentation: SCTP and TCP provide transport
layer fragmentation. If a SIP message is larger than the
MTU size it is fragmented at the transport layer. When UDP
is used fragmentation occurs at the IP layer. IP
fragmentation increases the likelihood of having packet
losses and make it difficult (when not impossible) NAT and
firewall traversal. This feature will become important if
the size of SIP messages grows dramatically.
3.2 Advantages over TCP
We have shown the advantages of SCTP and TCP over UDP. We now analyze
the advantages of SCTP over TCP.
Head of the Line: SCTP is message based as opposed to TCP that
is stream based. This allows SCTP to separate different
signalling messages at the transport layer. TCP just
understands bytes. Assembling received bytes to form
signalling messages is performed at the application layer.
Therefore, TCP always delivers an ordered stream of bytes
to the application. On the other hand, SCTP can deliver
signalling messages to the application as soon as they
arrive (when using the unordered service). The loss of a
signalling message does not affect the delivery of the rest
of the messages. 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
J. Rosenberg et. al. [Page 4]
Internet Draft SCTP as a Transport for SIP May 28, 2002
not adversely effect the ability of a different transaction
to send a message. Thus, if SIP is run between entities
with many transactions occurring 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 above).
Easier Parsing: Another advantage of message based protocols
such as SCTP and UDP over stream based protocols such as
TCP is that they allow easier parsing of messages at the
application layer. There is not need of establishing
boundaries (typically using Content-Length headers) between
different messages. However, this advantage is almost
negligible.
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.
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.
4 Usage of SCTP
Usage of SCTP requires no additional headers or syntax in SIP. Below
we show an example of a SIP URL with a transport parameter and an
example of a via header. In both examples SCTP is the transport
protocol.
J. Rosenberg et. al. [Page 5]
Internet Draft SCTP as a Transport for SIP May 28, 2002
sip:Bob.Johnson@example.com;transport=sctp
Via: SIP/2.0/SCTP ws1234.example.com:5060
Rules for sending a request over SCTP are identical to TCP. The only
difference is that an SCTP sender has to choose a particular stream
within an association in order to send the request.
Note that no SCTP identifier needs to be defined for SIP messages.
Therefore, the Payload Protocol Indentifier in SCTP DATA chunks
transporting SIP messages MUST be set to zero.
The SIP transport layers of both peers are responsible to manage the
persistent SCTP connection between them. On the sender side the core
or a client (or server) transaction generates a request (or response)
and passes it to the transport layer. The transport sends the request
to the peer's transaction layer. The peer's transaction layer is
responsible of delivering the incoming request (or response) to the
proper existing server (or client) transaction. If no server (or
client) transaction exists for the incoming message the transport
layer passes the request (or response) to the core, which may decide
to construct a new server (or client) transaction.
The mapping of SIP transactions into SCTP stream IDs serves two
purposes:
1. Avoid Head Of the Line (HOL) blocking
2. Provide a lightweight mechanism to perform transaction
identification. This allows an efficient delivery of
incoming SIP messages from the SIP transport layer to the
client or server transaction the message belongs to.
The former is REQUIRED whereas the latter is RECOMMENDED. This
document describes how to achieve both goals.
We believe that using stream IDs to demultiplex incoming
traffic is a useful mechanism to implement highly efficient
SIP proxies and gateways. However, we too believe that it
is essential that a SIP entity that is not stream ID aware
can interoperate with any other implementation. That is why
this feature is optional, and so, the second bullet is
RECOMMENDED and not REQUIRED.
4.1 Mapping of SIP Transactions into Streams
A SIP entity needs to relate incoming SIP messages to existing client
and server transactions. On the client side incoming responses need
J. Rosenberg et. al. [Page 6]
Internet Draft SCTP as a Transport for SIP May 28, 2002
to be delivered to the client transaction that generated the request.
On the server side:
1. ACKs for non-2xx final responses need to be delivered to
the INVITE server transaction that generated the response.
2. The core needs to relate incoming CANCEL requests to
existing server transactions.
Note that retransmissions of a request are never received over a
reliable transport such as SCTP.
In order to match a particular SIP message with an existing client or
server transaction it is necessary to compute the transaction
identifier of the message. The transaction identifier consists of the
To, From, Call-ID, Cseq and topmost Via header fields. The use of
SCTP stream IDs as lightweight transaction identifiers saves parsing
these headers every time a new SIP message arrives.
If a SIP entity chooses not to use SCTP stream IDs as lightweight
transaction identifiers it MUST send every request and every response
it generates using the SCTP stream ID zero with the "unordered" flag
set.
A SIP entity that decides to use stream IDs to identify particular
transactions MUST follow the rules described below (Sections 4.1.1
and 4.1.2).
4.1.1 Client Side
The decision of whether or not to use the SCTP stream ID to
demultiplex incoming traffic is made on a transaction basis by the
client's transport layer. If the transaction layer intends to perform
SIP traffic demultiplexing based on stream IDs for the current
transaction it MUST follow the rules below. If the transaction layer
does not intend to use stream IDs for that purpose for this
particular transaction it MUST send the request using the SCTP stream
ID zero with the "unordered" flag set.
A transport layer receiving a request from the core (as opposed to
from a client transaction layer) MUST send the request using the SCTP
stream ID zero with the "unordered" flag set.
A transport layer performing demultiplexing based on stream IDs MUST
use an uneven stream ID to send the any request but CANCEL. CANCEL
requests MUST be sent over the stream ID that the request to be
cancelled was sent plus one (e.g., an INVITE over stream 1 and its
CANCEL over stream 2). This rule implies that the highest stream ID
J. Rosenberg et. al. [Page 7]
Internet Draft SCTP as a Transport for SIP May 28, 2002
(2**16-1) MUST NOT be used to send SIP traffic.
A transport layer sending a request over a stream ID different than
zero MUST be able to relate the stream ID used to send the request
with the client transaction that generated the request. This MAY be
done by implementing an indexed table that relates stream IDs with
client transactions. Responses arriving over this particular stream
ID MUST be delivered to the client transaction that generated the
request.
Requests sent over a stream different than zero MUST NOT have the
"unordered" flag set.
A particular stream ID different than zero MUST NOT be used by more
than one client transaction at a time. Note, however, that a
particular stream ID MAY be used at the same time by a client
transaction and by a server transaction.
The transaction layer is able to distinguish requests from
responses and thus it is able to decide whether to deliver
the incoming SIP message to the client or to the server
transaction.
Effectively, a particular stream ID can be reused by a new client
transaction once the client transaction currently related to it
terminates. If an indexed table is used, the entry corresponding to
this transaction is removed at this point of time.
ACKs are a special case. ACK requests for non-2xx responses to an
INVITE are generated by the client transaction. They MUST be sent
over the same stream ID as the INVITE was sent. ACK requests for 2xx
responses for the INVITE are generated by the Transaction User. As
previously stated, every request generated by the core is sent over
stream ID zero with the "unordered" flag set.
4.1.2 Server Side
The decision of whether or not to use the SCTP stream ID to
demultiplex incoming traffic is made on a transaction basis by the
server's transport layer. If the transaction layer intends to perform
SIP traffic demultiplexing based on stream IDs for the current
transaction it MUST follow the rules below. If the transaction layer
does not intend to use stream IDs for that purpose for this
particular transaction it MUST send all responses it generates for
this transaction over stream zero with the "unordered" flag set.
If a transport layer chooses to demultiplex traffic based on stream
IDs it MUST be able to relate stream IDs with server transactions.
J. Rosenberg et. al. [Page 8]
Internet Draft SCTP as a Transport for SIP May 28, 2002
This MAY be implemented using an indexed table. When a new request
arrives over a stream different than zero, if the stream ID is
related to an existing server transaction the request MUST be passed
to that server transaction. If the stream ID is not related to any
server transaction the request is passed to the core. The SIP
transport layer MUST inform the core about the stream ID the request
was received over. If the core decides to create a server transaction
for the request, it MUST inform the transport layer about the server
transaction that corresponds to that particular stream ID.
If an indexed table is used an entry relating the stream ID
with the newly created server transaction is added.
When a server transaction passes a response to the SIP transport
layer this response MUST be sent over the stream ID corresponding to
this transaction. Responses passed to the transport layer directly
from the core (no server transaction involved) MUST be sent over
stream ID zero.
Once a server transaction terminates the bundling between this sever
transaction and the stream ID is terminated as well.
If case an indexed table is implemented, the entry for this
server transaction is removed.
Regardless of the stream ID used, the SIP transport layer MUST send
every response with the "unordered" flag set.
This avoids that a loss in a provisional response affects
the delivery of a final response within a particular
transaction.
4.1.3 Size of the stream ID space
The SCTP stream identifier is a 16-bit field. Since stream zero and
stream 2**16-1 cannot be used as transaction identifiers there are
2**15-1 = 32767 available stream IDs. A SIP proxy handling 333
requests per second (1.2 million Busy Hour Call attempts) would only
run out of stream IDs if it only handled INVITE transactions and if
every transaction lasted more than 98 seconds (INVITE transactions
typically last much less than that). Non-INVITE transactions
typically last less than INVITE transactions (16 seconds maximum
using default timers), so a proxy can handle a larger number of non-
INVITE transactions.
This calculations show that the stream ID space is large enough even
for proxies handling heavy traffic loads. And even if a proxy did
eventually run out of stream IDs, stream zero is always available for
J. Rosenberg et. al. [Page 9]
Internet Draft SCTP as a Transport for SIP May 28, 2002
the excess of traffic.
5 Locating a SIP server
The primary issue when sending a request is determining whether the
next hop server supports SCTP, so that an association can be opened.
This draft assumes that SRV records are the primary vehicle for such
determinations. RFC3261 [2] describes the process that an entity (UAC
or proxy) that wishes to send a request to a particular URI MUST
follow.
The format of the SRV RR as described in [3] is shown below:
_Service._Proto.Name TTL Class Priority weight Port Target
When SRV records are to be used, the service to use when querying for
the SRV record is "sip" and the transport protocol is "sctp". So, a
SIP client that wants to discover a SIP server that supports SCTP for
the domain example.com does a lookup of
_sip._sctp.example.com
SCTP associations 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. It is very likely that
only proxies have SRV record entries.
6 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.
7 Author's Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
J. Rosenberg et. al. [Page 10]
Internet Draft SCTP as a Transport for SIP May 28, 2002
email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com
8 Normative References
[1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T.
Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control
transmission protocol," RFC 2960, Internet Engineering Task Force,
Oct. 2000.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[3] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," RFC 2782, Internet Engineering
Task Force, Feb. 2000.
9 Informative References
[4] L. Coene, "Stream control transmission protocol applicability
statement," RFC 3257, Internet Engineering Task Force, Apr. 2002.
J. Rosenberg et. al. [Page 11]
