idnits 2.17.1 draft-ietf-sip-sctp-00.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 (August 14, 2001) is 8262 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 311 looks like a reference -- Missing reference section? '2' on line 316 looks like a reference -- Missing reference section? '3' on line 320 looks like a reference -- Missing reference section? '4' on line 324 looks like a reference -- Missing reference section? '5' on line 328 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-00.txt dynamicsoft,Columbia U.,Ericsson 5 August 14, 2001 6 Expires: February, 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 connection. 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 It is important noting that a receiver uses SIP headers such as 194 Call-ID to demultiplex requests (or responses) that belong to 195 different transactions and are received over the same STCP 196 association. The stream id MUST NOT be used for this purpose. 198 This way a receiver is not affected by the way a particular 199 sender maps transactions into streams. The receiver will 200 always be able to properly demultiplex incoming SIP traffic 201 without knowing the mapping policy of the sender. 203 Note that no SCTP identifier needs to defined for SIP messages. 204 Therefore, the Payload Protocol Indentifier in SCTP DATA chunks 205 transporting SIP messages MUST be set to zero. 207 4.1 Mapping of transactions into streams 209 The more efficient mapping of transactions into streams consists of 210 sending requests belonging to the same call over the same ordered 211 stream. Requests belonging to different calls will be mapped into 212 different streams. It is RECOMMENDED that some kind of stateless hash 213 be used so that requests for the same call all be mapped into the 214 same stream. 216 Note that if the number of calls handled by the SIP entity 217 is larger than the number of available streams some calls 218 would have to share the same stream. This would result in 219 the head of the line blocking problem described previously. 221 Responses are mapped in the same way - responses that belong to the 222 same call are sent over the same ordered stream. However, final 223 responses should be transmitted with the unordered flag set. This 224 prevents lost provisional responses from delaying the delivery of 225 final responses. 227 Some implementors might think that this way of mapping transactions 228 into streams is somehow complicated. It is possible to perform this 229 mapping in a much simpler way. Senders can take advantage of the 230 ordering of requests that SIP performs at the application layer. That 231 is, SIP does not send a new request until the last transaction has 232 completed (or at least until a SIP response has arrived from the 233 remote side). Therefore, all requests and responses can be sent with 234 the unordered flag set over any stream. Effectively, a single stream 235 can be used for all SIP traffic. This way of performing the mapping 236 is almost as effective as the one described previously and it has the 237 advantage of being simpler. 239 The scenarios where this second way of performing the 240 mapping might result in reordering of requests/responses 241 represent corner cases that do not justify the increase in 242 the complexity of the first solution. 244 It is RECOMMENDED to use the second approach because it combines 245 simplicity and efficiency. 247 5 Locating a SIP server 249 The primary issue when sending a request is determining whether the 250 next hop server supports SCTP, so that an association can be opened. 251 This draft assumes that SRV records are the primary vehicle for such 252 determinations. RFC2543bis [4] describes the process that an entity 253 (UAC or proxy) that wishes to send a request to a particular URI MUST 254 follow. 256 The format of the SRV RR as described in [5] is shown below: 258 _Service._Proto.Name TTL Class Priority weight Port Target 260 When SRV records are to be used, the service to use when querying for 261 the SRV record is "sip" and the transport protocol is "sctp". So, a 262 SIP client that wants to discover a SIP server that supports SCTP for 263 the domain example.com does a lookup of 265 _sip._sctp.example.com 267 SCTP associations that were opened by proxies as the result of a 268 successful SRV query SHOULD remain open after the transaction 269 completes. The amount of time after completion of a transaction, 270 before which the connection is closed, is configurable. 272 The rule here for SRV provides a neat way to differentiate 273 among connections between proxies, and between proxies and 274 UAs and UAs and proxies. You really only want and need long 275 lived connections between proxies. It is very likely that 276 only proxies have SRV record entries. 278 6 Conclusion 280 This draft has presented a discussion on the applicability of SCTP to 281 SIP transport, and provided an experimental mechanism for allowing 282 two SCTP-capable entities to establish and use an SCTP connection. 284 7 Author's Addresses 286 Jonathan Rosenberg 287 dynamicsoft 288 200 Executive Drive 289 Suite 120 290 West Orange, NJ 07052 291 email: jdrosen@dynamicsoft.com 293 Henning Schulzrinne 294 Columbia University 295 M/S 0401 296 1214 Amsterdam Ave. 297 New York, NY 10027-7003 298 email: schulzrinne@cs.columbia.edu 300 Gonzalo Camarillo 301 Ericsson 302 Advanced Signalling Research Lab. 303 FIN-02420 Jorvas 304 Finland 305 Phone: +358 9 299 3371 306 Fax: +358 9 299 3052 307 Email: Gonzalo.Camarillo@ericsson.com 309 8 Bibliography 311 [1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 312 Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control 313 transmission protocol," Request for Comments 2960, Internet 314 Engineering Task Force, Oct. 2000. 316 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 317 session initiation protocol," Request for Comments 2543, Internet 318 Engineering Task Force, Mar. 1999. 320 [3] L. Coene et al. , "Stream control transmission protocol 321 applicability statement," Internet Draft, Internet Engineering Task 322 Force, Apr. 2001. Work in progress. 324 [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 325 Session initiation protocol," Internet Draft, Internet Engineering 326 Task Force, Nov. 2000. Work in progress. 328 [5] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying 329 the location of services (DNS SRV)," Request for Comments 2782, 330 Internet Engineering Task Force, Feb. 2000. 332 Table of Contents 334 1 Introduction ........................................ 1 335 2 Terminology ......................................... 2 336 3 Potential Benefits .................................. 2 337 3.1 Advantages over UDP ................................. 2 338 3.2 Advantages over TCP ................................. 3 339 4 Usage of SCTP ....................................... 4 340 4.1 Mapping of transactions into streams ................ 5 341 5 Locating a SIP server ............................... 6 342 6 Conclusion .......................................... 6 343 7 Author's Addresses .................................. 6 344 8 Bibliography ........................................ 7