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-] {+draft-ietf-sip-sctp-03.txt June+} 28, 2002 Expires: [-November,-] {+December,+} 2002 [-SCTP-] {+The Stream Control Transmission Protocol+} as a Transport for [-SIP-] {+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. J. Rosenberg et. al. [Page 1] Internet Draft SCTP as a Transport for SIP [-May-] {+June+} 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-] {+7+} 6 {+Security Considerations ............................. 7 7+} Conclusion .......................................... [-10-] 7 {+8+} Author's Addresses .................................. [-10 8-] {+7 9+} Normative References ................................ [-11 9-] {+8 10+} Informative References .............................. [-11-] {+8+} J. Rosenberg et. al. [Page 2] Internet Draft SCTP as a Transport for SIP [-May-] {+June+} 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.-] {+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: 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-] {+June+} 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-] {+June+} 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.-] {+header field.+} In both examples SCTP is the transport protocol. J. Rosenberg et. al. [Page 5] Internet Draft SCTP as a Transport for SIP [-May-] {+June+} 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.-] {+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. [-The mapping-] {+4.1 Mapping+} of SIP {+Transactions into Streams SIP+} transactions {+need to be mapped+} into SCTP [-stream IDs serves two purposes: 1. Avoid-] {+streams in a way that avoids+} Head Of the Line (HOL) [-blocking 2. Provide a lightweight mechanism to perform transaction identification. This allows an efficient delivery-] {+blocking. Among all the different ways+} of [-incoming-] {+performing this mapping that fulfill this requirement, we have chosen the simplest one; a+} SIP [-messages from-] {+entity SHOULD send every SIP message (request or response) over stream zero with the unordered flag set. On+} the {+receiving side, a+} SIP [-transport layer-] {+entity MUST be ready+} to [-the client or server-] {+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 [-message belongs to. The former is REQUIRED whereas-] {+branch parameter of+} the [-latter is RECOMMENDED.-] {+Via entries.+} This [-document describes how-] {+transaction identifier, missing in the previous SIP spec [5], makes it unnecessary+} to [-achieve both goals. We believe that using-] {+use the SCTP+} stream IDs to demultiplex [-incoming traffic is a useful mechanism to implement highly efficient-] SIP [-proxies-] {+traffic. Some applications introduce an extra layer between the transport layer+} 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,-] {+(e.g., compression and/or encryption). This extra layer sometimes requires ordered delivery of messages from+} the [-second bullet-] {+transport layer (e.g., TLS [6]). In this case, it+} is RECOMMENDED [-and not REQUIRED. 4.1 Mapping of SIP Transactions into Streams A SIP entity needs to relate incoming-] {+that+} SIP messages {+belonging+} to [-existing client and server transactions. On-] the [-client side incoming responses need-] {+same transaction are sent over the same stream and messages belonging to different transactions are sent over+} J. Rosenberg et. al. [Page 6] Internet Draft SCTP as a Transport for SIP [-May-] {+June+} 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,-] {+streams. Note+} 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-] {+if both sides+} 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-] {+association+} 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-] {+this recommendation, if+} 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-] {+stream,+} 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-] {+free+} to [-the transport layer directly from the core (no server transaction involved) MUST be sent-] {+return responses+} 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-] {+different stream. This way, both sides manage+} the [-excess-] {+available streams in the sending direction, independently+} of [-traffic.-] {+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. [-This draft assumes that SRV records are the primary vehicle for such determinations. RFC3261 [2] describes the process that an entity (UAC or proxy) t