\documentclass[11pt]{article}
\usepackage{i-d,l2xtools,multibib}

\newcommand{\INVITE}{\textsf{INVITE}}
\newcommand{\BYE}{\textsf{BYE}}
\newcommand{\ACK}{\textsf{ACK}}
\newcommand{\CANCEL}{\textsf{CANCEL}}
\newcommand{\OPTIONS}{\textsf{OPTIONS}}
\newcommand{\REGISTER}{\textsf{REGISTER}}
\newcommand{\PRACK}{\textsf{PRACK}}
\newcommand{\header}[1]{\textsf{#1}}
\newcommand{\host}[1]{\texttt{#1}}
\newcommand{\MUST}{\textsc{must}}
\newcommand{\MUSTNOT}{\textsc{must not}}
\newcommand{\REQUIRED}{\textsc{required}}
\newcommand{\SHALL}{\textsc{shall}}
\newcommand{\SHALLNOT}{\textsc{shall not}}
\newcommand{\SHOULD}{\textsc{should}}
\newcommand{\SHOULDNOT}{\textsc{should not}}
\newcommand{\MAY}{\textsc{may}}
\newcommand{\OPTIONAL}{\textsc{optional}}
\newcommand{\RECOMMENDED}{\textsc{recommended}}
\newcommand{\NOTRECOMMENDED}{\textsc{not recommended}}

\newenvironment{syntax}{\begin{quotation}\begin{sf}\begin{tabular}{lcll}}{\end{tabular}\end{sf}\end{quotation}}

\newcommand{\motivation}[1]{{\footnotesize\begin{quotation}#1\end{quotation}}}

\newcites{norm,nonnorm}{Normative References,Informative References}
     
\pubdate{\today}
\expires{May, 2005}
\filename{draft-ietf-sip-sctp-05}
\title{The Stream Control Transmission Protocol (SCTP) as a 
       Transport for the Session Initiation Protocol (SIP)}
\author{J. Rosenberg,H. Schulzrinne,G. Camarillo}
\address{dynamicsoft,Columbia U.,Ericsson}
\shorttitle{SCTP as a Transport for SIP}
\wg{SIP WG}
\begin{document}
\maketitle

\status{}

\begin{abstract}
This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission Protocol) as the transport between SIP (Session
Initiation Protocol) 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.
\end{abstract}

\tableofcontents
\txtinserttocspace{2}{1}

\section{Introduction}

The Stream Control Transmission Protocol (SCTP) \citenorm{rfc2960} 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) \citenorm{rfc3261}, 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. This document defines
transport of SIP over SCTP.

\section{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
\citenorm{rfc2119}.

\section{Potential Benefits}

Coene et. al. present some of the key benefits of SCTP
\citenonnorm{rfc3257}. We summarize some of these benefits here and
analyze how they relate to SIP (a more detailed analysis can be found
in~\citenonnorm{sctp-simulations}).

\subsection{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.

\begin{description}
\item[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 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.


\item[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. 


\item[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 makes it difficult (when not impossible) NAT
and firewall traversal. This feature will become important if the size
of SIP messages grows dramatically.
\end{description}

\subsection{Advantages over TCP}

We have shown the advantages of SCTP and TCP over UDP. We now analyze
the advantages of SCTP over TCP.

\begin{description}
\item[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 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).

\item[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.

\item[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 (Service Selection) procedures defined in \citenorm{rfc3261} 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.
\end{description}

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.

\section{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 field. In both examples SCTP is the transport
protocol.
\motivation{sip:Bob.Johnson@example.com;transport=sctp}
\motivation{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 (see
Section~\ref{sec:mapping}).

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 for managing
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 for 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.

\subsection{Mapping of SIP Transactions into Streams}
\label{sec:mapping}

SIP transactions need to be mapped into SCTP streams in a way that
avoids Head Of the Line (HOL) blocking. Among all the different ways
of performing this mapping that fulfil this requirement, we have
chosen the simplest one; a SIP entity {\SHOULD} send every SIP message
(request or response) over stream zero with the unordered flag set. On
the receiving side, a SIP entity {\MUST} be ready to receive SIP
messages over any stream.
\motivation{In the past, it was proposed to use SCTP stream IDs as
lightweight SIP transaction identifiers. That proposal was withdrawn
because SIP now provides (as defined in RFC 3261 \citenorm{rfc3261}) a
transaction identifier in the branch parameter of the Via
entries. This transaction identifier, missing in the previous SIP spec
\citenonnorm{rfc2543}, makes it unnecessary to use the SCTP stream IDs
to demultiplex SIP traffic.}

SIP has many circumstances in which the use of TLS \citenorm{rfc2246}
is required, for instance, for routing a SIPS URI
\citenorm{rfc3261}. As defined in RFC 3436 \citenorm{rfc3436}, TLS
running over SCTP MUST NOT use the SCTP unordered delivery service,
therefore, SIP over SCTP using TLS MUST NOT use the unordered delivery
service.  Any SIP use of an extra layer between the transport layer
and SIP that requires ordered delivery of messages must observe this
requirement.

SIP applications that require ordered delivery of messages from the
transport layer (e.g., TLS) SHOULD send SIP messages belonging to the
same SIP transaction over the same SCTP stream. Additionally, they
SHOULD send messages belonging to different SIP transactions over
different SCTP streams, as long as there are enough available streams.
\motivation{A common scenario where the above mechanism should be used
consists of two proxies exchanging SIP traffic over a TLS connection
using SCTP as the transport protocol.  This works because all of the
SIP transactions between the two proxies can be established within one
SCTP association.}

Note that if both sides of the association follow this recommendation,
when a request arrives over a particular stream, the server is free to
return responses over a different stream. This way, both sides manage
the available streams in the sending direction, independently of the
streams chosen by the other side to send a particular SIP
message. This avoids undesirable collisions when seizing a particular
stream.


\section{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. SIP entities follow normal SIP procedures to discover
\citenonnorm{rfc3263} a server that supports SCTP.

\section{Security Considerations}

The security issues raised in RFC 3261 \citenorm{rfc3261} are not
worsened by SCTP, provided the advice in Section 4 is followed and
SCTP over TLS \citenorm{rfc3436} is used where TLS would be required
in RFC 3261 \citenorm{rfc3261}. So, the mechanisms described in RFC
3436 \citenorm{rfc3436} MUST be used when SIP runs on top of TLS
\citenorm{rfc2246} and SCTP.

\section{Conclusion}

This draft has presented a discussion on the applicability of SCTP to
SIP transport, and provided a mechanism for allowing two
SCTP-capable entities to use an SCTP association to exchange SIP traffic.

\section{Author's Addresses}

\begin{verbatim}
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 

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
\end{verbatim}

%\begin{small}
%\bibliographystyle{ieeetr}
%\bibliography{string,rfc,i-d}
%\end{small}

\bibliographystylenorm{ieeetr}
\bibliographystylenonnorm{ieeetr}

\bibliographynorm{string,i-d,rfc,misc}
\bibliographynonnorm{string,i-d,rfc,misc}

\input{./boilerplate}
\input{./copyright}

\end{document}




