draft-ietf-sip-sctp-02.txt   draft-ietf-sip-sctp-03.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft J. Rosenberg Internet Draft J. Rosenberg
dynamicsoft dynamicsoft
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
G. Camarillo G. Camarillo
Ericsson Ericsson
draft-ietf-sip-sctp-02.txt draft-ietf-sip-sctp-03.txt
May 28, 2002 June 28, 2002
Expires: November, 2002 Expires: December, 2002
SCTP as a Transport for SIP The Stream Control Transmission Protocol as a
Transport for the Session Initiation Protocol
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1 Introduction ........................................ 3 1 Introduction ........................................ 3
2 Terminology ......................................... 3 2 Terminology ......................................... 3
3 Potential Benefits .................................. 3 3 Potential Benefits .................................. 3
3.1 Advantages over UDP ................................. 3 3.1 Advantages over UDP ................................. 3
3.2 Advantages over TCP ................................. 4 3.2 Advantages over TCP ................................. 4
4 Usage of SCTP ....................................... 5 4 Usage of SCTP ....................................... 5
4.1 Mapping of SIP Transactions into Streams ............ 6 4.1 Mapping of SIP Transactions into Streams ............ 6
4.1.1 Client Side ......................................... 7 5 Locating a SIP server ............................... 7
4.1.2 Server Side ......................................... 8 6 Security Considerations ............................. 7
4.1.3 Size of the stream ID space ......................... 9 7 Conclusion .......................................... 7
5 Locating a SIP server ............................... 10 8 Author's Addresses .................................. 7
6 Conclusion .......................................... 10 9 Normative References ................................ 8
7 Author's Addresses .................................. 10 10 Informative References .............................. 8
8 Normative References ................................ 11
9 Informative References .............................. 11
1 Introduction 1 Introduction
The Stream Control Transmission Protocol (SCTP) [1] has been designed The Stream Control Transmission Protocol (SCTP) [1] has been designed
as a new transport protocol for the Internet (or intranets), at the 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 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 legacy SS7 signaling messages in mind. We have observed that many
of the features designed to support transport of such signaling are of the features designed to support transport of such signaling are
also useful for the transport of SIP (the Session Initiation also useful for the transport of SIP (the Session Initiation
Protocol) [2], which is used to initiate and manage interactive Protocol) [2], which is used to initiate and manage interactive
skipping to change at page 3, line 32 skipping to change at page 3, line 32
Note that this is not a proposal that SCTP be adopted as the primary Note that this is not a proposal that SCTP be adopted as the primary
or preferred transport for SIP; substantial evaluation of SCTP, or preferred transport for SIP; substantial evaluation of SCTP,
deployment, and experimentation can take place before that happens. deployment, and experimentation can take place before that happens.
This draft is targeted at encouraging such experimentation by This draft is targeted at encouraging such experimentation by
enabling it in SIP. enabling it in SIP.
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [3].
3 Potential Benefits 3 Potential Benefits
Coene et. al. present some of the key benefits of SCTP [4]. We 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 summarize some of these benefits here and analyze how they relate to
SIP: SIP:
3.1 Advantages over UDP 3.1 Advantages over UDP
All the advantages that SCTP has over UDP regarding SIP transport are All the advantages that SCTP has over UDP regarding SIP transport are
skipping to change at page 5, line 49 skipping to change at page 5, line 49
SCTP transport of SIP should perform on par with TCP transport. SCTP transport of SIP should perform on par with TCP transport.
Research is needed to evaluate under what loss conditions the Research is needed to evaluate under what loss conditions the
improvements in setup times and throughput will be observed. The improvements in setup times and throughput will be observed. The
purpose of this draft is to enable such experimentation in order to purpose of this draft is to enable such experimentation in order to
provide concrete data on its applicability to SIP. provide concrete data on its applicability to SIP.
4 Usage of SCTP 4 Usage of SCTP
Usage of SCTP requires no additional headers or syntax in SIP. Below 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 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 example of a via header field. In both examples SCTP is the transport
protocol. protocol.
sip:Bob.Johnson@example.com;transport=sctp sip:Bob.Johnson@example.com;transport=sctp
Via: SIP/2.0/SCTP ws1234.example.com:5060 Via: SIP/2.0/SCTP ws1234.example.com:5060
Rules for sending a request over SCTP are identical to TCP. The only 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 difference is that an SCTP sender has to choose a particular stream
within an association in order to send the request. 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. Note that no SCTP identifier needs to be defined for SIP messages.
Therefore, the Payload Protocol Indentifier in SCTP DATA chunks Therefore, the Payload Protocol Indentifier in SCTP DATA chunks
transporting SIP messages MUST be set to zero. transporting SIP messages MUST be set to zero.
The SIP transport layers of both peers are responsible to manage the The SIP transport layers of both peers are responsible to manage the
persistent SCTP connection between them. On the sender side the core persistent SCTP connection between them. On the sender side the core
or a client (or server) transaction generates a request (or response) or a client (or server) transaction generates a request (or response)
and passes it to the transport layer. The transport sends the request and passes it to the transport layer. The transport sends the request
to the peer's transaction layer. The peer's transaction layer is to the peer's transaction layer. The peer's transaction layer is
responsible of delivering the incoming request (or response) to the responsible of delivering the incoming request (or response) to the
proper existing server (or client) transaction. If no server (or proper existing server (or client) transaction. If no server (or
client) transaction exists for the incoming message the transport client) transaction exists for the incoming message the transport
layer passes the request (or response) to the core, which may decide layer passes the request (or response) to the core, which may decide
to construct a new server (or client) transaction. 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 4.1 Mapping of SIP Transactions into Streams
A SIP entity needs to relate incoming SIP messages to existing client SIP transactions need to be mapped into SCTP streams in a way that
and server transactions. On the client side incoming responses need avoids Head Of the Line (HOL) blocking. Among all the different ways
to be delivered to the client transaction that generated the request. of performing this mapping that fulfill this requirement, we have
On the server side: chosen the simplest one; a SIP entity SHOULD send every SIP message
(request or response) over stream zero with the unordered flag set.
1. ACKs for non-2xx final responses need to be delivered to On the receiving side, a SIP entity MUST be ready to receive SIP
the INVITE server transaction that generated the response. messages over any stream.
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
(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.
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 Note that previous versions of this document proposed to
stream 2**16-1 cannot be used as transaction identifiers there are use SCTP stream IDs as lightweight SIP transaction
2**15-1 = 32767 available stream IDs. A SIP proxy handling 333 identifiers. That proposal has been withdrawn because SIP
requests per second (1.2 million Busy Hour Call attempts) would only now provides a transaction identifier in the branch
run out of stream IDs if it only handled INVITE transactions and if parameter of the Via entries. This transaction identifier,
every transaction lasted more than 98 seconds (INVITE transactions missing in the previous SIP spec [5], makes it unnecessary
typically last much less than that). Non-INVITE transactions to use the SCTP stream IDs to demultiplex SIP traffic.
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 Some applications introduce an extra layer between the transport
for proxies handling heavy traffic loads. And even if a proxy did layer and SIP (e.g., compression and/or encryption). This extra layer
eventually run out of stream IDs, stream zero is always available for sometimes requires ordered delivery of messages from the transport
the excess of traffic. layer (e.g., TLS [6]). 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 5 Locating a SIP server
The primary issue when sending a request is determining whether the The primary issue when sending a request is determining whether the
next hop server supports SCTP, so that an association can be opened. next hop server supports SCTP, so that an association can be opened.
This draft assumes that SRV records are the primary vehicle for such SIP entities follow normal SIP procedures to discover [7] a server
determinations. RFC3261 [2] describes the process that an entity (UAC that supports SCTP.
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 6 Security Considerations
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 No extra security risk outside these specified by [2] are foreseen.
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 7 Conclusion
This draft has presented a discussion on the applicability of SCTP to This draft has presented a discussion on the applicability of SCTP to
SIP transport, and provided an experimental mechanism for allowing SIP transport, and provided a mechanism for allowing two SCTP-capable
two SCTP-capable entities to establish and use an SCTP connection. entities to use an SCTP association to exchange SIP traffic.
7 Author's Addresses 8 Author's Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
200 Executive Drive 200 Executive Drive
Suite 120 Suite 120
West Orange, NJ 07052 West Orange, NJ 07052
email: jdrosen@dynamicsoft.com email: jdrosen@dynamicsoft.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
skipping to change at page 11, line 22 skipping to change at page 8, line 8
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Advanced Signalling Research Lab.
FIN-02420 Jorvas FIN-02420 Jorvas
Finland Finland
Phone: +358 9 299 3371 Phone: +358 9 299 3371
Fax: +358 9 299 3052 Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
8 Normative References 9 Normative References
[1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. [1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T.
Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control
transmission protocol," RFC 2960, Internet Engineering Task Force, transmission protocol," RFC 2960, Internet Engineering Task Force,
Oct. 2000. Oct. 2000.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation [2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb. protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress. 2002. Work in progress.
[3] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying [3] S. Bradner, "Key words for use in RFCs to indicate requirement
the location of services (DNS SRV)," RFC 2782, Internet Engineering levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
Task Force, Feb. 2000.
9 Informative References 10 Informative References
[4] L. Coene, "Stream control transmission protocol applicability [4] L. Coene, "Stream control transmission protocol applicability
statement," RFC 3257, Internet Engineering Task Force, Apr. 2002. statement," RFC 3257, Internet Engineering Task Force, Apr. 2002.
[5] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," RFC 2543, Internet Engineering Task
Force, Mar. 1999.
[6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246,
Internet Engineering Task Force, Jan. 1999.
[7] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers,"
Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in
progress.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/