idnits 2.17.1 draft-ietf-sip-sctp-06.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 450. ** 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 (January 13, 2005) is 7042 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) -- Looks like a reference, but probably isn't: 'RFC3261' on line 339 -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 348 ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2960 (ref. '4') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '9') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP J. Rosenberg 3 Internet-Draft Cisco Systems 4 Expires: July 14, 2005 H. Schulzrinne 5 Columbia University 6 G. Camarillo 7 Ericsson 8 January 13, 2005 10 The Stream Control Transmission Protocol (SCTP) as a Transport for 11 the Session Initiation Protocol (SIP) 12 draft-ietf-sip-sctp-06.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 14, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document specifies a mechanism for usage of SCTP (the Stream 48 Control Transmission Protocol) as the transport between SIP (Session 49 Initiation Protocol) entities. SCTP is a new protocol which provides 50 several features that may prove beneficial for transport between SIP 51 entities which exchange a large amount of messages, including 52 gateways and proxies. As SIP is transport independent, support of 53 SCTP is a relatively straightforward process, nearly identical to 54 support for TCP. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Potential Benefits . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1 Advantages over UDP . . . . . . . . . . . . . . . . . . . 3 62 3.2 Advantages over TCP . . . . . . . . . . . . . . . . . . . 4 63 4. Transport Parameters . . . . . . . . . . . . . . . . . . . . . 5 64 5. SCTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1 Mapping of SIP Transactions into SCTP Streams . . . . . . 7 66 6. Locating a SIP Server . . . . . . . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 71 9.2 Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . 11 75 1. Introduction 77 The Stream Control Transmission Protocol (SCTP) [4] has been designed 78 as a new transport protocol for the Internet (or intranets), at the 79 same layer as TCP and UDP. SCTP has been designed with the transport 80 of legacy SS7 signaling messages in mind. We have observed that many 81 of the features designed to support transport of such signaling are 82 also useful for the transport of SIP (the Session Initiation 83 Protocol) [5], which is used to initiate and manage interactive 84 sessions on the Internet. 86 SIP itself is transport-independent, and can run over any reliable or 87 unreliable message or stream transport. However, procedures are only 88 defined for transport over UDP and TCP. This document defines 89 transport of SIP over SCTP. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [1]. 97 3. Potential Benefits 99 Coene et. al. present some of the key benefits of SCTP [10]. We 100 summarize some of these benefits here and analyze how they relate to 101 SIP (a more detailed analysis can be found in [12]). 103 3.1 Advantages over UDP 105 All the advantages that SCTP has over UDP regarding SIP transport are 106 also shared by TCP. Below there is a list of the general advantages 107 that a connection-oriented transport protocol such as TCP or SCTP has 108 over a connection-less transport protocol such as UDP. 110 Fast Retransmit: SCTP can quickly determine the loss of a packet, as 111 a result of its usage of SACK and a mechanism which sends SACK 112 messages faster than normal when losses are detected. The result 113 is that losses of SIP messages can be detected much faster than 114 when SIP is run over UDP (detection will take at least 500 ms, if 115 not more). Note that TCP SACK does exist as well, and TCP also 116 has a fast retransmit option. Over an existing connection, this 117 results in faster call setup times under conditions of packet 118 loss, which is very desirable. This is probably the most 119 significant advantage to SCTP for SIP transport. 121 Congestion Control: SCTP maintains congestion control over the entire 122 association. For SIP, this means that the aggregate rate of 123 messages between two entities can be controlled. When SIP is run 124 over TCP, the same advantages are afforded. However, when run 125 over UDP, SIP provides less effective congestion control. That is 126 because congestion state (measured in terms of the UDP retransmit 127 interval) is computed on a transaction by transaction basis, 128 rather than across all transactions. Congestion control 129 performance is thus similar to opening N parallel TCP connections, 130 as opposed to sending N messages over one TCP connection. 132 Transport-Layer Fragmentation: SCTP and TCP provide transport-layer 133 fragmentation. If a SIP message is larger than the MTU size it is 134 fragmented at the transport layer. When UDP is used fragmentation 135 occurs at the IP layer. IP fragmentation increases the likelihood 136 of having packet losses and makes it difficult (when not 137 impossible) NAT and firewall traversal. This feature will become 138 important if the size of SIP messages grows dramatically. 140 3.2 Advantages over TCP 142 We have shown the advantages of SCTP and TCP over UDP. We now 143 analyze the advantages of SCTP over TCP. 145 Head of the Line: SCTP is message based as opposed to TCP which is 146 stream based. This allows SCTP to separate different signalling 147 messages at the transport layer. TCP just understands bytes. 148 Assembling received bytes to form signalling messages is performed 149 at the application layer. Therefore, TCP always delivers an 150 ordered stream of bytes to the application. On the other hand, 151 SCTP can deliver signalling messages to the application as soon as 152 they arrive (when using the unordered service). The loss of a 153 signalling message does not affect the delivery of the rest of the 154 messages. This avoids the head of line blocking problem in TCP, 155 which occurs when multiple higher layer connections are 156 multiplexed within a single TCP connection. A SIP transaction can 157 be considered an application layer connection. Between proxies 158 there are multiple transactions running. The loss of a message in 159 one transaction should not adversely effect the ability of a 160 different transaction to send a message. Thus, if SIP is run 161 between entities with many transactions occurring in parallel, 162 SCTP can provide improved performance over SIP over TCP (but not 163 SIP 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 such as 167 SCTP and UDP over stream based protocols such as TCP is that they 168 allow easier parsing of messages at the application layer. There 169 is not need of establishing boundaries (typically using 170 Content-Length headers) between different messages. However, this 171 advantage is almost negligible. 173 Multihoming: An SCTP connection can be associated with multiple IP 174 addresses on the same host. Data is always sent over one of the 175 addresses, but should it become unreachable, data sent to one can 176 migrate to a different address. This improves fault tolerance; 177 network failures making one interface of the server unavailable do 178 not prevent the service from continuing to operate. SIP servers 179 are likely to have substantial fault tolerance requirements. It 180 is worth noting that because SIP is message oriented, and not 181 stream oriented, the existing SRV (Service Selection) procedures 182 defined in [5] can accomplish the same goal, even when SIP is run 183 over TCP. In fact, SRV records allow the 'connection' to fail 184 over to a separate host. Since SIP proxies can run statelessly, 185 failover can be accomplished without data synchronization between 186 the primary and its backups. Thus, the multihoming capabilities 187 of SCTP provide marginal benefits. 189 It is important to note that most of the benefits of SCTP for SIP 190 occur under loss conditions. Therefore, under a zero loss condition, 191 SCTP transport of SIP should perform on par with TCP transport. 192 Research is needed to evaluate under what loss conditions the 193 improvements in setup times and throughput will be observed. 195 4. Transport Parameters 197 A SIP URIs can carry a transport parameter indicating the transport 198 protocol to be used. RFC 3261 defines the value "sctp" for SCTP but 199 does not define the value for the transport parameter for TLS over 200 SCTP. Note that the value "tls", defined by RFC 3261, is intended 201 for TLS over TCP. 203 Here we define the value "tls-sctp" for the SIP URI transport 204 parameter to be used for messages to be sent over TLS over SCTP [8]. 205 The updated augmented BNF (Backus-Naur Form) [2] for this parameter 206 is the following (the original BNF for this parameter can be found in 207 RFC 3261): 209 transport-param = "transport=" 210 ( "udp" / "tcp" / "sctp" / "tls" / "tls-sctp" 211 / other-transport) 213 The following are examples of SIP URIs using "sctp" and "tls-sctp" in 214 their transport parameters: 216 sip:Bob.Johnson@example.com;transport=sctp 217 sip:Bob.Johnson@example.com;transport=tls-sctp 219 Via header fields also carry a transport protocol identifier. RFC 220 3261 defines the value "SCTP" for SCTP but does not define the value 221 for the transport parameter for TLS over SCTP. Note that the value 222 "TLS", defined by RFC 3261, is intended for TLS over TCP. 224 Here we define the value "TLS-SCTP" for the transport part of the Via 225 header field to be used for requests sent over TLS over SCTP [8]. 226 The updated augmented BNF (Backus-Naur Form) [2] for this parameter 227 is the following (the original BNF for this parameter can be found in 228 RFC 3261): 230 transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" 231 / other-transport 233 The following are examples of Via header fields using "SCTP" and 234 "TLS-SCTP": 236 Via: SIP/2.0/SCTP ws1234.example.com:5060 237 Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060 239 5. SCTP Usage 241 Rules for sending a request over SCTP are identical to TCP. The only 242 difference is that an SCTP sender has to choose a particular stream 243 within an association in order to send the request (see Section 5.1). 245 Note that no SCTP identifier needs to be defined for SIP messages. 246 Therefore, the Payload Protocol Indentifier in SCTP DATA chunks 247 transporting SIP messages MUST be set to zero. 249 The SIP transport layers of both peers are responsible for managing 250 the persistent SCTP connection between them. On the sender side the 251 core or a client (or server) transaction generates a request (or 252 response) and passes it to the transport layer. The transport sends 253 the request to the peer's transaction layer. The peer's transaction 254 layer is responsible for delivering the incoming request (or 255 response) to the proper existing server (or client) transaction. If 256 no server (or client) transaction exists for the incoming message the 257 transport layer passes the request (or response) to the core, which 258 may decide to construct a new server (or client) transaction. 260 5.1 Mapping of SIP Transactions into SCTP Streams 262 SIP transactions need to be mapped into SCTP streams in a way that 263 avoids Head Of the Line (HOL) blocking. Among all the different ways 264 of performing this mapping that fulfil this requirement, we have 265 chosen the simplest one; a SIP entity SHOULD send every SIP message 266 (request or response) over stream zero with the unordered flag set. 267 On the receiving side, a SIP entity MUST be ready to receive SIP 268 messages over any stream. 270 In the past, it was proposed to use SCTP stream IDs as lightweight 271 SIP transaction identifiers. That proposal was withdrawn because 272 SIP now provides (as defined in RFC 3261 [5]) a transaction 273 identifier in the branch parameter of the Via entries. This 274 transaction identifier, missing in the previous SIP spec [9], 275 makes it unnecessary to use the SCTP stream IDs to demultiplex SIP 276 traffic. 278 SIP has many circumstances in which the use of TLS [3] is required, 279 for instance, for routing a SIPS URI [5]. As defined in RFC 3436 280 [8], TLS running over SCTP MUST NOT use the SCTP unordered delivery 281 service. Moreover, any SIP use of an extra layer between the 282 transport layer and SIP that requires ordered delivery of messages 283 MUST NOT use the SCTP unordered delivery service. 285 SIP applications that require ordered delivery of messages from the 286 transport layer (e.g., TLS) SHOULD send SIP messages belonging to the 287 same SIP transaction over the same SCTP stream. Additionally, they 288 SHOULD send messages belonging to different SIP transactions over 289 different SCTP streams, as long as there are enough available 290 streams. 292 A common scenario where the above mechanism should be used 293 consists of two proxies exchanging SIP traffic over a TLS 294 connection using SCTP as the transport protocol. This works 295 because all of the SIP transactions between the two proxies can be 296 established within one SCTP association. 298 Note that if both sides of the association follow this 299 recommendation, when a request arrives over a particular stream, the 300 server is free to return responses over a different stream. This 301 way, both sides manage the available streams in the sending 302 direction, independently of the streams chosen by the other side to 303 send a particular SIP message. This avoids undesirable collisions 304 when seizing a particular stream. 306 6. Locating a SIP Server 308 The primary issue when sending a request is determining whether the 309 next hop server supports SCTP, so that an association can be opened. 310 SIP entities follow normal SIP procedures to discover [6] a server 311 that supports SCTP. 313 However, in order to be able to use TLS on top of SCTP, an extra 314 definition is needed. RFC 3263 defines the NAPTR (Naming Authority 315 Pointer) [7] service value "SIP+D2S" for SCTP but fails to define a 316 value for TLS over SCTP. Here we define the NAPTR service value 317 "SIPS+D2S" for servers that support TLS over SCTP [8]. 319 7. Security Considerations 321 The security issues raised in RFC 3261 [5] are not worsened by SCTP, 322 provided the advice in Section 5.1 is followed and TLS over SCTP [8] 323 is used where TLS would be required in RFC 3261 [5] or in RFC 3263 324 [6]. So, the mechanisms described in RFC 3436 [8] MUST be used when 325 SIP runs on top of TLS [3] and SCTP. 327 8. IANA Considerations 329 This document defines a new value (tls-sctp) for the SIP and SIPS URI 330 transport parameter. The IANA is requested to add a reference to 331 this document to the entry of the transport parameter in the 332 "SIP/SIPS URI Parameters" subregistry, which is located under the 333 "Session Initiation Protocol (SIP) Parameters" registry. The 334 reference should appear in double-brackets, as indicated in RFC 3969 335 [11]. The resulting entry should be: 337 Parameter Name Predefined Values Reference 338 -------------- ----------------- --------- 339 transport Yes [RFC3261] [[RFCXXXX]] 341 This document also defines a new NAPTR service field value 342 (SIPS+D2S). The IANA is requested to register this value under the 343 "Registry for the SIP SRV Resource Record Services Field". The 344 resulting entry should be: 346 Services Field Protocol Reference 347 -------------------- -------- --------- 348 SIPS+D2S SCTP [RFCXXXX] 350 9. References 352 9.1 Normative References 354 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 355 Levels", BCP 14, RFC 2119, March 1997. 357 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 358 Specifications: ABNF", RFC 2234, November 1997. 360 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 361 2246, January 1999. 363 [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 364 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 365 "Stream Control Transmission Protocol", RFC 2960, October 2000. 367 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 368 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 369 Session Initiation Protocol", RFC 3261, June 2002. 371 [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 372 (SIP): Locating SIP Servers", RFC 3263, June 2002. 374 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 375 Three: The Domain Name System (DNS) Database", RFC 3403, October 376 2002. 378 [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 379 Security over Stream Control Transmission Protocol", RFC 3436, 380 December 2002. 382 9.2 Informative References 384 [9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 385 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 387 [10] Coene, L., "Stream Control Transmission Protocol Applicability 388 Statement", RFC 3257, April 2002. 390 [11] Camarillo, G., "The Internet Assigned Number Authority (IANA) 391 Uniform Resource Identifier (URI) Parameter Registry for the 392 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 393 2004. 395 [12] Camarillo, G., Schulrinne, H. and R. Kantola, "Evaluation of 396 Transport Protocols for the Session Initiation Protocol", IEEE 397 Network vol. 17, no. 5, 2003. 399 Authors' Addresses 401 Jonathan Rosenberg 402 Cisco Systems 403 600 Lanidex Plaza 404 Parsippany, NJ 07054 405 US 407 Phone: +1 973 952-5000 408 EMail: jdrosen@dynamicsoft.com 409 URI: http://www.jdrosen.net 411 Henning Schulzrinne 412 Columbia University 413 M/S 0401 414 1214 Amsterdam Ave. 415 New York, NY 10027-7003 416 US 418 EMail: schulzrinne@cs.columbia.edu 420 Gonzalo Camarillo 421 Ericsson 422 Hirsalantie 11 423 Jorvas 02420 424 Finland 426 EMail: Gonzalo.Camarillo@ericsson.com 428 Intellectual Property Statement 430 The IETF takes no position regarding the validity or scope of any 431 Intellectual Property Rights or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; nor does it represent that it has 435 made any independent effort to identify any such rights. Information 436 on the procedures with respect to rights in RFC documents can be 437 found in BCP 78 and BCP 79. 439 Copies of IPR disclosures made to the IETF Secretariat and any 440 assurances of licenses to be made available, or the result of an 441 attempt made to obtain a general license or permission for the use of 442 such proprietary rights by implementers or users of this 443 specification can be obtained from the IETF on-line IPR repository at 444 http://www.ietf.org/ipr. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights that may cover technology that may be required to implement 449 this standard. Please address the information to the IETF at 450 ietf-ipr@ietf.org. 452 Disclaimer of Validity 454 This document and the information contained herein are provided on an 455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 457 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 458 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 459 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 Copyright Statement 464 Copyright (C) The Internet Society (2005). This document is subject 465 to the rights, licenses and restrictions contained in BCP 78, and 466 except as set forth therein, the authors retain all their rights. 468 Acknowledgment 470 Funding for the RFC Editor function is currently provided by the 471 Internet Society.