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