idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-03.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 lines == 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.) ** The abstract seems to contain references ([RFC2960], [RFC2719]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 2002) is 8109 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? 'RFC2960' on line 279 looks like a reference -- Missing reference section? 'RFC2719' on line 290 looks like a reference -- Missing reference section? 'SCTPFLOW' on line 294 looks like a reference -- Missing reference section? 'ALLMAN99' on line 298 looks like a reference -- Missing reference section? 'RFCOENE' on line 284 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT L. Coene(Ed) 3 Internet Engineering Task Force Siemens 4 Issued: January 2002 5 Expires: July 2002 7 Telephony Signalling Transport over SCTP applicability statement 8 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. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1ID-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This document describes the applicability of the Stream Control 32 Transmission Protocol (SCTP)[RFC2960] for transport of telephony 33 signalling information over IP infrastructure. Special 34 considerations for using SCTP to meet the requirements of 35 transporting telephony signalling [RFC2719] are discussed. 37 Draft SCTP & Telephony signalling January 2002 39 Table of contents 41 Telephony signalling over SCTP Applicability statement ......... ii 42 Chapter 1: Introduction ........................................ 2 43 Chapter 1.1: Terminology ....................................... 2 44 Chapter 1.2: Contributors ...................................... 3 45 Chapter 1.3: Overview ......................................... 3 46 Chapter 2: Applicability of telephony signalling transport 47 using SCTP ..................................................... 4 48 Chapter 3: Issues for transporting Telephony signalling 49 information over SCTP .......................................... 4 50 Chapter 3.1: Congestion control ................................ 4 51 Chapter 3.2: Detection of failures ............................. 5 52 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 5 53 Chapter 3.2.2: Heartbeat ....................................... 5 54 Chapter 3.2.3: Maximum Number of retransmissions ............... 5 55 Chapter 3.3: Shorten end-to-end message delay ................. 6 56 Chapter 3.4: Bundling considerations ........................... 6 57 Chapter 3.5: Stream Usage ...................................... 6 58 Chapter 4: Security considerations ............................. 6 59 Chapter 5: References and related work ......................... 7 60 Chapter 6: Acknowledgments ..................................... 7 61 Chapter 7: Author's address .................................... 7 63 1 INTRODUCTION 65 Transport of telephony signalling requires special 66 considerations. In order to use SCTP, special care must be taken to 67 meet the performance, timing and failure management requirements. 69 1.1 Terminology 71 The following terms are commonly identified in related work: 73 Association: SCTP connection between two endpoints. 75 Stream: A uni-directional logical channel established within an 76 association, within which all user messages are delivered in 77 sequence except for those submitted to the unordered delivery 78 service. 80 Draft SCTP & Telephony signalling January 2002 82 1.2 Contributors 84 The following people contributed to the document: L. Coene(Editor), 85 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 86 M. Holdrege, M.C. Belinchon, A. Jungmaier, and L. Ong. 88 1.3 Overview 90 SCTP provides a general purpose, reliable transport between two 91 endpoints. 93 The following functions are provided by SCTP: 95 - Reliable Data Transfer 97 - Multiple streams to help avoid head-of-line blocking 99 - Ordered and unordered data delivery on a per-stream basis 101 - Bundling and fragmentation of user data 103 - Congestion and flow control 105 - Support continuous monitoring of reachability 107 - Graceful termination of association 109 - Support of multi-homing for added reliability 111 - Protection against blind denial-of-service attacks 113 - Protection against blind masquerade attacks 115 Telephony Signalling transport over IP normally uses the following 116 architecture: 118 Telephony Application 119 | 120 +------------------------------------+ 121 | Signalling Adaptation module | 122 +------------------------------------+ 123 | 124 +------------------------------------+ 125 |Stream Control Transmission Protocol| 126 | (SCTP) | 127 +------------------------------------+ 128 | 129 Internet Protocol (IPv4/IPv6) 131 Figure 1.1: Telephony signalling transport protocol stack 133 Draft SCTP & Telephony signalling January 2002 135 The components of the protocol stack are : 137 (1) Adaptation modules are used when the telephony application needs 138 to preserve an existing primitive interface. (e.g. management 139 indications, data operation primitives, ... for a particular 140 user/application protocol). 142 (2) SCTP, specially configured to meet the telephony application 143 performance requirements. 145 (3) The standard Internet Protocol. 147 2 Applicability of Telephony Signalling transport using SCTP 149 SCTP can be used as the transport protocol for telephony 150 applications. Message boundaries are preserved during data 151 transport and so no message delineation is needed. The user data can 152 be delivered by the order of transmission within a stream(in 153 sequence delivery) or the order of arrival. 155 SCTP can be used to provide redundancy and fault tolerance at the 156 transport layer and below. Telephony applications needing this level 157 of fault tolerance can make use of SCTP's multi-homing support. 159 SCTP can be used for telephony applications where head-of-line 160 blocking is a concern. Such an application should use multiple 161 streams to provide independent ordering of telephony signalling 162 messages. 164 3 Issues for transporting telephony signalling over SCTP 166 3.1 Congestion Control 168 The basic mechanism of congestion control in SCTP have been 169 described in [RFC2960]. SCTP congestion control sometimes conflicts 170 with the timing requirements of telephony signalling transport. 172 In an engineered network (e.g. a private intranet), in which network 173 capacity and maximum traffic is very well understood, some telephony 174 signalling applications may choose to relax the congestion control 175 rules in order to satisfy the timing requirements. But this should 176 be done without destabilising the network, otherwise this would lead 177 to potential congestion collapse of the network. 179 Some telephony signalling applications may have their own congestion 181 Draft SCTP & Telephony signalling January 2002 183 control and flow control techniques. These techniques may interact 184 with the congestion control procedures in SCTP. Additionally, 185 telephony applications may use SCTP stream based flow control 186 [SCTPFLOW]. 188 3.2 Detection of failures 190 Telephony systems often must achieve high availability in operation. 191 For example, they are often required to be able to preserve stable 192 calls during a component failure. Therefore error situations at the 193 transport layer and below must be detected very fast so that the 194 application can take approriate steps to recover and preserve the 195 stable calls. This poses special requirements on SCTP to discover 196 unreachablility of a destination address or a peer. 198 3.2.1 Retransmission TimeOut (RTO) calculation 200 The SCTP protocol parameter RTO.Min value has a direct impact on the 201 calculation of the RTO itself. Some telephony applications want to 202 lower the value of the RTO.Min to less than 1 second. This would 203 allow the message sender to reach the maximum 204 number-of-retransmission threshold faster in the case of network 205 failures. However, lowering RTO.Min may have a negative impact on 206 network behaviour [ALLMAN99]. 208 In some rare cases, telephony applications might not want to use the 209 exponential timer back-off concept in RTO calculation in order to 210 speed up failure detection. The danger of doing this is that, when 211 network congestion occurs, not backing off the timer may worsen the 212 congestion situation. Therefore, this strategy should never be used 213 in public Internet. 215 It should be noted that not using delayed SACK will also help faster 216 failure detection. 218 3.2.2 Heartbeat 220 For faster detection of (un)availability of idle paths, the 221 telephony application may consider lowering the SCTP parameter 222 HB.interval. It should be noted this will result in a higher traffic 223 load. 225 3.2.3 Maximum number of retransmissions 227 Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters 228 to lower values will speed up both destination address and peer 230 Draft SCTP & Telephony signalling January 2002 232 failure detection. However, if these values are set too low, the 233 probability of false detections will increase. 235 3.3 Shorten end-to-end message delay 237 Telephony applications often require short end-to-end message 238 delays. The methods described in section 3.2.1 on lowering RTO and 239 not using delayed SACK may be considered. 241 3.4 Bundling considerations 243 Bundling small telephony signalling messages at transmission helps 244 improve the bandwidth usage efficiency of the network. On the 245 downside, bundling may introduce additional delay to some of the 246 messages. This should be taken into consideration when end-to-end 247 delay is a concern. 249 3.5 Stream Usage 251 Telephony signalling traffic is often composed of multiple, 252 independent message sequences. It is highly desirable to transfer 253 those independent message sequences in separate SCTP streams. This 254 reduces the probability of head-of-line blocking in which the 255 retransmission of a lost message affects the delivery of other 256 messages not belonging to the same message sequence. 258 4 Security considerations 260 SCTP only tries to increase the availability of a network. SCTP does 261 not contain any protocol mechanisms which are directly related to 262 user message authentication, integrity and confidentiality 263 functions. For such features, it depends on the IPSEC protocols and 264 architecture and/or on security features of its user protocols. 266 Mechanisms for reducing the risk of blind denial-of-service attacks 267 and masquerade attacks are built into SCTP protocol. See RFC2960, 268 section 11 for detailed information. 270 Currently the IPSEC working group is investigating the support of 271 multihoming by IPSEC protocols. At the present time to use IPSEC, 272 one must use 2 * N * M security associations if one endpoint uses N 273 addresses and the other M addresses. 275 Draft SCTP & Telephony signalling January 2002 277 5 References and related work 279 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 280 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 281 L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 282 October 2000. 284 [RFCOENE] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, 285 R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., 286 "Stream Control Transmission Protocol Applicability statement", 287 , December 2000. Work 288 In Progress. 290 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 291 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 292 Architecture for Signalling Transport", RFC2719, October 1999 294 [SCTPFLOW] Stewart, R., Ramalho, M., Xie, Q., Conrad, P. and Rose, 295 M., "SCTP Stream based flow control", September 2000, Work in 296 Progress. 298 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 299 Network Path Properties", Proc. SIGCOMM'99, 1999. 301 6 Acknowledgments 303 This document was initially developed by a design team consisting of 304 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 305 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 306 Jungmaier, Gery Verwimp and Lyndon Ong. 308 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, 309 G. Sidebottom, K. Morneault, T. George, M. Stillman and many others 310 for their invaluable comments. 312 7 Author's Address 314 Lode Coene Phone: +32-14-252081 315 Siemens Atea EMail: lode.coene@siemens.atea.be 316 Atealaan 34 317 B-2200 Herentals 318 Belgium 320 Draft SCTP & Telephony signalling January 2002 322 Expires: July 2002 324 Full Copyright Statement 326 Copyright (C) The Internet Society (2002). All Rights Reserved. 328 This document and translations of it may be copied and furnished 329 to others, and derivative works that comment on or otherwise 330 explain it or assist in its implementation may be prepared, 331 copied, published and distributed, in whole or in part, without 332 restriction of any kind, provided that the above copyright notice 333 and this paragraph are included on all such copies and derivative 334 works. However, this document itself may not be modified in any 335 way, such as by removing the copyright notice or references to the 336 Internet Society or other Internet organizations, except as needed 337 for the purpose of developing Internet standards in which case the 338 procedures for copyrights defined in the Internet Standards 339 process must be followed, or as required to translate it into 340 languages other than English. 342 The limited permissions granted above are perpetual and will not 343 be revoked by the Internet Society or its successors or assigns. 345 This document and the information contained herein is provided on 346 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 347 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 348 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 349 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.