idnits 2.17.1 draft-ietf-sip-sctp-04.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 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 19, 2003) is 7461 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) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '6') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '7') (Obsoleted by RFC 4346) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 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-04.txt 10 November 19, 2003 11 Expires: May, 2004 13 The Stream Control Transmission Protocol as a 14 Transport for the Session Initiation Protocol 16 STATUS OF THIS MEMO 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 To view the list Internet-Draft Shadow Directories, see 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document specifies a mechanism for usage of SCTP (the Stream 40 Control Transmission Protocol) as the transport between SIP entities. 41 SCTP is a new protocol which provides several features that may prove 42 beneficial for transport between SIP entities which exchange a large 43 amount of messages, including gateways and proxies. As SIP is 44 transport independent, support of SCTP is a relatively 45 straightforward process, nearly identical to support for TCP. 47 Table of Contents 49 1 Introduction ........................................ 3 50 2 Terminology ......................................... 3 51 3 Potential Benefits .................................. 3 52 3.1 Advantages over UDP ................................. 3 53 3.2 Advantages over TCP ................................. 4 54 4 Usage of SCTP ....................................... 5 55 4.1 Mapping of SIP Transactions into Streams ............ 6 56 5 Locating a SIP server ............................... 7 57 6 Security Considerations ............................. 7 58 7 Conclusion .......................................... 7 59 8 Author's Addresses .................................. 7 60 9 Normative References ................................ 8 61 10 Informative References .............................. 8 63 1 Introduction 65 The Stream Control Transmission Protocol (SCTP) [1] has been designed 66 as a new transport protocol for the Internet (or intranets), at the 67 same layer as TCP and UDP. SCTP has been designed with the transport 68 of legacy SS7 signaling messages in mind. We have observed that many 69 of the features designed to support transport of such signaling are 70 also useful for the transport of SIP (the Session Initiation 71 Protocol) [2], which is used to initiate and manage interactive 72 sessions on the Internet. 74 SIP itself is transport-independent, and can run over any reliable or 75 unreliable message or stream transport. However, procedures are only 76 defined for transport over UDP and TCP. In order to encourage 77 experimentation and evaluation of the appropriateness of SCTP for SIP 78 transport, this document defines transport of SIP over SCTP. 80 Note that this is not a proposal that SCTP be adopted as the primary 81 or preferred transport for SIP; substantial evaluation of SCTP, 82 deployment, and experimentation can take place before that happens. 83 This draft is targeted at encouraging such experimentation by 84 enabling it in SIP. 86 2 Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [3]. 92 3 Potential Benefits 94 Coene et. al. present some of the key benefits of SCTP [4]. We 95 summarize some of these benefits here and analyze how they relate to 96 SIP (a more detailed analysis can be found in [5].) 98 3.1 Advantages over UDP 100 All the advantages that SCTP has over UDP regarding SIP transport are 101 also shared by TCP. Below there is a list of the general advantages 102 that a connection-oriented transport protocol such as TCP or SCTP has 103 over a connection-less transport protocol such as UDP. 105 Fast Retransmit: SCTP can quickly determine the loss of a 106 packet, as a result of its usage of SACK and a mechanism 107 which sends SACK messages faster than normal when losses 108 are detected. The result is that losses of SIP messages can 109 be detected much faster than when SIP is run over UDP 110 (detection will take at least 500ms, if not more). Note 111 that TCP SACK does exist as well, and TCP also has a fast 112 retransmit option. Over an existing connection, this 113 results in faster call setup times under conditions of 114 packet loss, which is very desirable. This is probably the 115 most significant advantage to SCTP for SIP transport. 117 Congestion Control: SCTP maintains congestion control over the 118 entire association. For SIP, this means that the aggregate 119 rate of messages between two entities can be controlled. 120 When SIP is run over TCP, the same advantages are afforded. 121 However, when run over UDP, SIP provides less effective 122 congestion control. That is because congestion state 123 (measured in terms of the UDP retransmit interval) is 124 computed on a transaction by transaction basis, rather than 125 across all transactions. Congestion control performance is 126 thus similar to opening N parallel TCP connections, as 127 opposed to sending N messages over 1 TCP connection. 129 Transport layer fragmentation: SCTP and TCP provide transport 130 layer fragmentation. If a SIP message is larger than the 131 MTU size it is fragmented at the transport layer. When UDP 132 is used fragmentation occurs at the IP layer. IP 133 fragmentation increases the likelihood of having packet 134 losses and make it difficult (when not impossible) NAT and 135 firewall traversal. This feature will become important if 136 the size of SIP messages grows dramatically. 138 3.2 Advantages over TCP 140 We have shown the advantages of SCTP and TCP over UDP. We now analyze 141 the advantages of SCTP over TCP. 143 Head of the Line: SCTP is message based as opposed to TCP that 144 is stream based. This allows SCTP to separate different 145 signalling messages at the transport layer. TCP just 146 understands bytes. Assembling received bytes to form 147 signalling messages is performed at the application layer. 148 Therefore, TCP always delivers an ordered stream of bytes 149 to the application. On the other hand, SCTP can deliver 150 signalling messages to the application as soon as they 151 arrive (when using the unordered service). The loss of a 152 signalling message does not affect the delivery of the rest 153 of the messages. This avoids the head of line blocking 154 problem in TCP, which occurs when multiple higher layer 155 connections are multiplexed within a single TCP connection. 156 A SIP transaction can be considered an application layer 157 connection. Between proxies there are multiple transactions 158 running. The loss of a message in one transaction should 159 not adversely effect the ability of a different transaction 160 to send a message. Thus, if SIP is run between entities 161 with many transactions occurring in parallel, SCTP can 162 provide improved performance over SIP over TCP (but not SIP 163 over UDP; but SIP over UDP is not ideal from a congestion 164 control standpoint, see above). 166 Easier Parsing: Another advantage of message based protocols 167 such as SCTP and UDP over stream based protocols such as 168 TCP is that they allow easier parsing of messages at the 169 application layer. There is not need of establishing 170 boundaries (typically using Content-Length headers) between 171 different messages. However, this advantage is almost 172 negligible. 174 Multihoming: An SCTP connection can be associated with multiple 175 IP addresses on the same host. Data is always sent over one 176 of the addresses, but should it become unreachable, data 177 sent to one can migrate to a different address. This 178 improves fault tolerance; network failures making one 179 interface of the server unavailable do not prevent the 180 service from continuing to operate. SIP servers are likely 181 to have substantial fault tolerance requirements. It is 182 worth noting that because SIP is message-oriented, and not 183 stream oriented, the existing SRV procedures defined in [2] 184 can accomplish the same goal, even when SIP is run over 185 TCP. In fact, SRV records allow the "connection" to fail 186 over to a separate host. Since SIP proxies can run 187 statelessly, failover can be accomplished without data 188 synchronization between the primary and its backups. Thus, 189 the multihoming capabilities of SCTP provide marginal 190 benefits. 192 It is important to note that most of the benefits of SCTP for SIP 193 occur under loss conditions. Therefore, under a zero loss condition, 194 SCTP transport of SIP should perform on par with TCP transport. 195 Research is needed to evaluate under what loss conditions the 196 improvements in setup times and throughput will be observed. The 197 purpose of this draft is to enable such experimentation in order to 198 provide concrete data on its applicability to SIP. 200 4 Usage of SCTP 202 Usage of SCTP requires no additional headers or syntax in SIP. Below 203 we show an example of a SIP URL with a transport parameter and an 204 example of a via header field. In both examples SCTP is the transport 205 protocol. 207 sip:Bob.Johnson@example.com;transport=sctp 209 Via: SIP/2.0/SCTP ws1234.example.com:5060 211 Rules for sending a request over SCTP are identical to TCP. The only 212 difference is that an SCTP sender has to choose a particular stream 213 within an association in order to send the request (see Section 4.1). 215 Note that no SCTP identifier needs to be defined for SIP messages. 216 Therefore, the Payload Protocol Indentifier in SCTP DATA chunks 217 transporting SIP messages MUST be set to zero. 219 The SIP transport layers of both peers are responsible to manage the 220 persistent SCTP connection between them. On the sender side the core 221 or a client (or server) transaction generates a request (or response) 222 and passes it to the transport layer. The transport sends the request 223 to the peer's transaction layer. The peer's transaction layer is 224 responsible of delivering the incoming request (or response) to the 225 proper existing server (or client) transaction. If no server (or 226 client) transaction exists for the incoming message the transport 227 layer passes the request (or response) to the core, which may decide 228 to construct a new server (or client) transaction. 230 4.1 Mapping of SIP Transactions into Streams 232 SIP transactions need to be mapped into SCTP streams in a way that 233 avoids Head Of the Line (HOL) blocking. Among all the different ways 234 of performing this mapping that fulfill this requirement, we have 235 chosen the simplest one; a SIP entity SHOULD send every SIP message 236 (request or response) over stream zero with the unordered flag set. 237 On the receiving side, a SIP entity MUST be ready to receive SIP 238 messages over any stream. 240 Note that previous versions of this document proposed to 241 use SCTP stream IDs as lightweight SIP transaction 242 identifiers. That proposal has been withdrawn because SIP 243 now provides a transaction identifier in the branch 244 parameter of the Via entries. This transaction identifier, 245 missing in the previous SIP spec [6], makes it unnecessary 246 to use the SCTP stream IDs to demultiplex SIP traffic. 248 Some applications introduce an extra layer between the transport 249 layer and SIP (e.g., compression and/or encryption). This extra layer 250 sometimes requires ordered delivery of messages from the transport 251 layer (e.g., TLS [7]). In this case, it is RECOMMENDED that SIP 252 messages belonging to the same transaction are sent over the same 253 stream and messages belonging to different transactions are sent over 254 different streams. Note that if both sides of the association follow 255 this recommendation, if a request arrives over a particular stream, 256 the server is free to return responses over a different stream. This 257 way, both sides manage the available streams in the sending 258 direction, independently of the streams chosen by the other side to 259 send a particular SIP message. This avoids undesirable collisions 260 when seizing a particular stream. 262 5 Locating a SIP server 264 The primary issue when sending a request is determining whether the 265 next hop server supports SCTP, so that an association can be opened. 266 SIP entities follow normal SIP procedures to discover [8] a server 267 that supports SCTP. 269 6 Security Considerations 271 No extra security risk outside these specified by [2] are foreseen. 273 7 Conclusion 275 This draft has presented a discussion on the applicability of SCTP to 276 SIP transport, and provided a mechanism for allowing two SCTP-capable 277 entities to use an SCTP association to exchange SIP traffic. 279 8 Author's Addresses 281 Jonathan Rosenberg 282 dynamicsoft 283 200 Executive Drive 284 Suite 120 285 West Orange, NJ 07052 286 email: jdrosen@dynamicsoft.com 288 Henning Schulzrinne 289 Columbia University 290 M/S 0401 291 1214 Amsterdam Ave. 292 New York, NY 10027-7003 293 email: schulzrinne@cs.columbia.edu 295 Gonzalo Camarillo 296 Ericsson 297 Advanced Signalling Research Lab. 298 FIN-02420 Jorvas 299 Finland 300 Phone: +358 9 299 3371 301 Fax: +358 9 299 3052 302 Email: Gonzalo.Camarillo@ericsson.com 304 9 Normative References 306 [1] R. J. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, 307 T. Taylor, I. Rytina, and M. Kalla, "Stream control transmission 308 protocol," RFC 2960, Internet Engineering Task Force, Oct. 2000. 310 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 311 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 312 initiation protocol," RFC 3261, Internet Engineering Task Force, June 313 2002. 315 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 316 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 318 10 Informative References 320 [4] L. Coene, "Stream control transmission protocol applicability 321 statement," RFC 3257, Internet Engineering Task Force, Apr. 2002. 323 [5] G. Camarillo, H. Schulzrinne, and R. Kantola, "Evaluation of 324 transport protocols for the session initiation protocol," IEEE 325 Network , vol. 17, no. 5, 2003. 327 [6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 328 session initiation protocol," RFC 2543, Internet Engineering Task 329 Force, Mar. 1999. 331 [7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, 332 Internet Engineering Task Force, Jan. 1999. 334 [8] J. Rosenberg and H. Schulzrinne, "Session initiation protocol 335 (SIP): locating SIP servers," RFC 3263, Internet Engineering Task 336 Force, June 2002.