idnits 2.17.1 draft-ietf-sip-sctp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 375. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 24, 2004) is 7092 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 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '3') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '8') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: May 25, 2005 H. Schulzrinne 4 Columbia University 5 G. Camarillo 6 Ericsson 7 November 24, 2004 9 The Stream Control Transmission Protocol (SCTP) as a Transport for 10 the Session Initiation Protocol (SIP) 11 draft-ietf-sip-sctp-05.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document specifies a mechanism for usage of SCTP (the Stream 47 Control Transmission Protocol) as the transport between SIP (Session 48 Initiation Protocol) entities. SCTP is a new protocol which provides 49 several features that may prove beneficial for transport between SIP 50 entities which exchange a large amount of messages, including 51 gateways and proxies. As SIP is transport independent, support of 52 SCTP is a relatively straightforward process, nearly identical to 53 support for TCP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Potential Benefits . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1 Advantages over UDP . . . . . . . . . . . . . . . . . . . 3 61 3.2 Advantages over TCP . . . . . . . . . . . . . . . . . . . 4 62 4. Usage of SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1 Mapping of SIP Transactions into SCTP Streams . . . . . . 6 64 5. Locating a SIP Server . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 69 8.2 Informative References . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 71 Intellectual Property and Copyright Statements . . . . . . . . 9 73 1. Introduction 75 The Stream Control Transmission Protocol (SCTP) [3] has been designed 76 as a new transport protocol for the Internet (or intranets), at the 77 same layer as TCP and UDP. SCTP has been designed with the transport 78 of legacy SS7 signaling messages in mind. We have observed that many 79 of the features designed to support transport of such signaling are 80 also useful for the transport of SIP (the Session Initiation 81 Protocol) [4], which is used to initiate and manage interactive 82 sessions on the Internet. 84 SIP itself is transport-independent, and can run over any reliable or 85 unreliable message or stream transport. However, procedures are only 86 defined for transport over UDP and TCP. This document defines 87 transport of SIP over SCTP. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [1]. 95 3. Potential Benefits 97 Coene et. al. present some of the key benefits of SCTP [7]. We 98 summarize some of these benefits here and analyze how they relate to 99 SIP (a more detailed analysis can be found in [9]). 101 3.1 Advantages over UDP 103 All the advantages that SCTP has over UDP regarding SIP transport are 104 also shared by TCP. Below there is a list of the general advantages 105 that a connection-oriented transport protocol such as TCP or SCTP has 106 over a connection-less transport protocol such as UDP. 108 Fast Retransmit: SCTP can quickly determine the loss of a packet, as 109 a result of its usage of SACK and a mechanism which sends SACK 110 messages faster than normal when losses are detected. The result 111 is that losses of SIP messages can be detected much faster than 112 when SIP is run over UDP (detection will take at least 500 ms, if 113 not more). Note that TCP SACK does exist as well, and TCP also 114 has a fast retransmit option. Over an existing connection, this 115 results in faster call setup times under conditions of packet 116 loss, which is very desirable. This is probably the most 117 significant advantage to SCTP for SIP transport. 119 Congestion Control: SCTP maintains congestion control over the entire 120 association. For SIP, this means that the aggregate rate of 121 messages between two entities can be controlled. When SIP is run 122 over TCP, the same advantages are afforded. However, when run 123 over UDP, SIP provides less effective congestion control. That is 124 because congestion state (measured in terms of the UDP retransmit 125 interval) is computed on a transaction by transaction basis, 126 rather than across all transactions. Congestion control 127 performance is thus similar to opening N parallel TCP connections, 128 as opposed to sending N messages over one TCP connection. 130 Transport-Layer Fragmentation: SCTP and TCP provide transport-layer 131 fragmentation. If a SIP message is larger than the MTU size it is 132 fragmented at the transport layer. When UDP is used fragmentation 133 occurs at the IP layer. IP fragmentation increases the likelihood 134 of having packet losses and makes it difficult (when not 135 impossible) NAT and firewall traversal. This feature will become 136 important if 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 141 analyze the advantages of SCTP over TCP. 143 Head of the Line: SCTP is message based as opposed to TCP which is 144 stream based. This allows SCTP to separate different signalling 145 messages at the transport layer. TCP just understands bytes. 146 Assembling received bytes to form signalling messages is performed 147 at the application layer. Therefore, TCP always delivers an 148 ordered stream of bytes to the application. On the other hand, 149 SCTP can deliver signalling messages to the application as soon as 150 they arrive (when using the unordered service). The loss of a 151 signalling message does not affect the delivery of the rest of the 152 messages. This avoids the head of line blocking problem in TCP, 153 which occurs when multiple higher layer connections are 154 multiplexed within a single TCP connection. A SIP transaction can 155 be considered an application layer connection. Between proxies 156 there are multiple transactions running. The loss of a message in 157 one transaction should not adversely effect the ability of a 158 different transaction to send a message. Thus, if SIP is run 159 between entities with many transactions occurring in parallel, 160 SCTP can provide improved performance over SIP over TCP (but not 161 SIP over UDP; but SIP over UDP is not ideal from a congestion 162 control standpoint, see above). 164 Easier Parsing: Another advantage of message based protocols such as 165 SCTP and UDP over stream based protocols such as TCP is that they 166 allow easier parsing of messages at the application layer. There 167 is not need of establishing boundaries (typically using 168 Content-Length headers) between different messages. However, this 169 advantage is almost negligible. 171 Multihoming: An SCTP connection can be associated with multiple IP 172 addresses on the same host. Data is always sent over one of the 173 addresses, but should it become unreachable, data sent to one can 174 migrate to a different address. This improves fault tolerance; 175 network failures making one interface of the server unavailable do 176 not prevent the service from continuing to operate. SIP servers 177 are likely to have substantial fault tolerance requirements. It 178 is worth noting that because SIP is message oriented, and not 179 stream oriented, the existing SRV (Service Selection) procedures 180 defined in [4] can accomplish the same goal, even when SIP is run 181 over TCP. In fact, SRV records allow the 'connection' to fail 182 over to a separate host. Since SIP proxies can run statelessly, 183 failover can be accomplished without data synchronization between 184 the primary and its backups. Thus, the multihoming capabilities 185 of SCTP provide marginal benefits. 187 It is important to note that most of the benefits of SCTP for SIP 188 occur under loss conditions. Therefore, under a zero loss condition, 189 SCTP transport of SIP should perform on par with TCP transport. 190 Research is needed to evaluate under what loss conditions the 191 improvements in setup times and throughput will be observed. 193 4. Usage of SCTP 195 Usage of SCTP requires no additional headers or syntax in SIP. Below 196 we show an example of a SIP URL with a transport parameter and an 197 example of a Via header field. In both examples SCTP is the 198 transport protocol. 200 sip:Bob.Johnson@example.com;transport=sctp 201 Via: SIP/2.0/SCTP ws1234.example.com:5060 203 Rules for sending a request over SCTP are identical to TCP. The only 204 difference is that an SCTP sender has to choose a particular stream 205 within an association in order to send the request (see Section 4.1). 207 Note that no SCTP identifier needs to be defined for SIP messages. 208 Therefore, the Payload Protocol Indentifier in SCTP DATA chunks 209 transporting SIP messages MUST be set to zero. 211 The SIP transport layers of both peers are responsible for managing 212 the persistent SCTP connection between them. On the sender side the 213 core or a client (or server) transaction generates a request (or 214 response) and passes it to the transport layer. The transport sends 215 the request to the peer's transaction layer. The peer's transaction 216 layer is responsible for delivering the incoming request (or 217 response) to the proper existing server (or client) transaction. If 218 no server (or client) transaction exists for the incoming message the 219 transport layer passes the request (or response) to the core, which 220 may decide to construct a new server (or client) transaction. 222 4.1 Mapping of SIP Transactions into SCTP Streams 224 SIP transactions need to be mapped into SCTP streams in a way that 225 avoids Head Of the Line (HOL) blocking. Among all the different ways 226 of performing this mapping that fulfil this requirement, we have 227 chosen the simplest one; a SIP entity SHOULD send every SIP message 228 (request or response) over stream zero with the unordered flag set. 229 On the receiving side, a SIP entity MUST be ready to receive SIP 230 messages over any stream. 232 In the past, it was proposed to use SCTP stream IDs as lightweight 233 SIP transaction identifiers. That proposal was withdrawn because 234 SIP now provides (as defined in RFC 3261 [4]) a transaction 235 identifier in the branch parameter of the Via entries. This 236 transaction identifier, missing in the previous SIP spec [8], 237 makes it unnecessary to use the SCTP stream IDs to demultiplex SIP 238 traffic. 240 SIP has many circumstances in which the use of TLS [2] is required, 241 for instance, for routing a SIPS URI [4]. As defined in RFC 3436 242 [6], TLS running over SCTP MUST NOT use the SCTP unordered delivery 243 service. Moreover, any SIP use of an extra layer between the 244 transport layer and SIP that requires ordered delivery of messages 245 MUST NOT use the SCTP unordered delivery service. 247 SIP applications that require ordered delivery of messages from the 248 transport layer (e.g., TLS) SHOULD send SIP messages belonging to the 249 same SIP transaction over the same SCTP stream. Additionally, they 250 SHOULD send messages belonging to different SIP transactions over 251 different SCTP streams, as long as there are enough available 252 streams. 254 A common scenario where the above mechanism should be used 255 consists of two proxies exchanging SIP traffic over a TLS 256 connection using SCTP as the transport protocol. This works 257 because all of the SIP transactions between the two proxies can be 258 established within one SCTP association. 260 Note that if both sides of the association follow this 261 recommendation, when a request arrives over a particular stream, the 262 server is free to return responses over a different stream. This 263 way, both sides manage the available streams in the sending 264 direction, independently of the streams chosen by the other side to 265 send a particular SIP message. This avoids undesirable collisions 266 when seizing a particular stream. 268 5. Locating a SIP Server 270 The primary issue when sending a request is determining whether the 271 next hop server supports SCTP, so that an association can be opened. 272 SIP entities follow normal SIP procedures to discover [5] a server 273 that supports SCTP. 275 6. Security Considerations 277 The security issues raised in RFC 3261 [4] are not worsened by SCTP, 278 provided the advice in Section 4.1 is followed and SCTP over TLS [6] 279 is used where TLS would be required in RFC 3261 [4]. So, the 280 mechanisms described in RFC 3436 [6] MUST be used when SIP runs on 281 top of TLS [2] and SCTP. 283 7. IANA Considerations 285 This document has no IANA considerations. 287 8. References 289 8.1 Normative References 291 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 292 Levels", BCP 14, RFC 2119, March 1997. 294 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 295 2246, January 1999. 297 [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 298 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 299 "Stream Control Transmission Protocol", RFC 2960, October 2000. 301 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 302 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 303 Session Initiation Protocol", RFC 3261, June 2002. 305 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 306 (SIP): Locating SIP Servers", RFC 3263, June 2002. 308 [6] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 309 Security over Stream Control Transmission Protocol", RFC 3436, 310 December 2002. 312 8.2 Informative References 314 [7] Coene, L., "Stream Control Transmission Protocol Applicability 315 Statement", RFC 3257, April 2002. 317 [8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 318 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 320 [9] Camarillo, G., Schulrinne, H. and R. Kantola, "Evaluation of 321 Transport Protocols for the Session Initiation Protocol", IEEE 322 Network vol. 17, no. 5, 2003. 324 Authors' Addresses 326 Jonathan Rosenberg 327 Cisco Systems 328 600 Lanidex Plaza 329 Parsippany, NJ 07054 330 US 332 Phone: +1 973 952-5000 333 EMail: jdrosen@dynamicsoft.com 334 URI: http://www.jdrosen.net 336 Henning Schulzrinne 337 Columbia University 338 M/S 0401 339 1214 Amsterdam Ave. 340 New York, NY 10027-7003 341 US 343 EMail: schulzrinne@cs.columbia.edu 345 Gonzalo Camarillo 346 Ericsson 347 Hirsalantie 11 348 Jorvas 02420 349 Finland 351 EMail: Gonzalo.Camarillo@ericsson.com 353 Intellectual Property Statement 355 The IETF takes no position regarding the validity or scope of any 356 Intellectual Property Rights or other rights that might be claimed to 357 pertain to the implementation or use of the technology described in 358 this document or the extent to which any license under such rights 359 might or might not be available; nor does it represent that it has 360 made any independent effort to identify any such rights. Information 361 on the procedures with respect to rights in RFC documents can be 362 found in BCP 78 and BCP 79. 364 Copies of IPR disclosures made to the IETF Secretariat and any 365 assurances of licenses to be made available, or the result of an 366 attempt made to obtain a general license or permission for the use of 367 such proprietary rights by implementers or users of this 368 specification can be obtained from the IETF on-line IPR repository at 369 http://www.ietf.org/ipr. 371 The IETF invites any interested party to bring to its attention any 372 copyrights, patents or patent applications, or other proprietary 373 rights that may cover technology that may be required to implement 374 this standard. Please address the information to the IETF at 375 ietf-ipr@ietf.org. 377 Disclaimer of Validity 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Copyright Statement 389 Copyright (C) The Internet Society (2004). This document is subject 390 to the rights, licenses and restrictions contained in BCP 78, and 391 except as set forth therein, the authors retain all their rights. 393 Acknowledgment 395 Funding for the RFC Editor function is currently provided by the 396 Internet Society.