idnits 2.17.1 draft-rosenberg-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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '...n. The stream id MUST NOT be used for ...' RFC 2119 keyword, line 202: '...t streams. It is RECOMMENDED that some...' RFC 2119 keyword, line 233: '... It is RECOMMENDED to use the second...' RFC 2119 keyword, line 243: '...end a request to a particular URI MUST...' RFC 2119 keyword, line 258: '...essful SRV query SHOULD remain open af...' 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 18, 2001) is 8369 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 301 looks like a reference -- Missing reference section? '2' on line 306 looks like a reference -- Missing reference section? '3' on line 310 looks like a reference -- Missing reference section? '4' on line 314 looks like a reference -- Missing reference section? '5' on line 318 looks like a reference Summary: 5 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-rosenberg-sip-sctp-01.txt dynamicsoft,Columbia U.,Ericsson 5 May 18, 2001 6 Expires: November, 2001 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 Potential Benefits 66 Coene et. al. present some of the key benefits of SCTP [3]. We 67 summarize some of these benefits here and analyze how they relate to 68 SIP: 70 2.1 Advantages over UDP 72 All the advantages that SCTP has over UDP regarding SIP transport are 73 also shared by TCP. Below there is a list of the general advantages 74 that a connection-oriented transport protocol such as TCP or SCTP has 75 over a connection-less transport protocol such as UDP. 77 Fast Retransmit: SCTP can quickly determine the loss of a 78 packet, as a result of its usage of SACK and a mechanism 79 which sends SACK messages faster than normal when losses 80 are detected. The result is that losses of SIP messages can 81 be detected much faster than when SIP is run over UDP 82 (detection will take at least 500ms, if not more). Note 83 that TCP SACK does exist as well, and TCP also has a fast 84 retransmit option. Over an existing connection, this 85 results in faster call setup times under conditions of 86 packet loss, which is very desirable. This is probably the 87 most significant advantage to SCTP for SIP transport. 89 Congestion Control: SCTP maintains congestion control over the 90 entire connection. For SIP, this means that the aggregate 91 rate of messages between two entities can be controlled. 92 When SIP is run over TCP, the same advantages are afforded. 93 However, when run over UDP, SIP provides less effective 94 congestion control. That is because congestion state 95 (measured in terms of the UDP retransmit interval) is 96 computed on a transaction by transaction basis, rather than 97 across all transactions. Congestion control performance is 98 thus similar to opening N parallel TCP connections, as 99 opposed to sending N messages over 1 TCP connection. 101 Transport layer fragmentation: SCTP and TCP provide transport 102 layer fragmentation. If a SIP message is larger than the 103 MTU size it is fragmented at the transport layer. When UDP 104 is used fragmentation occurs at the IP layer. IP 105 fragmentation increases the likelihood of having packet 106 losses and make it difficult (when not impossible) NAT and 107 firewall traversal. This feature will become important if 108 the size of SIP messages grows dramatically. 110 2.2 Advantages over TCP 112 We have shown the advantages of SCTP and TCP over UDP. We now analyze 113 the advantages of SCTP over TCP. 115 Head of the Line: SCTP is message based as opposed to TCP that 116 is stream based. This allows SCTP to separate different 117 signalling messages at the transport layer. TCP just 118 understands bytes. Assembling received bytes to form 119 signalling messages is performed at the application layer. 120 Therefore, TCP always delivers an ordered stream of bytes 121 to the application. On the other hand, SCTP can deliver 122 signalling messages to the application as soon as they 123 arrive (when using the unordered service). The loss of a 124 signalling message does not affect the delivery of the rest 125 of the messages. This avoids the head of line blocking 126 problem in TCP, which occurs when multiple higher layer 127 connections are multiplexed within a single TCP connection. 128 A SIP transaction can be considered an application layer 129 connection. Between proxies there are multiple transactions 130 running. The loss of a message in one transaction should 131 not adversely effect the ability of a different transaction 132 to send a message. Thus, if SIP is run between entities 133 with many transactions occurring in parallel, SCTP can 134 provide improved performance over SIP over TCP (but not SIP 135 over UDP; but SIP over UDP is not ideal from a congestion 136 control standpoint, see above). 138 Easier Parsing: Another advantage of message based protocols 139 such as SCTP and UDP over stream based protocols such as 140 TCP is that they allow easier parsing of messages at the 141 application layer. There is not need of establishing 142 boundaries (typically using Content-Length headers) between 143 different messages. However, this advantage is almost 144 negligible. 146 Multihoming: An SCTP connection can be associated with multiple 147 IP addresses on the same host. Data is always sent over one 148 of the addresses, but should it become unreachable, data 149 sent to one can migrate to a different address. This 150 improves fault tolerance; network failures making one 151 interface of the server unavailable do not prevent the 152 service from continuing to operate. SIP servers are likely 153 to have substantial fault tolerance requirements. It is 154 worth noting that because SIP is message-oriented, and not 155 stream oriented, the existing SRV procedures defined in [2] 156 can accomplish the same goal, even when SIP is run over 157 TCP. In fact, SRV records allow the "connection" to fail 158 over to a separate host. Since SIP proxies can run 159 statelessly, failover can be accomplished without data 160 synchronization between the primary and its backups. Thus, 161 the multihoming capabilities of SCTP provide marginal 162 benefits. 164 It is important to note that most of the benefits of SCTP for SIP 165 occur under loss conditions. Therefore, under a zero loss condition, 166 SCTP transport of SIP should perform on par with TCP transport. 167 Research is needed to evaluate under what loss conditions the 168 improvements in setup times and throughput will be observed. The 169 purpose of this draft is to enable such experimentation in order to 170 provide concrete data on its applicability to SIP. 172 3 Usage of SCTP 174 Usage of SCTP requires no additional headers or syntax in SIP. Below 175 we show an example of a SIP URL with a transport parameter and an 176 example of a via header. In both examples SCTP is the transport 177 protocol. 179 sip:Bob.Johnson@example.com;transport=sctp 181 Via: SIP/2.0/SCTP ws1234.example.com:5060 183 Rules for sending a request over SCTP are identical to TCP. The only 184 difference is that an SCTP sender has to choose a particular stream 185 within an association in order to send the request. 187 It is important noting that a receiver uses SIP headers such as 188 Call-ID to demultiplex requests (or responses) that belong to 189 different transactions and are received over the same STCP 190 association. The stream id MUST NOT be used for this purpose. 192 This way a receiver is not affected by the way a particular 193 sender maps transactions into streams. The receiver will 194 always be able to properly demultiplex incoming SIP traffic 195 without knowing the mapping policy of the sender. 197 3.1 Mapping of transactions into streams 199 The more efficient mapping of transactions into streams consists of 200 sending requests belonging to the same call over the same ordered 201 stream. Requests belonging to different calls will be mapped into 202 different streams. It is RECOMMENDED that some kind of stateless hash 203 be used so that requests for the same call all be mapped into the 204 same stream. 206 Note that if the number of calls handled by the SIP entity 207 is larger than the number of available streams some calls 208 would have to share the same stream. This would result in 209 the head of the line blocking problem described previously. 211 Responses are mapped in the same way - responses that belong to the 212 same call are sent over the same oreered stream. However, final 213 responses should be transmitted with the unordered flag set. This 214 prevents lost provisional responses from delaying the delivery of 215 final responses. 217 Some implementors might think that this way of mapping transactions 218 into streams is somehow complicated. It is possible to perform this 219 mapping in a much simpler way. Senders can take advantage of the 220 ordering of requests that SIP performs at the application layer. That 221 is, SIP does not send a new request until the last transaction has 222 completed. Therefore, all requests and responses can be sent with the 223 unordered flag set over any stream. Effectively, a single stream can 224 be used for all SIP traffic. This way of performing the mapping is 225 almost as effective as the one described previously and it has the 226 advantage of being simpler. 228 The scenarios where this second way of performing the 229 mapping might result in reordering of requests/responses 230 represent corner cases that do not justify the increase in 231 the complexity of the first solution. 233 It is RECOMMENDED to use the second approach because it combines 234 simplicity and efficiency. 236 4 Locating a SIP server 238 The primary issue when sending a request is determining whether the 239 next hop server supports SCTP, so that an association can be opened. 241 This draft assumes that SRV records are the primary vehicle for such 242 determinations. RFC2543bis [4] describes the process that an entity 243 (UAC or proxy) that wishes to send a request to a particular URI MUST 244 follow. 246 The format of the SRV RR as described in [5] is shown below: 248 _Service._Proto.Name TTL Class Priority weight Port Target 250 When SRV records are to be used, the service to use when querying for 251 the SRV record is "sip" and the transport protocol is "sctp". So, a 252 SIP client that wants to discover a SIP server that supports SCTP for 253 the domain example.com does a lookup of 255 _sip._sctp.example.com 257 SCTP associations that were opened by proxies as the result of a 258 successful SRV query SHOULD remain open after the transaction 259 completes. The amount of time after completion of a transaction, 260 before which the connection is closed, is configurable. 262 The rule here for SRV provides a neat way to differentiate 263 among connections between proxies, and between proxies and 264 UAs and UAs and proxies. You really only want and need long 265 lived connections between proxies. It is very likely that 266 only proxies have SRV record entries. 268 5 Conclusion 270 This draft has presented a discussion on the applicability of SCTP to 271 SIP transport, and provided an experimental mechanism for allowing 272 two SCTP-capable entities to establish and use an SCTP connection. 274 6 Author's Addresses 276 Jonathan Rosenberg 277 dynamicsoft 278 200 Executive Drive 279 Suite 120 280 West Orange, NJ 07052 281 email: jdrosen@dynamicsoft.com 283 Henning Schulzrinne 284 Columbia University 285 M/S 0401 286 1214 Amsterdam Ave. 287 New York, NY 10027-7003 288 email: schulzrinne@cs.columbia.edu 290 Gonzalo Camarillo 291 Ericsson 292 Advanced Signalling Research Lab. 293 FIN-02420 Jorvas 294 Finland 295 Phone: +358 9 299 3371 296 Fax: +358 9 299 3052 297 Email: Gonzalo.Camarillo@ericsson.com 299 7 Bibliography 301 [1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 302 Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control 303 transmission protocol," Request for Comments 2960, Internet 304 Engineering Task Force, Oct. 2000. 306 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 307 session initiation protocol," Request for Comments 2543, Internet 308 Engineering Task Force, Mar. 1999. 310 [3] L. Coene et al. , "Stream control transmission protocol 311 applicability statement," Internet Draft, Internet Engineering Task 312 Force, Apr. 2001. Work in progress. 314 [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 315 Session initiation protocol," Internet Draft, Internet Engineering 316 Task Force, Nov. 2000. Work in progress. 318 [5] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying 319 the location of services (DNS SRV)," Request for Comments 2782, 320 Internet Engineering Task Force, Feb. 2000. 322 Table of Contents 324 1 Introduction ........................................ 1 325 2 Potential Benefits .................................. 2 326 2.1 Advantages over UDP ................................. 2 327 2.2 Advantages over TCP ................................. 3 328 3 Usage of SCTP ....................................... 4 329 3.1 Mapping of transactions into streams ................ 5 330 4 Locating a SIP server ............................... 5 331 5 Conclusion .......................................... 6 332 6 Author's Addresses .................................. 6 333 7 Bibliography ........................................ 7