draft-ietf-sip-sctp-00.txt   draft-ietf-sip-sctp-01.txt 
Internet Engineering Task Force SIP WG Internet Engineering Task Force SIP WG
Internet Draft Rosenberg/Schulzrinne/Camarillo Internet Draft Rosenberg/Schulzrinne/Camarillo
draft-ietf-sip-sctp-00.txt dynamicsoft,Columbia U.,Ericsson draft-ietf-sip-sctp-01.txt dynamicsoft,Columbia U.,Ericsson
August 14, 2001 November 20, 2001
Expires: February, 2002 Expires: May, 2002
SCTP as a Transport for SIP SCTP as a Transport for SIP
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
skipping to change at page 3, line 6 skipping to change at page 3, line 6
are detected. The result is that losses of SIP messages can are detected. The result is that losses of SIP messages can
be detected much faster than when SIP is run over UDP be detected much faster than when SIP is run over UDP
(detection will take at least 500ms, if not more). Note (detection will take at least 500ms, if not more). Note
that TCP SACK does exist as well, and TCP also has a fast that TCP SACK does exist as well, and TCP also has a fast
retransmit option. Over an existing connection, this retransmit option. Over an existing connection, this
results in faster call setup times under conditions of results in faster call setup times under conditions of
packet loss, which is very desirable. This is probably the packet loss, which is very desirable. This is probably the
most significant advantage to SCTP for SIP transport. most significant advantage to SCTP for SIP transport.
Congestion Control: SCTP maintains congestion control over the Congestion Control: SCTP maintains congestion control over the
entire connection. For SIP, this means that the aggregate entire association. For SIP, this means that the aggregate
rate of messages between two entities can be controlled. rate of messages between two entities can be controlled.
When SIP is run over TCP, the same advantages are afforded. When SIP is run over TCP, the same advantages are afforded.
However, when run over UDP, SIP provides less effective However, when run over UDP, SIP provides less effective
congestion control. That is because congestion state congestion control. That is because congestion state
(measured in terms of the UDP retransmit interval) is (measured in terms of the UDP retransmit interval) is
computed on a transaction by transaction basis, rather than computed on a transaction by transaction basis, rather than
across all transactions. Congestion control performance is across all transactions. Congestion control performance is
thus similar to opening N parallel TCP connections, as thus similar to opening N parallel TCP connections, as
opposed to sending N messages over 1 TCP connection. opposed to sending N messages over 1 TCP connection.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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.
It is important noting that a receiver uses SIP headers such as Note that no SCTP identifier needs to be defined for SIP messages.
Call-ID to demultiplex requests (or responses) that belong to
different transactions and are received over the same STCP
association. The stream id MUST NOT be used for this purpose.
This way a receiver is not affected by the way a particular
sender maps transactions into streams. The receiver will
always be able to properly demultiplex incoming SIP traffic
without knowing the mapping policy of the sender.
Note that no SCTP identifier needs to 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.
4.1 Mapping of transactions into streams 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 more efficient mapping of transactions into streams consists of The mapping of SIP transactions into SCTP stream IDs serves two
sending requests belonging to the same call over the same ordered purposes:
stream. Requests belonging to different calls will be mapped into
different streams. It is RECOMMENDED that some kind of stateless hash
be used so that requests for the same call all be mapped into the
same stream.
Note that if the number of calls handled by the SIP entity 1. Avoid Head Of the Line (HOL) blocking
is larger than the number of available streams some calls
would have to share the same stream. This would result in
the head of the line blocking problem described previously.
Responses are mapped in the same way - responses that belong to the 2. Provide a lightweight mechanism to perform transaction
same call are sent over the same ordered stream. However, final identification. This allows an efficient delivery of
responses should be transmitted with the unordered flag set. This incoming SIP messages from the SIP transport layer to the
prevents lost provisional responses from delaying the delivery of client or server transaction the message belongs to.
final responses.
Some implementors might think that this way of mapping transactions The former is REQUIRED whereas the latter is RECOMMENDED. This
into streams is somehow complicated. It is possible to perform this document describes how to achieve both goals.
mapping in a much simpler way. Senders can take advantage of the
ordering of requests that SIP performs at the application layer. That
is, SIP does not send a new request until the last transaction has
completed (or at least until a SIP response has arrived from the
remote side). Therefore, all requests and responses can be sent with
the unordered flag set over any stream. Effectively, a single stream
can be used for all SIP traffic. This way of performing the mapping
is almost as effective as the one described previously and it has the
advantage of being simpler.
The scenarios where this second way of performing the We believe that using stream IDs to demultiplex incoming
mapping might result in reordering of requests/responses traffic is a useful mechanism to implement highly efficient
represent corner cases that do not justify the increase in SIP proxies and gateways. However, we too believe that it
the complexity of the first solution. 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.
It is RECOMMENDED to use the second approach because it combines 4.1 Mapping of SIP Transactions into Streams
simplicity and efficiency.
A SIP entity needs to relate incoming SIP messages to existing client
and server transactions. On the client side incoming responses need
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
(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
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
the excess of traffic.
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 This draft assumes that SRV records are the primary vehicle for such
determinations. RFC2543bis [4] describes the process that an entity determinations. RFC2543bis [4] describes the process that an entity
(UAC or proxy) that wishes to send a request to a particular URI MUST (UAC or proxy) that wishes to send a request to a particular URI MUST
follow. follow.
skipping to change at page 7, line 40 skipping to change at page 10, line 26
Engineering Task Force, Oct. 2000. Engineering Task Force, Oct. 2000.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999. Engineering Task Force, Mar. 1999.
[3] L. Coene et al. , "Stream control transmission protocol [3] L. Coene et al. , "Stream control transmission protocol
applicability statement," Internet Draft, Internet Engineering Task applicability statement," Internet Draft, Internet Engineering Task
Force, Apr. 2001. Work in progress. Force, Apr. 2001. Work in progress.
[4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: [4] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
Session initiation protocol," Internet Draft, Internet Engineering protocol," Internet Draft, Internet Engineering Task Force, Oct.
Task Force, Nov. 2000. Work in progress. 2001. Work in progress.
[5] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying [5] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)," Request for Comments 2782, the location of services (DNS SRV)," Request for Comments 2782,
Internet Engineering Task Force, Feb. 2000. Internet Engineering Task Force, Feb. 2000.
Table of Contents Table of Contents
1 Introduction ........................................ 1 1 Introduction ........................................ 1
2 Terminology ......................................... 2 2 Terminology ......................................... 2
3 Potential Benefits .................................. 2 3 Potential Benefits .................................. 2
3.1 Advantages over UDP ................................. 2 3.1 Advantages over UDP ................................. 2
3.2 Advantages over TCP ................................. 3 3.2 Advantages over TCP ................................. 3
4 Usage of SCTP ....................................... 4 4 Usage of SCTP ....................................... 4
4.1 Mapping of transactions into streams ................ 5 4.1 Mapping of SIP Transactions into Streams ............ 5
5 Locating a SIP server ............................... 6 4.1.1 Client Side ......................................... 6
6 Conclusion .......................................... 6 4.1.2 Server Side ......................................... 7
7 Author's Addresses .................................. 6 4.1.3 Size of the stream ID space ......................... 8
8 Bibliography ........................................ 7 5 Locating a SIP server ............................... 8
6 Conclusion .......................................... 9
7 Author's Addresses .................................. 9
8 Bibliography ........................................ 10
 End of changes. 

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