Internet Engineering Task Force                                   SIP WG
Internet Draft                                              J. Rosenberg
                                                             dynamicsoft
                                                          H. Schulzrinne
                                                             Columbia U.
                                                            G. Camarillo
                                                                Ericsson
draft-ietf-sip-sctp-03.txt
June 28, 2002
draft-ietf-sip-sctp-04.txt
November 19, 2003
Expires: December, 2002 May, 2004

             The Stream Control Transmission Protocol as a
             Transport for the Session Initiation Protocol

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.

                           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
   5          Locating a SIP server ...............................    7
   6          Security Considerations .............................    7
   7          Conclusion ..........................................    7
   8          Author's Addresses ..................................    7
   9          Normative References ................................    8
   10         Informative References ..............................    8

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].

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:
   SIP (a more detailed analysis can be found in [5].)

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
             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
             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 field. In both examples SCTP is the transport
   protocol.

        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 (see Section 4.1).

   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.

4.1 Mapping of SIP Transactions into Streams

   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 fulfill 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.

        Note that previous versions of this document proposed to
        use SCTP stream IDs as lightweight SIP transaction
        identifiers. That proposal has been withdrawn because SIP
        now provides a transaction identifier in the branch
        parameter of the Via entries. This transaction identifier,
        missing in the previous SIP spec [5], [6], makes it unnecessary
        to use the SCTP stream IDs to demultiplex SIP traffic.

   Some applications introduce an extra layer between the transport
   layer and SIP (e.g., compression and/or encryption). This extra layer
   sometimes requires ordered delivery of messages from the transport
   layer (e.g., TLS [6]). [7]). In this case, it is RECOMMENDED that SIP
   messages belonging to the same transaction are sent over the same
   stream and messages belonging to different transactions are sent over
   different streams. Note that if both sides of the association follow
   this recommendation, if 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.

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.
   SIP entities follow normal SIP procedures to discover [7] [8] a server
   that supports SCTP.

6 Security Considerations

   No extra security risk outside these specified by [2] are foreseen.

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

8 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

   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

9 Normative References

   [1] R. J. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
   T. Taylor, I. Rytina, and 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.  , G. Camarillo, A. R. Johnston, J.
   Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session session
   initiation protocol," Internet Draft, RFC 3261, Internet Engineering Task Force, Feb. June
   2002.  Work in progress.

   [3] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

10 Informative References

   [4] L. Coene, "Stream control transmission protocol applicability
   statement," RFC 3257, Internet Engineering Task Force, Apr. 2002.

   [5] G. Camarillo, H. Schulzrinne, and R. Kantola, "Evaluation of
   transport protocols for the session initiation protocol,"  IEEE
   Network , vol. 17, no. 5, 2003.

   [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," RFC 2543, Internet Engineering Task
   Force, Mar. 1999.

   [6]

   [7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246,
   Internet Engineering Task Force, Jan. 1999.

   [7] H. Schulzrinne and

   [8] J. Rosenberg, "SIP: Locating Rosenberg and H. Schulzrinne, "Session initiation protocol
   (SIP):  locating SIP servers,"
   Internet Draft, RFC 3263, Internet Engineering Task
   Force, Feb. June 2002.  Work in
   progress.