idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-02.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? ** 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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 == Line 121 has weird spacing: '...ses the follo...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 278 looks like a reference -- Missing reference section? 'RFC2719' on line 289 looks like a reference -- Missing reference section? 'SCTPFLOW' on line 293 looks like a reference -- Missing reference section? 'ALLMAN99' on line 296 looks like a reference -- Missing reference section? 'RFCOENE' on line 283 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene 2 Internet Engineering Task Force M. Tuexen 3 Issued: December 2000 G. Verwimp 4 Expires: June 2001 Siemens 5 J. Loughney 6 Nokia 7 R.R. Stewart 8 Cisco 9 Qiaobing Xie 10 Motorola 11 M.C. Belinchon 12 I. Rytina 13 Ericsson 14 L. Ong 15 Nortel Networks 17 Telephony Signalling Transport over SCTP applicability statement 18 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as 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 The list of Internet- 35 Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document describes the applicability of the Stream Control 41 Transmission Protocol (SCTP)[RFC2960] for transport of telephony 42 signalling information over IP infrastructure. Special considerations 43 for using SCTP to meet the requirements of transporting telephony 44 signalling [RFC2719] are discussed. 46 Draft Telephony Signalling Transport over SCTP AS December 2000 48 TABLE OF CONTENTS 50 Telephony Signalling transport over SCTP Applicability state- 51 ment ........................................................... ii 52 Chapter 1: Introduction ........................................ 2 53 Chapter 1.1: Terminology ....................................... 2 54 Chapter 1.2: Overview .......................................... 3 55 Chapter 2: Applicability of Telephony Signalling transport 56 using SCTP ..................................................... 4 57 Chapter 3: Issues for transporting Telephony signalling 58 information over SCTP .......................................... 5 59 Chapter 3.1: Congestion control ................................ 5 60 Chapter 3.2: Detection of failures ............................. 5 61 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 5 62 Chapter 3.2.2: Heartbeat ....................................... 6 63 Chapter 3.2.3: Maximum Number of retransmissions ............... 6 64 Chapter 3.3: Shorten end-to-end message delay .................. 6 65 Chapter 3.4: Bundling considerations ............................ 6 66 Chapter 3.5: Stream Usage ...................................... 6 67 Chapter 4: Security considerations ............................. 7 68 Chapter 5: References and related work ......................... 7 69 Chapter 6: Acknowledgments ..................................... 8 70 Chapter 7: Authors address ..................................... 8 72 1 INTRODUCTION 74 Transport of telephony signalling requires special considerations. 75 In order to use SCTP, special care must be taken to meet the perfor- 76 mance, timing and failure management requirements. 78 1.1 Terminology 80 The following terms are commonly identified in related work: 82 Association: SCTP connection between two endpoints. 84 Stream: A uni-directional logical channel established within an 86 Draft Telephony Signalling Transport over SCTP AS December 2000 88 association, within which all user messages are delivered in 89 sequence except for those submitted to the unordered delivery ser- 90 vice. 92 1.2 Overview 94 SCTP provides a general purpose, reliable transport between two end- 95 points. 97 The following functions are provided by SCTP: 99 - Reliable Data Transfer 101 - Multiple streams to help avoid head-of-line blocking 103 - Ordered and unordered data delivery on a per-stream basis 105 - Bundling and fragmentation of user data 107 - Congestion and flow control 109 - Support continuous monitoring of reachability 111 - Graceful termination of association 113 - Support of multi-homing for added reliability 115 - Protection against blind denial-of-service attacks 117 - Protection against blind masquerade attacks 119 Draft Telephony Signalling Transport over SCTP AS December 2000 121 Telephony Signalling transport over IP normally uses the following 122 architecture: 124 Telephony Application 125 | 126 +------------------------------------+ 127 | Signalling Adaptation module | 128 +------------------------------------+ 129 | 130 +------------------------------------+ 131 |Stream Control Transmission Protocol| 132 | (SCTP) | 133 +------------------------------------+ 134 | 135 Internet Protocol (IPv4/IPv6) 137 Figure 1.1: Telephony signalling transport protocol stack 139 The components of the protocol stack are : 141 (1) Adaptation modules are used when the telephony application needs to 142 preserve an existing primitive interface. (e.g. management indica- 143 tions, data operation primitives, ... for a particular 144 user/application protocol). 146 (2) SCTP, specially configured to meet the telephony application per- 147 formance requirements. 149 (3) The standard Internet Protocol. 151 2 Applicability of Telephony Signalling transport using SCTP 153 SCTP can be used as the transport protocol for telephony applications. 154 Message boundaries are preserved during data transport and so no message 155 delineation is needed. The user data can be delivered by the order of 156 transmission within a stream(in sequence delivery) or the order of 157 arrival. 159 SCTP can be used to provide redundancy and fault tolerance at the tran- 160 sport layer and below. Telephony applications needing this level of 161 fault tolerance can make use of SCTP's multi-homing support. 163 SCTP can be used for telephony applications where head-of-line blocking 164 is a concern. Such an application should use multiple streams to provide 166 Draft Telephony Signalling Transport over SCTP AS December 2000 168 independent ordering of telephony signalling messages. 170 3 Issues for transporting telephony signalling over SCTP 172 3.1 Congestion Control 174 The basic mechanism of congestion control in SCTP have been described in 175 [RFC2960]. SCTP congestion control sometimes conflicts with the timing 176 requirements of telephony signalling transport. 178 In an engineered network (e.g. a private intranet), in which network 179 capacity and maximum traffic is very well understood, some telephony 180 signalling applications may choose to relax the congestion control rules 181 in order to satisfy the timing requirements. But this should be done 182 without destabilising the network, otherwise this would lead to poten- 183 tial congestion collapse of the network. 185 Some telephony signalling applications may have their own congestion 186 control and flow control techniques. These techniques may interact with 187 the congestion control procedures in SCTP. Additionally, telephony 188 applications may use SCTP stream based flow control [SCTPFLOW]. 190 3.2 Detection of failures 192 Telephony systems often must achieve high availability in operation. For 193 example, they are often required to be able to preserve stable calls 194 during a component failure. Therefore error situations at the transport 195 layer and below must be detected very fast so that the application can 196 take approriate steps to recover and preserve the stable calls. This 197 poses special requirements on SCTP to discover unreachablility of a des- 198 tination address or a peer. 200 3.2.1 Retransmission TimeOut (RTO) calculation 202 The SCTP protocol parameter RTO.Min value has a direct impact on the 203 calculation of the RTO itself. Some telephony applications want to lower 204 the value of the RTO.Min to less than 1 second. This would allow the 205 message sender to reach the maximum number-of-retransmission threshold 206 faster in the case of network failures. However, lowering RTO.Min may 207 have a negative impact on network behaviour [ALLMAN99]. 209 In some rare cases, telephony applications might not want to use the 210 exponential timer back-off concept in RTO calculation in order to speed 212 Draft Telephony Signalling Transport over SCTP AS December 2000 214 up failure detection. The danger of doing this is that, when network 215 congestion occurs, not backing off the timer may worsen the congestion 216 situation. Therefore, this strategy should never be used in public 217 Internet. 219 It should be noted that not using delayed SACK will also help faster 220 failure detection. 222 3.2.2 Heartbeat 224 For faster detection of (un)availability of idle paths, the telephony 225 application may consider lowering the SCTP parameter HB.interval. It 226 should be noted this will result in a higher traffic load. 228 3.2.3 Maximum number of retransmissions 230 Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters to 231 lower values will speed up both destination address and peer failure 232 detection. However, if these values are set too low, the probability of 233 false detections will increase. 235 3.3 Shorten end-to-end message delay 237 Telephony applications often require short end-to-end message delays. 238 The methods described in section 3.2.1 on lowering RTO and not using 239 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 downside, 245 bundling may introduce additional delay to some of the messages. This 246 should be taken into consideration when end-to-end delay is a concern. 248 3.5 Stream Usage 250 Telephony signalling traffic is often composed of multiple, independent 251 message sequences. It is highly desirable to transfer those independent 252 message sequences in separate SCTP streams. This reduces the probability 253 of head-of-line blocking in which the retransmission of a lost message 254 affects the delivery of other messages not belonging to the same message 255 sequence. 257 Draft Telephony Signalling Transport over SCTP AS December 2000 259 4 Security considerations 261 SCTP only tries to increase the availability of a network. SCTP does not 262 contain any protocol mechanisms which are directly related to user mes- 263 sage authentication, integrity and confidentiality functions. For such 264 features, it depends on the IPSEC protocols and architecture and/or on 265 security features of its user protocols. 267 Mechanisms for reducing the risk of blind denial-of-service attacks and 268 masquerade attacks are built into SCTP protocol. See RFC2960, section 11 269 for detailed information. 271 Currently the IPSEC working group is investigating the support of mul- 272 tihoming by IPSEC protocols. At the present time to use IPSEC, one must 273 use 2 * N * M security associations if one endpoint uses N addresses and 274 the other M addresses. 276 5 References and related work 278 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 279 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. 280 and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 281 October 2000. 283 [RFCOENE] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, R. 284 R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., 285 "Stream Control Transmission Protocol Applicability statement", 286 , December 2000. Work 287 In Progress. 289 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 290 Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework Architec- 291 ture for Signalling Transport", RFC2719, October 1999 293 [SCTPFLOW] Stewart, R., Ramalho, M., Xie, Q., Conrad, P. and Rose, M., 294 "SCTP Stream based flow control", September 2000, Work in Progress. 296 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network 297 Path Properties", Proc. SIGCOMM'99, 1999. 299 Draft Telephony Signalling Transport over SCTP AS December 2000 301 6 Acknowledgments 303 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, G. 304 Sidebottom, K. Morneault, T. George, M. Stillman and many others for 305 their invaluable comments. 307 7 Author's Address 309 Lode Coene Phone: +32-14-252081 310 Siemens Atea EMail: lode.coene@siemens.atea.be 311 Atealaan 34 312 B-2200 Herentals 313 Belgium 315 John Loughney Phone: +358-9-43761 316 Nokia Research Center EMail: john.loughney@nokia.com 317 Itamerenkatu 11-13 318 FIN-00180 Helsinki 319 Finland 321 Michel Tuexen Phone: +49-89-722-47210 322 Siemens AG EMail: Michael.Tuexen@icn.siemens.de 323 Hofmannstr. 51 324 81359 Munich 325 Germany 327 Randall R. Stewart Phone: +1-815-477-2127 328 24 Burning Bush Trail. EMail: rrs@cisco.com 329 Crystal Lake, IL 60012 330 USA 332 Qiaobing Xie Phone: +1-847-632-3028 333 Motorola, Inc. EMail: qxie1@email.mot.com 334 1501 W. Shure Drive 335 Arlington Heights, IL 60004 336 USA 338 Maria-Carmen Belinchon Phone: +34-91-339-3535 339 Ericsson Espana S. A. EMail: Maria.C.Belinchon@ericsson.com 340 Network Communication Services 341 Retama 7, 5th floor 342 Madrid, 28045 343 Spain 345 Draft Telephony Signalling Transport over SCTP AS December 2000 347 Ian Rytina EMail:ian.rytina@ericsson.com 348 Ericsson Australia 349 37/360 Elizabeth Street 350 Melbourne, Victoria 3000 351 Australia 353 Lyndon Ong Phone: - 354 Nortel Networks EMail: long@nortelnetworks.com 355 4401 Great America Parkway 356 Santa Clara, CA 95054 357 USA 359 Gery Verwimp Phone: +32-14-253424 360 Siemens Atea EMail: gery.verwimp@siemens.atea.be 361 Atealaan 34 362 B-2200 Herentals 363 Belgium 365 Expires: June 2001 367 Full Copyright Statement 369 Copyright (C) The Internet Society (2000). All Rights Reserved. 371 This document and translations of it may be copied and furnished 372 to others, and derivative works that comment on or otherwise 373 explain it or assist in its implementation may be prepared, 374 copied, published and distributed, in whole or in part, without 375 restriction of any kind, provided that the above copyright notice 376 and this paragraph are included on all such copies and derivative 377 works. However, this document itself may not be modified in any 378 way, such as by removing the copyright notice or references to the 379 Internet Society or other Internet organizations, except as needed 380 for the purpose of developing Internet standards in which case the 381 procedures for copyrights defined in the Internet Standards 382 process must be followed, or as required to translate it into 383 languages other than English. 385 The limited permissions granted above are perpetual and will not 386 be revoked by the Internet Society or its successors or assigns. 388 This document and the information contained herein is provided on 390 Draft Telephony Signalling Transport over SCTP AS December 2000 392 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 393 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 394 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 395 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 396 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.