idnits 2.17.1 draft-ietf-sip-sctp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 28, 2002) is 8003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2960 (ref. '1') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 H. Schulzrinne 6 Columbia U. 7 G. Camarillo 8 Ericsson 9 draft-ietf-sip-sctp-02.txt 10 May 28, 2002 11 Expires: November, 2002 13 SCTP as a Transport for SIP 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies a mechanism for usage of SCTP (the Stream 39 Control Transmission Protocol) as the transport between SIP entities. 40 SCTP is a new protocol which provides several features that may prove 41 beneficial for transport between SIP entities which exchange a large 42 amount of messages, including gateways and proxies. As SIP is 43 transport independent, support of SCTP is a relatively 44 straightforward process, nearly identical to support for TCP. 46 Table of Contents 48 1 Introduction ........................................ 3 49 2 Terminology ......................................... 3 50 3 Potential Benefits .................................. 3 51 3.1 Advantages over UDP ................................. 3 52 3.2 Advantages over TCP ................................. 4 53 4 Usage of SCTP ....................................... 5 54 4.1 Mapping of SIP Transactions into Streams ............ 6 55 4.1.1 Client Side ......................................... 7 56 4.1.2 Server Side ......................................... 8 57 4.1.3 Size of the stream ID space ......................... 9 58 5 Locating a SIP server ............................... 10 59 6 Conclusion .......................................... 10 60 7 Author's Addresses .................................. 10 61 8 Normative References ................................ 11 62 9 Informative References .............................. 11 64 1 Introduction 66 The Stream Control Transmission Protocol (SCTP) [1] has been designed 67 as a new transport protocol for the Internet (or intranets), at the 68 same layer as TCP and UDP. SCTP has been designed with the transport 69 of legacy SS7 signaling messages in mind. We have observed that many 70 of the features designed to support transport of such signaling are 71 also useful for the transport of SIP (the Session Initiation 72 Protocol) [2], which is used to initiate and manage interactive 73 sessions on the Internet. 75 SIP itself is transport-independent, and can run over any reliable or 76 unreliable message or stream transport. However, procedures are only 77 defined for transport over UDP and TCP. In order to encourage 78 experimentation and evaluation of the appropriateness of SCTP for SIP 79 transport, this document defines transport of SIP over SCTP. 81 Note that this is not a proposal that SCTP be adopted as the primary 82 or preferred transport for SIP; substantial evaluation of SCTP, 83 deployment, and experimentation can take place before that happens. 84 This draft is targeted at encouraging such experimentation by 85 enabling it in SIP. 87 2 Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119. 93 3 Potential Benefits 95 Coene et. al. present some of the key benefits of SCTP [4]. We 96 summarize some of these benefits here and analyze how they relate to 97 SIP: 99 3.1 Advantages over UDP 101 All the advantages that SCTP has over UDP regarding SIP transport are 102 also shared by TCP. Below there is a list of the general advantages 103 that a connection-oriented transport protocol such as TCP or SCTP has 104 over a connection-less transport protocol such as UDP. 106 Fast Retransmit: SCTP can quickly determine the loss of a 107 packet, as a result of its usage of SACK and a mechanism 108 which sends SACK messages faster than normal when losses 109 are detected. The result is that losses of SIP messages can 110 be detected much faster than when SIP is run over UDP 111 (detection will take at least 500ms, if not more). Note 112 that TCP SACK does exist as well, and TCP also has a fast 113 retransmit option. Over an existing connection, this 114 results in faster call setup times under conditions of 115 packet loss, which is very desirable. This is probably the 116 most significant advantage to SCTP for SIP transport. 118 Congestion Control: SCTP maintains congestion control over the 119 entire association. For SIP, this means that the aggregate 120 rate of messages between two entities can be controlled. 121 When SIP is run over TCP, the same advantages are afforded. 122 However, when run over UDP, SIP provides less effective 123 congestion control. That is because congestion state 124 (measured in terms of the UDP retransmit interval) is 125 computed on a transaction by transaction basis, rather than 126 across all transactions. Congestion control performance is 127 thus similar to opening N parallel TCP connections, as 128 opposed to sending N messages over 1 TCP connection. 130 Transport layer fragmentation: SCTP and TCP provide transport 131 layer fragmentation. If a SIP message is larger than the 132 MTU size it is fragmented at the transport layer. When UDP 133 is used fragmentation occurs at the IP layer. IP 134 fragmentation increases the likelihood of having packet 135 losses and make it difficult (when not impossible) NAT and 136 firewall traversal. This feature will become important if 137 the size of SIP messages grows dramatically. 139 3.2 Advantages over TCP 141 We have shown the advantages of SCTP and TCP over UDP. We now analyze 142 the advantages of SCTP over TCP. 144 Head of the Line: SCTP is message based as opposed to TCP that 145 is stream based. This allows SCTP to separate different 146 signalling messages at the transport layer. TCP just 147 understands bytes. Assembling received bytes to form 148 signalling messages is performed at the application layer. 149 Therefore, TCP always delivers an ordered stream of bytes 150 to the application. On the other hand, SCTP can deliver 151 signalling messages to the application as soon as they 152 arrive (when using the unordered service). The loss of a 153 signalling message does not affect the delivery of the rest 154 of the messages. This avoids the head of line blocking 155 problem in TCP, which occurs when multiple higher layer 156 connections are multiplexed within a single TCP connection. 157 A SIP transaction can be considered an application layer 158 connection. Between proxies there are multiple transactions 159 running. The loss of a message in one transaction should 160 not adversely effect the ability of a different transaction 161 to send a message. Thus, if SIP is run between entities 162 with many transactions occurring in parallel, SCTP can 163 provide improved performance over SIP over TCP (but not SIP 164 over UDP; but SIP over UDP is not ideal from a congestion 165 control standpoint, see above). 167 Easier Parsing: Another advantage of message based protocols 168 such as SCTP and UDP over stream based protocols such as 169 TCP is that they allow easier parsing of messages at the 170 application layer. There is not need of establishing 171 boundaries (typically using Content-Length headers) between 172 different messages. However, this advantage is almost 173 negligible. 175 Multihoming: An SCTP connection can be associated with multiple 176 IP addresses on the same host. Data is always sent over one 177 of the addresses, but should it become unreachable, data 178 sent to one can migrate to a different address. This 179 improves fault tolerance; network failures making one 180 interface of the server unavailable do not prevent the 181 service from continuing to operate. SIP servers are likely 182 to have substantial fault tolerance requirements. It is 183 worth noting that because SIP is message-oriented, and not 184 stream oriented, the existing SRV procedures defined in [2] 185 can accomplish the same goal, even when SIP is run over 186 TCP. In fact, SRV records allow the "connection" to fail 187 over to a separate host. Since SIP proxies can run 188 statelessly, failover can be accomplished without data 189 synchronization between the primary and its backups. Thus, 190 the multihoming capabilities of SCTP provide marginal 191 benefits. 193 It is important to note that most of the benefits of SCTP for SIP 194 occur under loss conditions. Therefore, under a zero loss condition, 195 SCTP transport of SIP should perform on par with TCP transport. 196 Research is needed to evaluate under what loss conditions the 197 improvements in setup times and throughput will be observed. The 198 purpose of this draft is to enable such experimentation in order to 199 provide concrete data on its applicability to SIP. 201 4 Usage of SCTP 203 Usage of SCTP requires no additional headers or syntax in SIP. Below 204 we show an example of a SIP URL with a transport parameter and an 205 example of a via header. In both examples SCTP is the transport 206 protocol. 208 sip:Bob.Johnson@example.com;transport=sctp 210 Via: SIP/2.0/SCTP ws1234.example.com:5060 212 Rules for sending a request over SCTP are identical to TCP. The only 213 difference is that an SCTP sender has to choose a particular stream 214 within an association in order to send the request. 216 Note that no SCTP identifier needs to be defined for SIP messages. 217 Therefore, the Payload Protocol Indentifier in SCTP DATA chunks 218 transporting SIP messages MUST be set to zero. 220 The SIP transport layers of both peers are responsible to manage the 221 persistent SCTP connection between them. On the sender side the core 222 or a client (or server) transaction generates a request (or response) 223 and passes it to the transport layer. The transport sends the request 224 to the peer's transaction layer. The peer's transaction layer is 225 responsible of delivering the incoming request (or response) to the 226 proper existing server (or client) transaction. If no server (or 227 client) transaction exists for the incoming message the transport 228 layer passes the request (or response) to the core, which may decide 229 to construct a new server (or client) transaction. 231 The mapping of SIP transactions into SCTP stream IDs serves two 232 purposes: 234 1. Avoid Head Of the Line (HOL) blocking 236 2. Provide a lightweight mechanism to perform transaction 237 identification. This allows an efficient delivery of 238 incoming SIP messages from the SIP transport layer to the 239 client or server transaction the message belongs to. 241 The former is REQUIRED whereas the latter is RECOMMENDED. This 242 document describes how to achieve both goals. 244 We believe that using stream IDs to demultiplex incoming 245 traffic is a useful mechanism to implement highly efficient 246 SIP proxies and gateways. However, we too believe that it 247 is essential that a SIP entity that is not stream ID aware 248 can interoperate with any other implementation. That is why 249 this feature is optional, and so, the second bullet is 250 RECOMMENDED and not REQUIRED. 252 4.1 Mapping of SIP Transactions into Streams 254 A SIP entity needs to relate incoming SIP messages to existing client 255 and server transactions. On the client side incoming responses need 256 to be delivered to the client transaction that generated the request. 257 On the server side: 259 1. ACKs for non-2xx final responses need to be delivered to 260 the INVITE server transaction that generated the response. 262 2. The core needs to relate incoming CANCEL requests to 263 existing server transactions. 265 Note that retransmissions of a request are never received over a 266 reliable transport such as SCTP. 268 In order to match a particular SIP message with an existing client or 269 server transaction it is necessary to compute the transaction 270 identifier of the message. The transaction identifier consists of the 271 To, From, Call-ID, Cseq and topmost Via header fields. The use of 272 SCTP stream IDs as lightweight transaction identifiers saves parsing 273 these headers every time a new SIP message arrives. 275 If a SIP entity chooses not to use SCTP stream IDs as lightweight 276 transaction identifiers it MUST send every request and every response 277 it generates using the SCTP stream ID zero with the "unordered" flag 278 set. 280 A SIP entity that decides to use stream IDs to identify particular 281 transactions MUST follow the rules described below (Sections 4.1.1 282 and 4.1.2). 284 4.1.1 Client Side 286 The decision of whether or not to use the SCTP stream ID to 287 demultiplex incoming traffic is made on a transaction basis by the 288 client's transport layer. If the transaction layer intends to perform 289 SIP traffic demultiplexing based on stream IDs for the current 290 transaction it MUST follow the rules below. If the transaction layer 291 does not intend to use stream IDs for that purpose for this 292 particular transaction it MUST send the request using the SCTP stream 293 ID zero with the "unordered" flag set. 295 A transport layer receiving a request from the core (as opposed to 296 from a client transaction layer) MUST send the request using the SCTP 297 stream ID zero with the "unordered" flag set. 299 A transport layer performing demultiplexing based on stream IDs MUST 300 use an uneven stream ID to send the any request but CANCEL. CANCEL 301 requests MUST be sent over the stream ID that the request to be 302 cancelled was sent plus one (e.g., an INVITE over stream 1 and its 303 CANCEL over stream 2). This rule implies that the highest stream ID 304 (2**16-1) MUST NOT be used to send SIP traffic. 306 A transport layer sending a request over a stream ID different than 307 zero MUST be able to relate the stream ID used to send the request 308 with the client transaction that generated the request. This MAY be 309 done by implementing an indexed table that relates stream IDs with 310 client transactions. Responses arriving over this particular stream 311 ID MUST be delivered to the client transaction that generated the 312 request. 314 Requests sent over a stream different than zero MUST NOT have the 315 "unordered" flag set. 317 A particular stream ID different than zero MUST NOT be used by more 318 than one client transaction at a time. Note, however, that a 319 particular stream ID MAY be used at the same time by a client 320 transaction and by a server transaction. 322 The transaction layer is able to distinguish requests from 323 responses and thus it is able to decide whether to deliver 324 the incoming SIP message to the client or to the server 325 transaction. 327 Effectively, a particular stream ID can be reused by a new client 328 transaction once the client transaction currently related to it 329 terminates. If an indexed table is used, the entry corresponding to 330 this transaction is removed at this point of time. 332 ACKs are a special case. ACK requests for non-2xx responses to an 333 INVITE are generated by the client transaction. They MUST be sent 334 over the same stream ID as the INVITE was sent. ACK requests for 2xx 335 responses for the INVITE are generated by the Transaction User. As 336 previously stated, every request generated by the core is sent over 337 stream ID zero with the "unordered" flag set. 339 4.1.2 Server Side 341 The decision of whether or not to use the SCTP stream ID to 342 demultiplex incoming traffic is made on a transaction basis by the 343 server's transport layer. If the transaction layer intends to perform 344 SIP traffic demultiplexing based on stream IDs for the current 345 transaction it MUST follow the rules below. If the transaction layer 346 does not intend to use stream IDs for that purpose for this 347 particular transaction it MUST send all responses it generates for 348 this transaction over stream zero with the "unordered" flag set. 350 If a transport layer chooses to demultiplex traffic based on stream 351 IDs it MUST be able to relate stream IDs with server transactions. 353 This MAY be implemented using an indexed table. When a new request 354 arrives over a stream different than zero, if the stream ID is 355 related to an existing server transaction the request MUST be passed 356 to that server transaction. If the stream ID is not related to any 357 server transaction the request is passed to the core. The SIP 358 transport layer MUST inform the core about the stream ID the request 359 was received over. If the core decides to create a server transaction 360 for the request, it MUST inform the transport layer about the server 361 transaction that corresponds to that particular stream ID. 363 If an indexed table is used an entry relating the stream ID 364 with the newly created server transaction is added. 366 When a server transaction passes a response to the SIP transport 367 layer this response MUST be sent over the stream ID corresponding to 368 this transaction. Responses passed to the transport layer directly 369 from the core (no server transaction involved) MUST be sent over 370 stream ID zero. 372 Once a server transaction terminates the bundling between this sever 373 transaction and the stream ID is terminated as well. 375 If case an indexed table is implemented, the entry for this 376 server transaction is removed. 378 Regardless of the stream ID used, the SIP transport layer MUST send 379 every response with the "unordered" flag set. 381 This avoids that a loss in a provisional response affects 382 the delivery of a final response within a particular 383 transaction. 385 4.1.3 Size of the stream ID space 387 The SCTP stream identifier is a 16-bit field. Since stream zero and 388 stream 2**16-1 cannot be used as transaction identifiers there are 389 2**15-1 = 32767 available stream IDs. A SIP proxy handling 333 390 requests per second (1.2 million Busy Hour Call attempts) would only 391 run out of stream IDs if it only handled INVITE transactions and if 392 every transaction lasted more than 98 seconds (INVITE transactions 393 typically last much less than that). Non-INVITE transactions 394 typically last less than INVITE transactions (16 seconds maximum 395 using default timers), so a proxy can handle a larger number of non- 396 INVITE transactions. 398 This calculations show that the stream ID space is large enough even 399 for proxies handling heavy traffic loads. And even if a proxy did 400 eventually run out of stream IDs, stream zero is always available for 401 the excess of traffic. 403 5 Locating a SIP server 405 The primary issue when sending a request is determining whether the 406 next hop server supports SCTP, so that an association can be opened. 407 This draft assumes that SRV records are the primary vehicle for such 408 determinations. RFC3261 [2] describes the process that an entity (UAC 409 or proxy) that wishes to send a request to a particular URI MUST 410 follow. 412 The format of the SRV RR as described in [3] is shown below: 414 _Service._Proto.Name TTL Class Priority weight Port Target 416 When SRV records are to be used, the service to use when querying for 417 the SRV record is "sip" and the transport protocol is "sctp". So, a 418 SIP client that wants to discover a SIP server that supports SCTP for 419 the domain example.com does a lookup of 421 _sip._sctp.example.com 423 SCTP associations that were opened by proxies as the result of a 424 successful SRV query SHOULD remain open after the transaction 425 completes. The amount of time after completion of a transaction, 426 before which the connection is closed, is configurable. 428 The rule here for SRV provides a neat way to differentiate 429 among connections between proxies, and between proxies and 430 UAs and UAs and proxies. You really only want and need long 431 lived connections between proxies. It is very likely that 432 only proxies have SRV record entries. 434 6 Conclusion 436 This draft has presented a discussion on the applicability of SCTP to 437 SIP transport, and provided an experimental mechanism for allowing 438 two SCTP-capable entities to establish and use an SCTP connection. 440 7 Author's Addresses 442 Jonathan Rosenberg 443 dynamicsoft 444 200 Executive Drive 445 Suite 120 446 West Orange, NJ 07052 447 email: jdrosen@dynamicsoft.com 449 Henning Schulzrinne 450 Columbia University 451 M/S 0401 452 1214 Amsterdam Ave. 453 New York, NY 10027-7003 454 email: schulzrinne@cs.columbia.edu 456 Gonzalo Camarillo 457 Ericsson 458 Advanced Signalling Research Lab. 459 FIN-02420 Jorvas 460 Finland 461 Phone: +358 9 299 3371 462 Fax: +358 9 299 3052 463 Email: Gonzalo.Camarillo@ericsson.com 465 8 Normative References 467 [1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 468 Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control 469 transmission protocol," RFC 2960, Internet Engineering Task Force, 470 Oct. 2000. 472 [2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 473 protocol," Internet Draft, Internet Engineering Task Force, Feb. 474 2002. Work in progress. 476 [3] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying 477 the location of services (DNS SRV)," RFC 2782, Internet Engineering 478 Task Force, Feb. 2000. 480 9 Informative References 482 [4] L. Coene, "Stream control transmission protocol applicability 483 statement," RFC 3257, Internet Engineering Task Force, Apr. 2002.