idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-07.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? == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 21 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2960], [RFC2719]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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.) -- 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? 'RFC2719' on line 922 looks like a reference -- Missing reference section? 'RFC2960' on line 912 looks like a reference -- Missing reference section? 'ALLMAN99' on line 956 looks like a reference -- Missing reference section? 'RFCSIGSEC' on line 959 looks like a reference -- Missing reference section? 'RF3257' on line 917 looks like a reference -- Missing reference section? 'RFC3057' on line 928 looks like a reference -- Missing reference section? 'RFC3331' on line 931 looks like a reference -- Missing reference section? 'RFC3332' on line 935 looks like a reference -- Missing reference section? 'RFCzzzz' on line 940 looks like a reference -- Missing reference section? 'RFCwwww' on line 945 looks like a reference -- Missing reference section? 'RFCqqqq' on line 949 looks like a reference -- Missing reference section? 'RFCtttt' on line 952 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene(Ed) 2 Internet Engineering Task Force Siemens 3 Issued: January 2003 J. Pastor 4 Expires: July 2003 Ericsson 6 Telephony Signalling Transport over SCTP applicability statement 7 < draft-ietf-sigtran-signalling-over-sctp-applic-07.txt> 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1ID-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 This document describes the applicability of the new protocols 31 developed under the signalling transport framework[RFC2719]. A 32 description of the main issues regarding the use of the Stream 33 Control Transmission Protocol (SCTP)[RFC2960] and each adaptation 34 layer for transport of telephony signalling information over IP 35 infrastructure is explained. 37 Draft Telephony signalling over SCTP AS January 2003 39 Table of contents 41 Telephony signalling over SCTP Applicability statement ......... ii 42 Chapter 1: Introduction ........................................ 2 43 Chapter 1.1: Scope ..... ....................................... 3 44 Chapter 1.2: Terminology ....................................... 3 45 Chapter 1.3: Contributors ...................................... 3 46 Chapter 2: SIGTRAN architecture ................................ 4 47 Chapter 2.1: Overview ......................................... 4 48 Chapter 3: Issues for transporting Telephony signalling 49 information over SCTP .......................................... 6 50 Chapter 3.1: Congestion control ................................ 6 51 Chapter 3.2: Detection of failures ............................. 6 52 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 7 53 Chapter 3.2.2: Heartbeat ....................................... 7 54 Chapter 3.2.3: Maximum Number of retransmissions ............... 7 55 Chapter 3.3: Shorten end-to-end message delay ................. 7 56 Chapter 3.4: Bundling considerations ........................... 8 57 Chapter 3.5: Stream Usage ...................................... 8 58 Chapter 4: User Adaptation Layers............................... 8 59 Chapter 4.1: Access Signalling.................................. 11 60 Chapter 4.1.1: IUA (ISDN Q.921 User Adaptation) ................ 11 61 Chapter 4.1.2: V5UA (V5.2-User Adaptation) Layer ............... 12 62 Chapter 4.1.3: DUA (DPNSS/DASS User adaptation) Layer .......... 13 63 Chapter 4.2: Network Signalling ................................ 13 64 Chapter 4.2.1: MTP lvl3 over IP ................................ 14 65 Chapter 4.2.1.1: M2UA (SS7 MTP2-User Adaptation) Layer ......... 14 66 Chapter 4.2.1.2: M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) .. 15 67 Chapter 4.2.1.3: Main difference between M2PA and M2UA ......... 16 68 Chapter 4.2.2: M3UA (SS7 MTP3 User Adaptation) Layer ........... 17 69 Chapter 4.2.3: SUA (SS7 SCCP User Adaptation) Layer ............ 18 70 Chapter 5: Security considerations ............................. 20 71 Chapter 6: References and related work ......................... 20 72 Chapter 7: Acknowledgments ..................................... 21 73 Chapter 8: Author's address .................................... 22 75 1 INTRODUCTION 76 Draft Telephony signalling over SCTP AS January 2003 78 This document intends to inform how to transport telephony 79 signalling protocols, used in classic telephony systems, over IP 80 networks. The whole architecture is called SIGTRAN (Signalling 81 Transport) as described in RFC2719 and is composed of a transport 82 protocol(SCTP) and several User Adaptation layers(UAL). The 83 transport protocol SCTP has been been developed to fulfill the 84 stringent requirements that telephony signalling networks have. The 85 set of User Adaptation layers have also been introduced to make it 86 possible that different signalling protocols can use the SCTP layer. 88 1.1 Scope 90 The scope of this document is to explain the way that user 91 adaptation layers and SCTP protocols have to be used to transport 92 Telephony signalling information over IP. 94 1.2 Terminology 96 The following terms are commonly identified in related work: 98 Association: SCTP connection between two endpoints. 100 Stream: A uni-directional logical channel established within an 101 association, within which all user messages are delivered in 102 sequence except for those submitted to the unordered delivery 103 service. 105 SPU: Signalling protocol user, the application on top of the User 106 adaptation layer. 108 CTSP: Classical Telephony Signalling protocol(examples: MTP level2, 109 MTP level 3, SCCP....). 111 UAL: User adaptation layer: the protocol that encapsulate the upper 112 layer telephony signalling protocols that are to be transported over 113 SCTP/IP. 115 ISEP: IP signalling endpoint: a IP node that implements SCTP and a 116 User adapatation layer. 118 SP: signalling point 120 1.3 Contributors 121 Draft Telephony signalling over SCTP AS January 2003 123 The following people contributed to the document: L. Coene(Editor), 124 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 125 M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong. 127 2 SIGTRAN architecture 129 The SIGTRAN architecture describes the transport of signalling 130 information over IP infrastructure. 132 Telephony Signalling transport over IP normally uses the following 133 architecture: 135 Telephony Signalling Application 136 | 137 +------------------------------------+ 138 | Signalling Adaptation Layers | 139 +------------------------------------+ 140 | 141 +------------------------------------+ 142 |Stream Control Transmission Protocol| 143 | (SCTP) | 144 +------------------------------------+ 145 | 146 Internet Protocol (IPv4/IPv6) 148 Figure 1.1: Telephony signalling transport protocol stack 150 The components of the protocol stack are : 152 (1) Adaptation modules are used when the telephony application needs 153 to preserve an existing primitive interface. (e.g. management 154 indications, data operation primitives, ... for a particular 155 user/application protocol). 157 (2) SCTP, specially configured to meet the telephony application 158 performance requirements. 160 (3) The standard Internet Protocol. 162 The telephony signalling protocols to be transported can be: 164 - SS7 MTP3 users: SCCP, ISUP, TUP... 166 - SS7 MTP2 users: MTP3 168 - SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 170 Draft Telephony signalling over SCTP AS January 2003 172 - ISDN Q.921 users: Q.931 174 - V5.2/DSS1 176 - .... 178 Every classic telephony protocol can have a corresponding UAL 179 developed. 181 The user adaptation layers(UALs) are a set of protocols that 182 encapsulate a specific signalling protocol to be transported over 183 SCTP. The adapation is done in a way that the upper signalling 184 protocols that are relayed remain unaware that the lower layers are 185 different to the originail lower telephony signalling layers. In 186 that sense, the upper interface of the user adapatation layers need 187 to be the same as the upper layer interface to its original lower 188 layer. If a MTP user is being relayed over the IP network, the 189 related UAL used to transport the MTP user will have the same upper 190 interface as MTP has. 192 The Stream Control Transmission protocol was designed to fulfill the 193 stringent transport requirements that classical signalling protocols 194 have and is therefore the recommended transport protocol to use for 195 this purpose. 197 The following functions are provided by SCTP: 199 - Reliable Data Transfer 201 - Multiple streams to help avoid head-of-line blocking 203 - Ordered and unordered data delivery on a per-stream basis 205 - Bundling and fragmentation of user data 207 - Congestion and flow control 209 - Support continuous monitoring of reachability 211 - Graceful termination of association 213 - Support of multi-homing for added reliability 215 - Protection against blind denial-of-service attacks 217 - Protection against blind masquerade attacks 219 SCTP is used as the transport protocol for telephony signalling 220 applications. Message boundaries are preserved during data 221 transport by SCTP and so each UAL can specify its own message 222 structure withing the SCTP user data. The SCTP user data can be 223 delivered by the order of transmission within a stream(in sequence 224 delivery) or unordered. 226 Draft Telephony signalling over SCTP AS January 2003 228 SCTP can be used to provide redundancy at the 229 transport layer and below. Telephony applications needing this level 230 of redundancy can make use of SCTP's multi-homing support. 232 SCTP can be used for telephony applications where head-of-line 233 blocking is a concern. Such an application should use multiple 234 streams to provide independent ordering of telephony signalling 235 messages. 237 3 Issues for transporting telephony signalling over SCTP 239 Transport of telephony signalling requires special 240 considerations. In order to use SCTP, special care must be taken to 241 meet the performance, timing and failure management requirements. 243 3.1 Congestion Control 245 The basic mechanism of congestion control in SCTP have been 246 described in [RFC2960]. SCTP congestion control sometimes conflicts 247 with the timing requirements of telephony signalling application 248 messages which are transported by SCTP. During congestion, messages 249 may be delayed by SCTP, thus sometimes violating the timing 250 requirements of those telephony applications. 252 In an engineered network (e.g. a private intranet), in which network 253 capacity and maximum traffic are very well understood, some 254 telephony signalling applications may choose to relax the congestion 255 control rules of SCTP in order to satisfy the timing 256 requirements. In order to do this, they should employ their own 257 congestion control mechanisms. But this should be done without 258 destabilising the network, otherwise this would lead to potential 259 congestion collapse of the network. 261 Some telephony signalling applications may have their own congestion 262 control and flow control techniques. These techniques may interact 263 with the congestion control procedures in SCTP. 265 3.2 Detection of failures 267 Telephony systems often must have no single point of failure in 268 operation. 270 The UAL must meet certain service availability and performance 271 requirements according to the classical signalling layers they are 273 Draft Telephony signalling over SCTP AS January 2003 275 replacing. Those requirements may be specific for each UAL. 277 For example, telephony systems are often required to be able to 278 preserve stable calls during a component failure. Therefore error 279 situations at the transport layer and below must be detected quickly 280 so that the UAL can take approriate steps to recover and preserve the 281 calls. This poses special requirements on SCTP to discover 282 unreachablility of a destination address or a peer. 284 3.2.1 Retransmission TimeOut (RTO) calculation 286 The SCTP protocol parameter RTO.Min value has a direct impact on the 287 calculation of the RTO itself. Some telephony applications want to 288 lower the value of the RTO.Min to less than 1 second. This would 289 allow the message sender to reach the maximum 290 number-of-retransmission threshold faster in the case of network 291 failures. However, lowering RTO.Min may have a negative impact on 292 network behaviour [ALLMAN99]. 294 In some rare cases, telephony applications might not want to use the 295 exponential timer back-off concept in RTO calculation in order to 296 speed up failure detection. The danger of doing this is that, when 297 network congestion occurs, not backing off the timer may worsen the 298 congestion situation. Therefore, this strategy should never be used 299 in public Internet. 301 It should be noted that not using delayed SACK will also help faster 302 failure detection. 304 3.2.2 Heartbeat 306 For faster detection of (un)availability of idle paths, the 307 telephony application may consider lowering the SCTP parameter 308 HB.interval. It should be noted this might result in a higher traffic 309 load. 311 3.2.3 Maximum number of retransmissions 313 Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters 314 to lower values will speed up both destination address and peer 315 failure detection. However, if these values are set too low, the 316 probability of false fault detections might increase. 318 Draft Telephony signalling over SCTP AS January 2003 320 3.3 Shorten end-to-end message delay 322 Telephony applications often require short end-to-end message 323 delays. The method described in section 3.2.1 on lowering RTO may 324 be considered. The different paths within a single association will 325 have a different RTO, so using the path with the lowest RTO will 326 lead to a shorter end-to-end message delay for the application 327 running on top of the UAL's. 329 3.4 Bundling considerations 331 Bundling small telephony signalling messages at transmission helps 332 improve the bandwidth usage efficiency of the network. On the 333 downside, bundling may introduce additional delay to some of the 334 messages. This should be taken into consideration when end-to-end 335 delay is a concern. 337 3.5 Stream Usage 339 Telephony signalling traffic is often composed of multiple, 340 independent message sequences. It is highly desirable to transfer 341 those independent message sequences in separate SCTP streams. This 342 reduces the probability of head-of-line blocking in which the 343 retransmission of a lost message affects the delivery of other 344 messages not belonging to the same message sequence. 346 4. User Adaptation Layers 348 Users Adaptation Layers (UALs) are defined to encapsulate different 349 signalling protocols in order to transport them over SCTP/IP 351 There are UALs for both access signalling (DSS1) and trunk signalling 352 (SS7). A brief description of the standardized UALs follows in the 353 next sub-sections. 355 The delivery mechanism in the several UALs 357 - Supports seamless operation of UALs user peers over an IP 358 network connection. 360 - Supports the interface boundary that the UAL user had with the 361 traditional lower layer. 363 Draft Telephony signalling over SCTP AS January 2003 365 - Supports management of SCTP transport associations and traffic 366 between SGs and ISEPs or two ISEPs 368 - Supports asynchronous reporting of status changes to management. 370 Signalling User Adaptation Layers have been developed for both: 371 Access and Trunk Telephony Signalling. They are defined as follows. 373 Access Signalling: This is the signalling that is needed between and 374 access device and an exchange in the core network in order to 375 establish, manage or release the voice or data call paths. There 376 are several protocols that have been developed for this purpose. 378 Trunk Signalling: This is the signalling that is used between the 379 exchanges inside the core network in order to establish, manage or 380 release the voice or data call paths. The most common protocols 381 used for this purpose are known as the SS7 system that belongs to 382 the Common Channel Signalling (CCS) philosophy. The SS7 protocol 383 stack is depicted below: 385 +------+-----+-------+- -+-------+------+-----+------+ 386 | | | | | | MAP | CAP | INAP | 387 + | + RANAP |...| BSSAP +-------------------+ 388 | ISUP | TUP | | | | TCAP | 389 + | +---------------------------------------+ 390 | | | SCCP | 391 +----------------------------------------------------+ 392 | MTP3 | 393 +----------------------------------------------------+ 394 | MTP2 | 395 +----------------------------------------------------+ 396 | MTP1 | 397 +----------------------------------------------------+ 399 The Telephony Signalling Protocols to be transported with the already 400 designed UALS are: 402 - ISDN Q.921 Users: Q.931 403 - V5.2/DSS1 404 - DPNSS/DASS2 405 - SS7 MTP3 Users: SCCP, ISUP, TUP 406 - SS7 MTP2 Users: MTP3 407 - SS7 SCCP Users: TCAP, RANAP, BSSAP, ... 409 Two main scenarios have been developed to use the different UALS for 410 IP Signalling Transport: 412 Draft Telephony signalling over SCTP AS January 2003 414 (1) Intercommunication of traditional Signalling transport nodes and 415 IP based nodes. 417 Traditional Telephony 418 Telephony Signalling 419 ********* Signalling ********** over IP ******** 420 * SEP *----------------* SG *--------------* ISEP * 421 ********* ********** ******** 423 +-------+ +-------+ 424 |SigProt| |SigProt| 425 +-------+ +----+----+ +-------+ 426 | | | |UAL | | UAL | 427 | | | +----+ +-------+ 428 | TTST | |TTST|SCTP| | SCTP | 429 | | | +----+ +-------+ 430 | | | | IP | | IP | 431 +-------+ +---------+ +-------+ 433 SEP - Signalling Endpoint 434 SG - Signalling Gateway 435 ISEP - IP Signalling Endpoint 436 SigProt - Signalling Protocol 437 TTST - Traditional Telephony Signalling Transport 438 UAL - User Adaptation Layer 439 SCTP - Stream Control Transport Protocol 441 It is also referred as SG to AS communication. AS I the name that 442 UAL usually gives to the ISEP nodes. It stands for Application 443 Server. 445 (2) Communication inside the IP network. 447 Telephony 448 Signalling 449 ********* over IP ********* 450 * ISEP *------------------* ISEP * 451 ********* ********* 453 +-------+ +-------+ 454 |SigProt| |SigProt| 455 +-------+ +-------+ 456 | UAL | | UAL | 457 +-------+ +-------+ 458 | SCTP | | SCTP | 459 +-------+ +-------+ 460 | IP | | IP | 461 +-------+ +-------+ 463 This is also referred to as IPSP communication. IPSP is the name 465 Draft Telephony signalling over SCTP AS January 2003 467 of the role that an UAL plays on an IP-based node. It stands for 468 IP Signalling Point. 470 The first scenario is applied for both types of signalling (access 471 and trunk signalling). On the other hand the peer to peer basis can 472 only be used for trunk signalling. 474 4.1 Access Signalling 476 The SIGTRAN WG have developed UALs to transport the following Access 477 Signalling protocols: 479 - ISDN Q.931 480 - V5.2 481 - DPNSS/DASS2 483 4.1.1 ISDN Q.931 over IP 485 UAL: IUA (ISDN Q.921 User Adaptation) 487 This document supports both ISDN Primary Rate Access (PRA) as well as 488 Basic Rate Access (BRA) including the support for both point-to-point 489 and point-to-multipoint modes of communication. This support 490 includes Facility Associated Signalling (FAS), Non-Facility 491 Associated Signalling (NFAS) and NFAS with backup D channel. 493 It implements the client/server architecture. The default orientation 494 would be for the SG to take on the role of server while the ISEP is 495 the client. The SCTP (and UDP/TCP) Registered User Port Number 496 Assignment for IUA is 9900. 498 Examples of the upper layers to be transported would be Q.931 and 499 QSIG. 501 The main scenario supported by this UAL is the SG to ISEP 502 communication where the ISEP role is typically played by a node 503 called MGC defined in [RFC2719]. 505 ****** ISDN ****** IP ******* 506 *PBX *---------------* SG *--------------* MGC * 507 ****** ****** ******* 509 +-----+ +-----+ 510 |Q.931| (NIF) |Q.931| 511 +-----+ +----------+ +-----+ 512 | | | | IUA| | IUA | 513 | | | +----+ +-----+ 514 |Q.921| |Q.921|SCTP| |SCTP | 515 | | | +----+ +-----+ 516 | | | | IP | | IP | 517 +-----+ +-----+----+ +-----+ 519 Draft Telephony signalling over SCTP AS January 2003 521 NIF - Nodal Interworking Function 522 PBX - Private Branch Exchange 523 SCTP - Stream Control Transmission Protocol 524 IUA - ISDN User Adaptation Layer Protocol 526 The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA 527 is 9900. 529 The value assigned by IANA for the Payload Protocol Identifier in the 530 SCTP Payload Data chunk is �1� 532 4.1.2 V5UA over IP 534 UAL: V5UA (V5.2-User Adaptation) 536 It is an extension from the IUA layer with the modifications needed 537 to support the differences between Q.921 / Q.931, and V5.2 layer 2 / 538 layer 3. It supports analog telephone access, ISDN basic rate access 539 and ISDN primary rate access over a V5.2 interface. It is basically 540 implemented in an interworking scenario with SG. 542 ****** V5.2 ****** IP ******* 543 * AN *---------------* SG *--------------* MGC * 544 ****** ****** ******* 546 +-----+ +-----+ 547 |V5.2 | (NIF) |V5.2 | 548 +-----+ +----------+ +-----+ 549 | | | |V5UA| |V5UA | 550 | | | +----+ +-----+ 551 |LAPV5| |LAPV5|SCTP| |SCTP | 552 | | | +----+ +-----+ 553 | | | | IP + | IP | 554 +-----+ +-----+----+ +-----+ 556 AN � Access Network 557 NIF � Nodal Interworking Function 558 LAPV5 � Link Access Protocol for the V5 channel 559 SCTP - Stream Control Transmission Protocol 561 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 562 V5UA is 5675. 564 Draft Telephony signalling over SCTP AS January 2003 566 The value assigned by IANA for the Payload Protocol Identifier in the 567 SCTP Payload Data chunk is "6". 569 4.1.3 DPNSS/DASS2 over IP 571 UAL: DUA (DPNSS/DASS2 User Adaptation) 573 The DUA is built on top of IUA defining the necessary extensions to 574 IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private 575 Network Signalling System and DASS2 for Digital Access Signalling 576 System No 2 578 ****** DPNSS ****** IP ******* 579 *PBX *---------------* SG *--------------* MGC * 580 ****** ****** ******* 582 +-----+ +-----+ 583 |DPNSS| (NIF) |DPNSS| 584 | L3 | | L3 | 585 +-----+ +-----+----+ +-----+ 586 | | | | DUA| | DUA | 587 |DPNSS| |DPNSS+----+ +-----+ 588 | L2 | | L2 |SCTP| |SCTP | 589 | | | +----+ +-----+ 590 | | | | IP + | IP | 591 +-----+ +-----+----+ +-----+ 593 PBX - Private Branch eXchange 594 NIF - Nodal Interworking function 595 SCTP - Stream Control Transmission Protocol 596 DUA - DPNSS User Adaptation Layer Protocol 598 The value assigned by IANA for the Payload Protocol Identifier in the 599 SCTP Payload Data chunk is "TBD". 601 4.2 Network Signalling 603 The SIGTRAN WG have developed UALs to transport the following SS7 604 protocols: 606 - MTP2 Users: MTP3 607 - MTP3 Users: ISUP, TUP, SCCP 608 - SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ... 610 4.2.1 MTP lvl3 over IP 612 Draft Telephony signalling over SCTP AS January 2003 614 UALs: 616 - M2UA (SS7 MTP2 User Adaptation) 617 - M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) 619 4.2.1.1 M2UA (SS7 MTP2 User Adaptation) 621 M2UA protocol is mainly used between a Signalling Gateway (SG) and 622 Media Gateway Controller (MGC). The SG will terminate up to MTP Level 623 2 and the MGC will terminate MTP Level 3 and above. In other words, 624 the SG will transport MTP Level 3 messages over an IP network to a 625 MGC. 627 The only SS7 MTP2 User is MTP3 that is the protocol transported by 628 this UAL. 630 The SG provides a interworking of transport functions with the IP 631 transport, in order to transfer the MTP2-User signalling messages to 632 and from an Application Server (e.g. MGC) where the peer MTP2- 633 User protocol layer exists. 635 ****** SS7 ****** IP ******* 636 *SEP *-----------* SG *-------------* MGC * 637 ****** ****** ******* 639 +----+ +----+ 640 |S7UP| |S7UP| 641 +----+ +----+ 642 |MTP3| |MTP3| 643 | | (NIF) | | 644 +----+ +----+----+ +----+ 645 | | | |M2UA| |M2UA| 646 | | | +----+ +----+ 647 |MTP2| |MTP2|SCTP| |SCTP| 648 | | | +----+ +----+ 649 | | | |IP | |IP | 650 +----+ +---------+ +----+ 652 MGC - Media Gateway Controler 653 SG - Signalling Gateway 654 SEP - SS7 Signalling Endpoint 655 NIF - Nodal Interworking Function 656 IP - Internet Protocol 657 SCTP - Stream Control Transmission Protocol 659 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 660 M2UA is 2904. 662 Draft Telephony signalling over SCTP AS January 2003 664 The value assigned by IANA for the Payload Protocol Identifier in the 665 SCTP Payload Data chunk is "2" 667 4.2.1.2 M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer 669 M2PA protocol is used between SS7 Signalling Points employing the MTP 670 Level 3 protocol. The SS7 Signalling Points may also employ standard 671 SS7 links using the SS7 MTP Layer 2 to provide transport of MTP Layer 672 3 signalling messages. 674 Both configurations: intercommunication of SS7 and IP with SG and 675 communication between ISEPs are possible. 677 Communication between two IP nodes: 679 ******** IP ******** 680 * IPSP *--------* IPSP * 681 ******** ******** 683 +------+ +------+ 684 | TCAP | | TCAP | 685 +------+ +------+ 686 | SCCP | | SCCP | 687 +------+ +------+ 688 | MTP3 | | MTP3 | 689 +------+ +------+ 690 | M2PA | | M2PA | 691 +------+ +------+ 692 | SCTP | | SCTP | 693 +------+ +------+ 694 | IP | | IP | 695 +------+ +------+ 697 IP - Internet Protocol 698 IPSP - IP Signalling Point 699 SCTP - Stream Control Transmission Protocol 701 Interconnection of SS7 and IP nodes: 703 Draft Telephony signalling over SCTP AS January 2003 705 ******** SS7 *************** IP ******** 706 * SEP *--------* SG *--------* IPSP * 707 ******** *************** ******** 709 +------+ +------+ 710 | TCAP | | TCAP | 711 +------+ +------+ 712 | SCCP | | SCCP | 713 +------+ +-------------+ +------+ 714 | MTP3 | | MTP3 | | MTP3 | 715 +------+ +------+------+ +------+ 716 | | | | M2PA | | M2PA | 717 | | | +------+ +------+ 718 | MTP2 | | MTP2 | SCTP | | SCTP | 719 | | | +------+ +------+ 720 | | | | IP | | IP | 721 +------+ +------+------+ +------+ 723 SEP - SS7 Signalling Endpoint 725 These figures are only an example. Other configurations are possible. 726 For example, IPSPs without traditional SS7 links could use the 727 protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network 728 with all IP links. 730 Another example is that two SGs could be connected over an IP network 731 to form an SG mated pair similar to the way STPs are provisioned in 732 traditional SS7 networks. 734 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 735 M2PA is TBD. 737 The value assigned by IANA for the Payload Protocol Identifier in the 738 SCTP Payload Data chunk is TBD 740 4.2.1.3 Main differences between M2PA and M2UA: 742 a. M2PA: IPSP processes MTP3/MTP2 primitives. 743 M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 744 and the MGC's MTP3 (via the NIF) for processing. 746 b. M2PA: SG-IPSP connection is an SS7 link. 747 M2UA: SG-MGC connection is not an SS7 link. It is an 748 extension of MTP to a remote entity. 750 c. M2PA: SG is an SS7 node with a point code. 751 M2UA: SG is not an SS7 node and has no point code. 753 d. M2PA: SG can have upper SS7 layers, e.g., SCCP. 754 M2UA: SG does not have upper SS7 layers since it has no MTP3. 756 Draft Telephony signalling over SCTP AS January 2003 758 e. M2PA: relies on MTP3 for management procedures. 759 M2UA: uses M2UA management procedures. 761 4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP 763 UAL: M3UA (SS7 MTP3 User Adaptation) 765 M3UA protocol supports the transport of any SS7 MTP3-User signalling 766 such as TUP, ISUP and SCCP over IP using the services of SCTP. 768 Interconnection of SS7 and IP nodes: 770 ******** SS7 ***************** IP ******** 771 * SEP *---------* SGP *--------* ASP * 772 ******** ***************** ******** 774 +------+ +---------------+ +------+ 775 | ISUP | | (NIF) | | ISUP | 776 +------+ +------+ +------+ +------+ 777 | MTP3 | | MTP3 | | M3UA | | M3UA | 778 +------| +------+-+------+ +------+ 779 | MTP2 | | MTP2 | | SCTP | | SCTP | 780 +------+ +------+ +------+ +------+ 781 | L1 | | L1 | | IP | | IP | 782 +------+ +------+ +------+ +------+ 784 SEP - SS7 Signalling End Point 785 SCTP - Stream Control Transmission Protocol 786 NIF - Nodal Interworking Function 788 Communication between two IP nodes: 790 Draft Telephony signalling over SCTP AS January 2003 792 ******** IP ******** 793 * IPSP *----------* IPSP * 794 ******** ******** 796 +------+ +------+ 797 |SCCP- | |SCCP- | 798 | User | | User | 799 +------+ +------+ 800 | SCCP | | SCCP | 801 +------+ +------+ 802 | M3UA | | M3UA | 803 +------+ +------+ 804 | SCTP | | SCTP | 805 +------+ +------+ 806 | IP | | IP | 807 +------+ +------+ 809 It works using the client-server philosophy. ISEP is recommended to 810 be client when talking with a SG. The reserved port by IANA is 2905 811 to listen to possible client connections. 813 The assigned payload protocol identifier for the SCTP DATA chunks is 814 �3�. 816 4.4 SCCP-Users over IP 818 UAL: SUA (SS7 SCCP User Adaptation) 820 SUA protocol supports the transport of any SS7 SCCP-User signalling 821 such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of 822 SCTP. SUA can support only non-call related signalling. 824 SUA does not pose stringent timing constraints on SCTP due to the 825 fact that SUA applications have broad timing requirement (from 10 of 826 seconds to hours) which the applications guard themselves and the 827 timing supervision of the application is end-to-end, not hop-by- 828 hop(as with ISUP). 830 Possible configurations are showed in the pictures below. 832 - Interconnection of SS7 and IP: 834 Draft Telephony signalling over SCTP AS January 2003 836 ******** *************** ******** 837 * SEP * IP * * IP * * 838 * or *---------* SG *--------* ASP * 839 * STP * * * * * 840 ******** *************** ******** 842 +------ +------+ 843 | SUAP | | SUAP | 844 +------+ +------+------+ +------+ 845 | SCCP | | SCCP | SUA | | SUA | 846 +------+ +------+------+ +------+ 847 | | | | | | | 848 | MTP3 | | MTP3 | SCTP | | SCTP | 849 | | | | | | | 850 +------+ +------+------+ +------+ 851 | MTP2 | | MTP2 | IP | | IP | 852 +------+ +------+------+ +------+ 854 SUAP - SCCP/SUA User Protocol (TCAP, for example) 855 STP - SS7 Signalling Transfer Point 857 - IP Node to IP Node communication: 859 ******** ******** 860 * * IP * * 861 * IPSP *--------* IPSP * 862 * * * * 863 ******** ******** 865 +------+ +------+ 866 | SUAP | | SUAP | 867 +------+ +------+ 868 | SUA | | SUA | 869 +------+ +------+ 870 | SCTP | | SCTP | 871 +------+ +------+ 872 | IP | | IP | 873 +------+ +------+ 875 IANA has registered SCTP Port Number 14001 for SUA. It is 876 recommended that SGs use this SCTP port number for listening for new 877 connections. The payload protocol identifier for the SCTP DATA chunks 878 is "4". 880 Draft Telephony signalling over SCTP AS January 2003 882 5 Security considerations 884 UALs are designated to carry signalling messages for telephony 885 services. As such, UALs must involve the security needs of several 886 parties: the end users of the services; the network providers and 887 the applications involved. Additional requirements may come from 888 local regulation. While having some overlapping security needs, any 889 security solution should fulfill all of the different parties' 890 needs. See specific Security considerations in each UAL technical 891 specification. 893 SCTP only tries to increase the availability of a network. SCTP does 894 not contain any protocol mechanisms which are directly related to 895 communication security, i.e. user message authentication, integrity 896 or confidentiality functions. For such features, it depends on 897 security protocols. In the field of system security, SCTP includes 898 mechanisms for reducing the risk of blind denial-of-service attacks 899 as it is described in section 11 in RFC2960. 901 This document does not add any new components to the protocols 902 included in the discussion. For secure use of the SIGTRAN protocols 903 the readers should go through the "Security Considerations for 904 SIGTRAN protocols" [RFCSIGSEC]). According to that document, the use 905 of the IPsec is the main recommendation to secure SIGTRAN protocols 906 in the Internet, but TLS is also considered as a perfectly valid 907 option to be used in certain scenarios. Recomendations of usage are 908 also included. 910 6 References and related work 912 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 913 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 914 L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 915 October 2000. 917 [RF3257] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, 918 R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., 919 "Stream Control Transmission Protocol Applicability statement", 920 RFC3257, April 2002. 922 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 923 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 924 Architecture for Signalling Transport", RFC2719, October 1999. 926 Draft Telephony signalling over SCTP AS January 2003 928 [RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., 929 "ISDN Q.921-User Adaptation Layer", RFC3057, February 2001. 931 [RFC3331] Morneault, K., Dantu, R., Sidebottom, G., George, T., 932 Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer 933 Part (MTP) 2 - User Adaptation Layer", RFC3331, September 2002. 935 [RFC3332] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau, 936 G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K., 937 Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User 938 Adaptation Layer (M3UA)", RFC3332, September 2002. 940 [RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S., 941 Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss, 942 S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz, 943 May 2002. 945 [RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., 946 Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation 947 Layer", RFCwwww, June 2002. 949 [RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User 950 Adaptation Layer (V5UA)", RFCqqqq, June 2002 952 [RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault, 953 K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, August 954 2002. 956 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 957 Network Path Properties", Proc. SIGCOMM'99, 1999. 959 [RFCSIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J.,"Security 960 Considerations for SIGTRAN Protocols", 961 draft-ietf-sigtran-security-00.txt, work in progress 963 7 Acknowledgments 965 This document was initially developed by a design team consisting of 966 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 967 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 968 Jungmaier, Gery Verwimp and Lyndon Ong. 970 Draft Telephony signalling over SCTP AS January 2003 972 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, 973 G. Sidebottom, K. Morneault, T. George, M. Stillman and many others 974 for their invaluable comments. 976 8 Author's Address 978 Lode Coene Phone: +32-14-252081 979 Siemens Atea EMail: lode.coene@siemens.com 980 Atealaan 34 981 B-2200 Herentals 982 Belgium 984 Javier Pastor-Balbas Phone: +34-91-3393819 985 Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com- 986 C/ Retama 1 987 28045 Madrid 988 Spain 990 Full Copyright Statement 992 Copyright (C) The Internet Society (2003). All Rights Reserved. 994 This document and translations of it may be copied and furnished 995 to others, and derivative works that comment on or otherwise 996 explain it or assist in its implementation may be prepared, 997 copied, published and distributed, in whole or in part, without 998 restriction of any kind, provided that the above copyright notice 999 and this paragraph are included on all such copies and derivative 1000 works. However, this document itself may not be modified in any 1001 way, such as by removing the copyright notice or references to the 1002 Internet Society or other Internet organizations, except as needed 1003 for the purpose of developing Internet standards in which case the 1004 procedures for copyrights defined in the Internet Standards 1005 process must be followed, or as required to translate it into 1006 languages other than English. 1008 The limited permissions granted above are perpetual and will not 1009 be revoked by the Internet Society or its successors or assigns. 1011 This document and the information contained herein is provided on 1012 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1013 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1014 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1015 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1016 Draft Telephony signalling over SCTP AS January 2003 1018 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1020 -