idnits 2.17.1 draft-ietf-sigtran-common-transport-00.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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 457 lines 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. 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 (June 1999) is 9080 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Authors 3 Transport Working Group Ian Rytina, Ericsson 4 Category: Informational Lyndon Ong, Nortel Networks 5 June 1999 6 Expires: January 2000 8 Framework for SIGTRAN Common Transport Protocol 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), its 16 areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document outlines a framework for the Sigtran protocol that 33 consists of a modular, extensible structure with a common reliable 34 transport protocol used for all signaling transport. This structure 35 initially allows for narrowband SCN signalling protocols to be 36 transported over an IP network in order to support TDM to IP 37 interworking of voice and data services, and allows the protocol to 38 be extended for future use as required. 40 The reliable transport protocol addresses a set of requirements for 41 signaling transport which include persistent associations, reliable 42 data transport and sequence preservation (within a control stream). 43 These requirements imply a TCP-like protocol, with added functions 44 to support: 45 -- elimination of head-of-line blocking 46 -- rapid detection of session failure 47 -- failover to backup session or port 48 -- improved transport delay characteristics suited to signaling. 50 The functional characteristics for the signaling common transport 51 protocol are described in greater detail in the document, and these 52 are compared with TCP characteristics. 54 1. Introduction 56 1.1 Overview 58 This document outlines a framework for the Sigtran protocol. The 59 framework provides a modular structure using a common reliable 60 transport protocol for transport needs, and allowing definition 61 of adaptation modules for different SCN control protocols to be 62 added as extensions, without affecting the transport protocol itself. 63 This will allow progress to be made initially on a set of "key" SCN 64 protocols for the first stage of Sigtran activities, and adaptation 65 modules supporting additional protocols to be added at a later date, 66 as required. 68 1.2 Terminology 70 The following general term is used in this document: 72 Signaling Common Transport Protocol : 74 This is a generic term used to describe the protocol used to transport 75 SCN signaling protocols over IP. It is assumed to have a modular 76 structure that uses UDP for underlying transport functions, but adds 77 functions such as reliability, sequenced delivery, etc., as needed 78 for SCN signaling transport (see also [1]). 80 1.3 Scope 82 Signaling transport focuses on transparent transport of SCN signaling 83 protocols over IP networks. The signaling transport protocol will be 84 defined in such a way as to support encapsulation and carriage of a 85 variety of application and call control protocols. For more information 86 refer to [1]. 88 It is the intention that the signaling transport protocol be designed 89 in an open manner so that it can be integrated with multimedia 90 frameworks such as H.323 and SIP, to provide transport of SCN 91 protocols in such systems. 93 2. Protocol Framework Architecture 95 2.1 Signaling Transport Components 97 The basic architecture, as defined in [1], is as in Figure 1 :- 99 SCN Protocols 100 | | | 101 +--------------------------------+ 102 | SCN Adaptation modules | 103 +--------------------------------+ 104 | 105 +--------------------------------+ 106 | Common Signaling Transport | 107 +--------------------------------+ 108 | 109 +--------------------------------+ 110 | Standard IP Transport | 111 +--------------------------------+ 112 | 113 Network Layer (IP) 115 Figure 1: Signaling Transport Components 117 The three components of Signaling Transport are :- 119 1) adaptation modules that support specific primitives, e.g. 120 management indications, required by a particular SCN signaling 121 application protocol. 122 2) a Signaling Common Transport Protocol that supports a common set 123 of reliable transport functions for signaling transport. 124 3) a standard IP transport protocol (TCP/UDP) provided by the operating 125 system. In some network scenarios, it has been recognised that TCP 126 can provide limited (but sufficient) reliable transport 127 functionality for signaling, and this is discussed later in this 128 document. 130 In order to provide a generic modular structure, the architecture can 131 be further decomposed to allow full optionality according to the SCN 132 protocol being transported. This architecture is outlined in Figure 133 2a (for UDP) and Figure 2b (for TCP). 135 (*1) 136 || || || || || 137 +------------------+ +------------------------------------+ 138 | |--| Adaptation Modules (ADAL1....ADALn)| 139 | | +------------------------------------+ 140 | | ||(*2) 141 | | +------------------------------------+ 142 | |--| Sequencing Sublayer | 143 | Layer Control | +------------------------------------+ 144 | and | || 145 | Layer Management | +------------------------------------+ 146 | |--| Reliability Sublayer | 147 | | +------------------------------------+ 148 | | || 149 | | +------------------------------------+ 150 | |--| Link Sublayer | 151 +------------------+ +------------------------------------+ 152 ||(*3) 153 +------------------------------------+ 154 | UDP | 155 +------------------------------------+ 157 || = Data 158 | = Management 160 Figure 2a: Signaling Transport Sublayers 161 (Underlying Transport Protocol is UDP) 163 Published (open) interfaces are :- 164 (*1) SCN primitives. Initially, MTP3-user, MTP2-user, Q.921-user. 165 (*2) Common Signaling Transport Protocol upper primitives. 166 (*3) UDP upper primitives. 168 (*1) 169 || || || || || 170 +------------------+ +------------------------------------+ 171 | Layer Control |--| Adaptation Modules (ADAL1....ADALn)| 172 | and | +------------------------------------+ 173 | Layer Management | || 174 +------------------+ ||(*4) 175 +------------------------------------+ 176 | TCP | 177 +------------------------------------+ 179 || = Data 180 | = Management 182 Figure 2b: Signaling Transport Sublayers 183 (Underlying Transport Protocol is TCP) 185 TCP provides the sequencing, reliability and link sublayers, hence 186 these sublayers are null. The published (open) interfaces are :- 187 (*1) SCN primitives. 188 (*4) TCP upper primitives. 190 2.2 Definition of Sublayer Functionality 192 The function of the sublayers described in Figures 2a and 2b can be 193 defined as follows :- 195 - Link, Reliability, Sequencing sublayers are the Signaling 196 Common Transport Protocol. These sublayers are not exposed to 197 external view, and are only used to model the functions 198 of the Signaling Common Transport Protocol. These sublayers 199 will be empty/null, according to whether the underlying transport 200 is UDP or TCP. The protocol will be based on MDTP [2]. 202 - The Adaptation Modules (ADAL1....ADALn) make up the sublayer 203 that describes the functions expected by a particular SCN 204 signaling protocol. For example, one such function could be the 205 mapping of different SCN primitives to the Signaling Common 206 Transport Protocol primitives (and vice versa). 207 In order to meet the extensibility requirement for transporting 208 existing and future SCN signaling protocols [1] the structure of this 209 sublayer must be made generic, and easily extensible. Two current 210 examples of adaptation modules are the Backhaul Manager [3] and SS7 211 ISUP Tunneling [4]. 213 2.3 Peer-to-Peer Relationship 215 The relationship between two peer entities is described in Figure 3. 217 || || || || || || || || 218 +-------+ +--------------------+ +--------------------+ +-------+ 219 | |-| Adaptation Modules |<=====>| Adaptation Modules |-| | 220 | | +--------------------+ +--------------------+ | | 221 | | || || | | 222 | | +--------------------+ +--------------------+ | | 223 | Layer |-| Sequencing SL |<=====>| Sequencing SL |-| Layer | 224 |Control| +--------------------+ +--------------------+ |Control| 225 | & | || || | & | 226 | Mgmnt | +--------------------+ +--------------------+ | Mgmnt | 227 | |-| Reliability SL |<=====>| Reliability SL |-| | 228 | | +--------------------+ +--------------------+ | | 229 | | || || | | 230 | | +--------------------+ +--------------------+ | | 231 | |-| Link SL |<=====>| Link SL |-| | 232 +-------+ +--------------------+ +--------------------+ +-------+ 233 || || 234 +--------------------+ +--------------------+ 235 | TCP/UDP | | TCP/UDP | 236 +--------------------+ +--------------------+ 237 || || 238 +-------------------------------------------------+ 239 | Network Layer (IP) | 240 +-------------------------------------------------+ 242 || = Data 243 | = Management 245 Figure 3: Peer-to-Peer Relationship 247 3. Generic Protocol Framework 249 3.1 Generic Protocol Structure 251 The set of SCN control protocols which are to be supported is 252 potentially very large. Since there are many SCN protocols, each with 253 different requirements, this is best addressed by a modular framework 254 which allows addition of modules to support SCN protocols not addressed 255 in the initial specification. 257 The advantage of the architecture described in Section 2 is that it 258 assumes that all SCN protocols have similar transport requirements, so 259 that the only protocol specific considerations are in the adaptation 260 modules. One proposal is that an adaptation module document (RFC) is 261 written for each SCN protocol. (To be decided) 263 Initial work will be carried out on mapping the MTP3-user, the 264 MTP2-user and the Q.921-user primitives to the upper primitives of the 265 Signaling Common Transport Protocol [2]. 267 3.2 Registration aspects 269 TBD, possibly required to register with IANA for Protocol Identifier, 270 and Port Numbers. 272 4. Signaling Common Transport Protocol 274 This section documents the reasoning behind the need to use a transport 275 protocol that has similar functionality to TCP (i.e. link, reliability 276 and sequencing) but also suggesting added functions that are specific 277 for signaling transport but are not provided by current TCP. 279 4.1 Requirements for Signaling Transport 281 Based on the architecture for signaling transport [1], it can be 282 determined that transport of SCN control protocols will have the 283 following requirements: 285 (a) Persistent Associations 287 The applications identified in [1] require transport of 288 signaling messages multiplexed from many different interactions 289 (e.g., many different calls). As a result, the transport 290 association should be persistent, and setup of the association 291 is small relative to the duration of the association. 293 (b) Reliable Transport 295 The performance requirements identified in [1] require that 296 the transport protocol carries data reliably and with minimal 297 errors. 299 (c) Time-Dependent Transport 301 The nature of signaling adds some time-dependency to transport 302 requirements: signaling messages that are delayed in transport 303 are in most cases no longer useful, because the associated 304 SCN protocol or the user will time out and take alternative 305 actions. 307 (d) Availability 309 Since multiplexed signaling affects a large number of users 310 (for example, a single 56 Kbps SS7 link may support signaling 311 for 50,000 individual calls per hour), availability of signaling 312 transport must be high, often implemented through use of 313 redundancy of devices and ports. 315 4.2 Functions Comparable to TCP 317 A number of the functions for signaling transport can be met by 318 use of TCP for transport, especially: 320 - persistent associations 321 - reliable transport 322 - sequence preservation 324 4.3 Functions Beyond Current TCP 326 Signaling transport ideally would support a number of functions 327 that are not provided by current TCP: 329 - no head-of-line blocking, i.e. multiple streams 330 - multilink failover for added reliability 331 - keep-alive function for active rapid failure detection 332 - message verses byte sequence numbering 333 - tighter timer control (than standard TCP implementations) 334 - greater fan out (than standard TCP implementations) 336 4.4 TCP for Reliable Transport 338 It is possible to use TCP for reliable transport, however, certain 339 features will not be provided as identified in the previous section. 340 Also, certain features of TCP may need to be turned off in order to 341 avoid interference with signaling transport requirements. Some of these, 342 for example, are :- 343 - use of the Nagle algorithm (adds delay) 344 - tbd 346 4.5 Security 348 Since signaling affects a large number of users and carries potentially 349 sensitive information, security is extremely important. SCN protocols 350 are protected by running over private links, and care should be taken 351 to continue this practice when running over IP. When the Signaling 352 Common Transport Protocol is used over a shared IP network, such as 353 the Internet, IPsec protocols (RFC2401, RFC2411) should be used to 354 secure the data and to protect the header of the IP packet. 356 5. Functions of Target Signaling Common Transport Protocol 358 The following basic functions are provided by the target Signaling 359 Common Transport Protocol :- 361 - Initialization of transport association 362 - Synchronization of association state 363 - Synchronization of sequence numbering 364 - Reliable Data Transfer 365 - Forward and backward sequence numbering 366 - Timers for transmission and acknowledgement 367 - Notification of out-of-sequence 368 - Retransmission of lost messages 369 - Support of multiple control streams 370 - Separate sequence control and delivery of each stream 371 - Request to open new streams 372 - Congestion control 373 - Window flow control 374 - Congestion avoidance based on on TCP methods, e.g. using 375 retransmission backoff, window reduction, etc. 376 - Detection of session failure by active means, e.g. heartbeat 377 - Termination of association 379 6. References 381 [1] L.Ong, I.Rytina, et al :- Architectural Framework for Signaling 382 Transport 383 , June 1999, work in progress. 385 [2] R. Stewart, Q. Xie, et al :- Multi-Network Datagram Transmission 386 Protocol 387 , June 1999, work in progress. 389 [3] D. Auerbach, D. Berg, K, Morneault :- Signaling Backhaul Protocol 390 , February 1999, work in 391 progress. 393 [4] G. Sidebottom, L. Ong, I. Rytina :- SS7 ISUP Tunneling 394 , June 1999, work in progress. 396 Acknowledgements 398 Credit for the basic architecture diagram should be given to Tom 399 Taylor for supplying the original decomposition. 400 The authors would also like to thank M. Holdridge, C. Sharp and 401 G. Sidebottom for their valuable comments and suggestions. 403 Authors' Addresses 405 Ian Rytina, Lyndon Ong 406 Ericsson Australia, Nortel Networks 407 37/360 Elizabeth Street, 4401 Great America Parkway 408 Melbourne, Victoria 3000 Santa Clara, CA 95054 409 Australia USA 410 ian.rytina@ericsson.com long@nortelnetworks.com 412 Full Copyright Statement 414 Copyright (C) The Internet Society (1998). All Rights Reserved. 416 This document and translations of it may be copied and furnished to 417 others, and derivative works that comment on or otherwise explain it 418 or assist in its implementation may be prepared, copied, published and 419 distributed, in whole or in part, without restriction of any kind, 420 provided that the above copyright notice and this paragraph are 421 included on all such copies and derivative works. 423 However, this document itself may not be modified in any way, such as 424 by removing the copyright notice or references to the Internet Society 425 or other Internet organizations, except as needed for the purpose of 426 developing Internet standards in which case the procedures for 427 copyrights defined in the Internet Standards process must be followed, 428 or as required to translate it into languages other than English. 430 The limited permissions granted above are perpetual and will not be 431 revoked by the Internet Society or its successors or assigns. 433 This document and the information contained herein is provided on an 434 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 435 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 436 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 437 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 438 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 This Internet Draft expires in 6 months from June 1999.