idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-08.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 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 868 looks like a reference -- Missing reference section? 'RFC2960' on line 858 looks like a reference -- Missing reference section? 'ALLMAN99' on line 900 looks like a reference -- Missing reference section? 'RFCSIGSEC' on line 903 looks like a reference -- Missing reference section? 'RF3257' on line 863 looks like a reference -- Missing reference section? 'RFC3057' on line 872 looks like a reference -- Missing reference section? 'RFC3331' on line 875 looks like a reference -- Missing reference section? 'RFC3332' on line 879 looks like a reference -- Missing reference section? 'RFCzzzz' on line 884 looks like a reference -- Missing reference section? 'RFCwwww' on line 889 looks like a reference -- Missing reference section? 'RFCqqqq' on line 893 looks like a reference -- Missing reference section? 'RFCtttt' on line 896 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 14 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: March 2003 J. Pastor 5 Expires: September 2003 Ericsson 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 new protocols 32 developed under the signalling transport framework[RFC2719]. A 33 description of the main issues regarding the use of the Stream 34 Control Transmission Protocol (SCTP)[RFC2960] and each adaptation 35 layer for transport of telephony signalling information over IP 36 infrastructure is explained. 38 Table of contents 40 Telephony signalling over SCTP Applicability statement ......... ii 41 Chapter 1: Introduction ........................................ 3 42 Chapter 1.1: Scope ..... ....................................... 3 43 Chapter 1.2: Terminology ....................................... 3 44 Chapter 1.3: Contributors ...................................... 4 45 Chapter 2: SIGTRAN architecture ................................ 4 46 Chapter 2.1: Overview ......................................... 4 47 Chapter 3: Issues for transporting Telephony signalling 48 information over SCTP .......................................... 6 49 Chapter 3.1: Congestion control ................................ 6 50 Chapter 3.2: Detection of failures ............................. 6 51 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 7 52 Chapter 3.2.2: Heartbeat ....................................... 7 53 Chapter 3.2.3: Maximum Number of retransmissions ............... 7 54 Chapter 3.3: Shorten end-to-end message delay ................. 8 55 Chapter 3.4: Bundling considerations ........................... 8 56 Chapter 3.5: Stream Usage ...................................... 8 57 Chapter 4: User Adaptation Layers............................... 8 58 Chapter 4.1: Access Signalling.................................. 11 59 Chapter 4.1.1: IUA (ISDN Q.921 User Adaptation) ................ 11 60 Chapter 4.1.2: V5UA (V5.2-User Adaptation) Layer ............... 12 61 Chapter 4.1.3: DUA (DPNSS/DASS User adaptation) Layer .......... 13 62 Chapter 4.2: Network Signalling ................................ 14 63 Chapter 4.2.1: MTP lvl3 over IP ................................ 14 64 Chapter 4.2.1.1: M2UA (SS7 MTP2-User Adaptation) Layer ......... 14 65 Chapter 4.2.1.2: M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) .. 15 66 Chapter 4.2.1.3: Main difference between M2PA and M2UA ......... 16 67 Chapter 4.2.2: M3UA (SS7 MTP3 User Adaptation) Layer ........... 17 68 Chapter 4.2.3: SUA (SS7 SCCP User Adaptation) Layer ............ 18 69 Chapter 5: Security considerations ............................. 20 70 Chapter 6: References and related work ......................... 20 71 Chapter 7: Acknowledgments ..................................... 21 72 Chapter 8: Author's address .................................... 22 74 1 INTRODUCTION 76 This document intends to inform how to transport telephony 77 signalling protocols, used in classic telephony systems, over IP 78 networks. The whole architecture is called SIGTRAN (Signalling 79 Transport) as described in RFC2719 and is composed of a transport 80 protocol(SCTP) and several User Adaptation layers(UAL). The 81 transport protocol SCTP has been been developed to fulfill the 82 stringent requirements that telephony signalling networks have. The 83 set of User Adaptation layers have also been introduced to make it 84 possible that different signalling protocols can use the SCTP layer. 86 1.1 Scope 88 The scope of this document is to explain the way that user 89 adaptation layers and SCTP protocols have to be used to transport 90 Telephony signalling information over IP. 92 1.2 Terminology 94 The following terms are commonly identified in related work: 96 Association: SCTP connection between two endpoints. 98 Stream: A uni-directional logical channel established within an 99 association, within which all user messages are delivered in 100 sequence except for those submitted to the unordered delivery 101 service. 103 SPU: Signalling protocol user, the application on top of the User 104 adaptation layer. 106 CTSP: Classical Telephony Signalling protocol(examples: MTP level2, 107 MTP level 3, SCCP....). 109 UAL: User adaptation layer: the protocol that encapsulate the upper 110 layer telephony signalling protocols that are to be transported over 111 SCTP/IP. 113 ISEP: IP signalling endpoint: a IP node that implements SCTP and a 114 User adapatation layer. 116 SP: signalling point 118 1.3 Contributors 120 The following people contributed to the document: L. Coene(Editor), 121 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 122 M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong. 124 2 SIGTRAN architecture 126 The SIGTRAN architecture describes the transport of signalling 127 information over IP infrastructure. 129 Telephony Signalling transport over IP normally uses the following 130 architecture: 132 Telephony Signalling Application 133 | 134 +------------------------------------+ 135 | Signalling Adaptation Layers | 136 +------------------------------------+ 137 | 138 +------------------------------------+ 139 |Stream Control Transmission Protocol| 140 | (SCTP) | 141 +------------------------------------+ 142 | 143 Internet Protocol (IPv4/IPv6) 145 Figure 1.1: Telephony signalling transport protocol stack 147 The components of the protocol stack are : 149 (1) Adaptation modules are used when the telephony application needs 150 to preserve an existing primitive interface. (e.g. management 151 indications, data operation primitives, ... for a particular 152 user/application protocol). 154 (2) SCTP, specially configured to meet the telephony application 155 performance requirements. 157 (3) The standard Internet Protocol. 159 The telephony signalling protocols to be transported can be: 161 - SS7 MTP3 users: SCCP, ISUP, TUP... 163 - SS7 MTP2 users: MTP3 164 - SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 166 - ISDN Q.921 users: Q.931 168 - V5.2/DSS1 170 - .... 172 Every classic telephony protocol can have a corresponding UAL 173 developed. 175 The user adaptation layers(UALs) are a set of protocols that 176 encapsulate a specific signalling protocol to be transported over 177 SCTP. The adapation is done in a way that the upper signalling 178 protocols that are relayed remain unaware that the lower layers are 179 different to the originail lower telephony signalling layers. In 180 that sense, the upper interface of the user adapatation layers need 181 to be the same as the upper layer interface to its original lower 182 layer. If a MTP user is being relayed over the IP network, the 183 related UAL used to transport the MTP user will have the same upper 184 interface as MTP has. 186 The Stream Control Transmission protocol was designed to fulfill the 187 stringent transport requirements that classical signalling protocols 188 have and is therefore the recommended transport protocol to use for 189 this purpose. 191 The following functions are provided by SCTP: 193 - Reliable Data Transfer 195 - Multiple streams to help avoid head-of-line blocking 197 - Ordered and unordered data delivery on a per-stream basis 199 - Bundling and fragmentation of user data 201 - Congestion and flow control 203 - Support continuous monitoring of reachability 205 - Graceful termination of association 207 - Support of multi-homing for added reliability 209 - Protection against blind denial-of-service attacks 211 - Protection against blind masquerade attacks 213 SCTP is used as the transport protocol for telephony signalling 214 applications. Message boundaries are preserved during data 215 transport by SCTP and so each UAL can specify its own message 216 structure within the SCTP user data. The SCTP user data can be 217 delivered by the order of transmission within a stream(in sequence 218 delivery) or unordered. 220 SCTP can be used to provide redundancy at the 221 transport layer and below. Telephony applications needing this level 222 of redundancy can make use of SCTP's multi-homing support. 224 SCTP can be used for telephony applications where head-of-line 225 blocking is a concern. Such an application should use multiple 226 streams to provide independent ordering of telephony signalling 227 messages. 229 3 Issues for transporting telephony signalling over SCTP 231 Transport of telephony signalling requires special 232 considerations. In order to use SCTP, special care must be taken to 233 meet the performance, timing and failure management requirements. 235 3.1 Congestion Control 237 The basic mechanism of congestion control in SCTP have been 238 described in [RFC2960]. SCTP congestion control sometimes conflicts 239 with the timing requirements of telephony signalling application 240 messages which are transported by SCTP. During congestion, messages 241 may be delayed by SCTP, thus sometimes violating the timing 242 requirements of those telephony applications. 244 In an engineered network (e.g. a private intranet), in which network 245 capacity and maximum traffic are very well understood, some 246 telephony signalling applications may choose to relax the congestion 247 control rules of SCTP in order to satisfy the timing 248 requirements. In order to do this, they should employ their own 249 congestion control mechanisms. But this should be done without 250 destabilising the network, otherwise this would lead to potential 251 congestion collapse of the network. 253 Some telephony signalling applications may have their own congestion 254 control and flow control techniques. These techniques may interact 255 with the congestion control procedures in SCTP. 257 3.2 Detection of failures 259 Telephony systems often must have no single point of failure in 260 operation. 262 The UAL must meet certain service availability and performance 263 requirements according to the classical signalling layers they are 264 replacing. Those requirements may be specific for each UAL. 266 For example, telephony systems are often required to be able to 267 preserve stable calls during a component failure. Therefore error 268 situations at the transport layer and below must be detected quickly 269 so that the UAL can take approriate steps to recover and preserve the 270 calls. This poses special requirements on SCTP to discover 271 unreachablility of a destination address or a peer. 273 3.2.1 Retransmission TimeOut (RTO) calculation 275 The SCTP protocol parameter RTO.Min value has a direct impact on the 276 calculation of the RTO itself. Some telephony applications want to 277 lower the value of the RTO.Min to less than 1 second. This would 278 allow the message sender to reach the maximum 279 number-of-retransmission threshold faster in the case of network 280 failures. However, lowering RTO.Min may have a negative impact on 281 network behaviour [ALLMAN99]. 283 In some rare cases, telephony applications might not want to use the 284 exponential timer back-off concept in RTO calculation in order to 285 speed up failure detection. The danger of doing this is that, when 286 network congestion occurs, not backing off the timer may worsen the 287 congestion situation. Therefore, this strategy should never be used 288 in public Internet. 290 It should be noted that not using delayed SACK will also help faster 291 failure detection. 293 3.2.2 Heartbeat 295 For faster detection of (un)availability of idle paths, the 296 telephony application may consider lowering the SCTP parameter 297 HB.interval. It should be noted this might result in a higher traffic 298 load. 300 3.2.3 Maximum number of retransmissions 302 Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters 303 to lower values will speed up both destination address and peer 304 failure detection. However, if these values are set too low, the 305 probability of false fault detections might increase. 307 3.3 Shorten end-to-end message delay 309 Telephony applications often require short end-to-end message 310 delays. The method described in section 3.2.1 on lowering RTO may 311 be considered. The different paths within a single association will 312 have a different RTO, so using the path with the lowest RTO will 313 lead to a shorter end-to-end message delay for the application 314 running on top of the UAL's. 316 3.4 Bundling considerations 318 Bundling small telephony signalling messages at transmission helps 319 improve the bandwidth usage efficiency of the network. On the 320 downside, bundling may introduce additional delay to some of the 321 messages. This should be taken into consideration when end-to-end 322 delay is a concern. 324 3.5 Stream Usage 326 Telephony signalling traffic is often composed of multiple, 327 independent message sequences. It is highly desirable to transfer 328 those independent message sequences in separate SCTP streams. This 329 reduces the probability of head-of-line blocking in which the 330 retransmission of a lost message affects the delivery of other 331 messages not belonging to the same message sequence. 333 4. User Adaptation Layers 335 Users Adaptation Layers (UALs) are defined to encapsulate different 336 signalling protocols in order to transport them over SCTP/IP 338 There are UALs for both access signalling (DSS1) and trunk signalling 339 (SS7). A brief description of the standardized UALs follows in the 340 next sub-sections. 342 The delivery mechanism in the several UALs 344 - Supports seamless operation of UALs user peers over an IP 345 network connection. 347 - Supports the interface boundary that the UAL user had with the 348 traditional lower layer. 350 - Supports management of SCTP transport associations and traffic 351 between SGs and ISEPs or two ISEPs 353 - Supports asynchronous reporting of status changes to management. 355 Signalling User Adaptation Layers have been developed for both: 356 Access and Trunk Telephony Signalling. They are defined as follows. 358 Access Signalling: This is the signalling that is needed between and 359 access device and an exchange in the core network in order to 360 establish, manage or release the voice or data call paths. There 361 are several protocols that have been developed for this purpose. 363 Trunk Signalling: This is the signalling that is used between the 364 exchanges inside the core network in order to establish, manage or 365 release the voice or data call paths. The most common protocols 366 used for this purpose are known as the SS7 system that belongs to 367 the Common Channel Signalling (CCS) philosophy. The SS7 protocol 368 stack is depicted below: 370 +------+-----+-------+- -+-------+------+-----+------+ 371 | | | | | | MAP | CAP | INAP | 372 + | + RANAP |...| BSSAP +-------------------+ 373 | ISUP | TUP | | | | TCAP | 374 + | +---------------------------------------+ 375 | | | SCCP | 376 +----------------------------------------------------+ 377 | MTP3 | 378 +----------------------------------------------------+ 379 | MTP2 | 380 +----------------------------------------------------+ 381 | MTP1 | 382 +----------------------------------------------------+ 384 The Telephony Signalling Protocols to be transported with the already 385 designed UALS are: 387 - ISDN Q.921 Users: Q.931 388 - V5.2/DSS1 389 - DPNSS/DASS2 390 - SS7 MTP3 Users: SCCP, ISUP, TUP 391 - SS7 MTP2 Users: MTP3 392 - SS7 SCCP Users: TCAP, RANAP, BSSAP, ... 394 Two main scenarios have been developed to use the different UALS for 395 IP Signalling Transport: 397 (1) Intercommunication of traditional Signalling transport nodes and 398 IP based nodes. 400 Traditional Telephony 401 Telephony Signalling 402 ********* Signalling ********** over IP ******** 403 * SEP *----------------* SG *--------------* ISEP * 404 ********* ********** ******** 406 +-------+ +-------+ 407 |SigProt| |SigProt| 408 +-------+ +----+----+ +-------+ 409 | | | |UAL | | UAL | 410 | | | +----+ +-------+ 411 | TTST | |TTST|SCTP| | SCTP | 412 | | | +----+ +-------+ 413 | | | | IP | | IP | 414 +-------+ +---------+ +-------+ 416 SEP - Signalling Endpoint 417 SG - Signalling Gateway 418 ISEP - IP Signalling Endpoint 419 SigProt - Signalling Protocol 420 TTSP - Traditional Telephony Signalling Protocol 421 UAL - User Adaptation Layer 422 SCTP - Stream Control Transport Protocol 424 It is also referred as SG to AS communication. AS is the name that 425 UAL usually gives to the ISEP nodes. It stands for Application 426 Server. 428 (2) Communication inside the IP network. 430 Telephony 431 Signalling 432 ********* over IP ********* 433 * ISEP *------------------* ISEP * 434 ********* ********* 436 +-------+ +-------+ 437 |SigProt| |SigProt| 438 +-------+ +-------+ 439 | UAL | | UAL | 440 +-------+ +-------+ 441 | SCTP | | SCTP | 442 +-------+ +-------+ 443 | IP | | IP | 444 +-------+ +-------+ 446 This is also referred to as IPSP communication. IPSP stands for IP 447 Signalling Point and describes the role that the UAL plays on a 448 IP-based node. 450 The first scenario is applied for both types of signalling (access 451 and trunk signalling). On the other hand the peer to peer basis can 452 only be used for trunk signalling. 454 4.1 Access Signalling 456 The SIGTRAN WG have developed UALs to transport the following Access 457 Signalling protocols: 459 - ISDN Q.931 460 - V5.2 461 - DPNSS/DASS2 463 4.1.1 ISDN Q.931 over IP 465 UAL: IUA (ISDN Q.921 User Adaptation) 467 This document supports both ISDN Primary Rate Access (PRA) as well as 468 Basic Rate Access (BRA) including the support for both point-to-point 469 and point-to-multipoint modes of communication. This support 470 includes Facility Associated Signalling (FAS), Non-Facility 471 Associated Signalling (NFAS) and NFAS with backup D channel. 473 It implements the client/server architecture. The default orientation 474 is for the SG to take on the role of server while the ISEP is 475 the client. The SCTP (and UDP/TCP) Registered User Port Number 476 Assignment for IUA is 9900. 478 Examples of the upper layers to be transported are Q.931 and QSIG. 480 The main scenario supported by this UAL is the SG to ISEP 481 communication where the ISEP role is typically played by a node 482 called an MGC, as defined in [RFC2719]. 484 ****** ISDN ****** IP ******* 485 *PBX *---------------* SG *--------------* MGC * 486 ****** ****** ******* 488 +-----+ +-----+ 489 |Q.931| (NIF) |Q.931| 490 +-----+ +----------+ +-----+ 491 | | | | IUA| | IUA | 492 | | | +----+ +-----+ 493 |Q.921| |Q.921|SCTP| |SCTP | 494 | | | +----+ +-----+ 495 | | | | IP | | IP | 496 +-----+ +-----+----+ +-----+ 497 NIF - Nodal Interworking Function 498 PBX - Private Branch Exchange 499 SCTP - Stream Control Transmission Protocol 500 IUA - ISDN User Adaptation Layer Protocol 502 The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA 503 is 9900. 505 The value assigned by IANA for the Payload Protocol Identifier in the 506 SCTP Payload Data chunk is "1". 508 4.1.2 V5UA over IP 510 UAL: V5UA (V5.2-User Adaptation) 512 It is an extension from the IUA layer with the modifications needed 513 to support the differences between Q.921 / Q.931, and V5.2 layer 2 / 514 layer 3. It supports analog telephone access, ISDN basic rate access 515 and ISDN primary rate access over a V5.2 interface. It is typically 516 implemented in an interworking scenario with SG. 518 ****** V5.2 ****** IP ******* 519 * AN *---------------* SG *--------------* MGC * 520 ****** ****** ******* 522 +-----+ +-----+ 523 |V5.2 | (NIF) |V5.2 | 524 +-----+ +----------+ +-----+ 525 | | | |V5UA| |V5UA | 526 | | | +----+ +-----+ 527 |LAPV5| |LAPV5|SCTP| |SCTP | 528 | | | +----+ +-----+ 529 | | | | IP + | IP | 530 +-----+ +-----+----+ +-----+ 532 AN - Access Network 533 NIF - Nodal Interworking Function 534 LAPV5 - Link Access Protocol for the V5 channel 535 SCTP - Stream Control Transmission Protocol 537 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 538 V5UA is 5675. 540 The value assigned by IANA for the Payload Protocol Identifier in the 541 SCTP Payload Data chunk is "6". 543 4.1.3 DPNSS/DASS2 over IP 545 UAL: DUA (DPNSS/DASS2 User Adaptation) 547 The DUA is built on top of IUA and defines the necessary extensions 548 to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private 549 Network Signalling System and DASS2 for Digital Access Signalling 550 System No 2. 552 ****** DPNSS ****** IP ******* 553 *PBX *---------------* SG *--------------* MGC * 554 ****** ****** ******* 556 +-----+ +-----+ 557 |DPNSS| (NIF) |DPNSS| 558 | L3 | | L3 | 559 +-----+ +-----+----+ +-----+ 560 | | | | DUA| | DUA | 561 |DPNSS| |DPNSS+----+ +-----+ 562 | L2 | | L2 |SCTP| |SCTP | 563 | | | +----+ +-----+ 564 | | | | IP + | IP | 565 +-----+ +-----+----+ +-----+ 567 PBX - Private Branch eXchange 568 NIF - Nodal Interworking function 569 SCTP - Stream Control Transmission Protocol 570 DUA - DPNSS User Adaptation Layer Protocol 572 The value assigned by IANA for the Payload Protocol Identifier in the 573 SCTP Payload Data chunk is "10". 575 4.2 Network Signalling 577 The SIGTRAN WG have developed UALs to transport the following SS7 578 protocols: 580 - MTP2 Users: MTP3 581 - MTP3 Users: ISUP, TUP, SCCP 582 - SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ... 584 4.2.1 MTP lvl3 over IP 586 UALs: 588 - M2UA (SS7 MTP2 User Adaptation) 589 - M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) 591 4.2.1.1 M2UA (SS7 MTP2 User Adaptation) 593 M2UA protocol is typically used between a Signalling Gateway (SG) 594 and Media Gateway Controller (MGC). The SG will terminate up to MTP 595 Level 2 and the MGC will terminate MTP Level 3 and above. In other 596 words, the SG will transport MTP Level 3 messages over an IP network 597 to a MGC. 599 MTP3 and MTP3b are the the only SS7 MTP2 User protocols that is 600 transported by this UAL. 602 The SG provides a interworking of transport functions with the IP 603 transport to transfer MTP2-User signalling messages with an 604 Application Server (e.g. MGC) where the peer MTP2-User exists. 606 ****** SS7 ****** IP ******* 607 *SEP *-----------* SG *-------------* MGC * 608 ****** ****** ******* 610 +----+ +----+ 611 |S7UP| |S7UP| 612 +----+ +----+ 613 |MTP3| |MTP3| 614 | | (NIF) | | 615 +----+ +----+----+ +----+ 616 | | | |M2UA| |M2UA| 617 | | | +----+ +----+ 618 |MTP2| |MTP2|SCTP| |SCTP| 619 | | | +----+ +----+ 620 | | | |IP | |IP | 621 +----+ +---------+ +----+ 622 MGC - Media Gateway Controler 623 SG - Signalling Gateway 624 SEP - SS7 Signalling Endpoint 625 NIF - Nodal Interworking Function 626 IP - Internet Protocol 627 SCTP - Stream Control Transmission Protocol 629 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 630 M2UA is 2904. 632 The value assigned by IANA for the Payload Protocol Identifier in the 633 SCTP Payload Data chunk is "2". 635 4.2.1.2 M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer 637 M2PA protocol is used between SS7 Signalling Points employing the MTP 638 Level 3 protocol. The SS7 Signalling Points may also use standard 639 SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 640 3 signalling messages. 642 Both configurations: communication of SS7 and IP with SG and 643 communication between ISEPs are possible. 645 Communication between two IP nodes: 647 ******** IP ******** 648 * IPSP *--------* IPSP * 649 ******** ******** 651 +------+ +------+ 652 | TCAP | | TCAP | 653 +------+ +------+ 654 | SCCP | | SCCP | 655 +------+ +------+ 656 | MTP3 | | MTP3 | 657 +------+ +------+ 658 | M2PA | | M2PA | 659 +------+ +------+ 660 | SCTP | | SCTP | 661 +------+ +------+ 662 | IP | | IP | 663 +------+ +------+ 665 IP - Internet Protocol 666 IPSP - IP Signalling Point 667 SCTP - Stream Control Transmission Protocol 669 Connection of SS7 and IP nodes: 671 ******** SS7 *************** IP ******** 672 * SEP *--------* SG *--------* IPSP * 673 ******** *************** ******** 675 +------+ +------+ 676 | TCAP | | TCAP | 677 +------+ +------+ 678 | SCCP | | SCCP | 679 +------+ +-------------+ +------+ 680 | MTP3 | | MTP3 | | MTP3 | 681 +------+ +------+------+ +------+ 682 | | | | M2PA | | M2PA | 683 | | | +------+ +------+ 684 | MTP2 | | MTP2 | SCTP | | SCTP | 685 | | | +------+ +------+ 686 | | | | IP | | IP | 687 +------+ +------+------+ +------+ 689 SEP - SS7 Signalling Endpoint 691 These figures are only an example. Other configurations are possible. 692 For example, IPSPs without traditional SS7 links could use the 693 protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network 694 with all IP links. 696 Another example is that two SGs could be connected over an IP network 697 to form an SG mated pair similar to the way STPs are provisioned in 698 traditional SS7 networks. 700 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 701 M2PA is 3565. 703 The value assigned by IANA for the Payload Protocol Identifier in the 704 SCTP Payload Data chunk is "5". 706 4.2.1.3 Main differences between M2PA and M2UA: 708 a. M2PA: IPSP processes MTP3/MTP2 primitives. 709 M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 710 and the MGC's MTP3 (via the NIF) for processing. 712 b. M2PA: SG-IPSP connection is an SS7 link. 713 M2UA: SG-MGC connection is not an SS7 link. It is an 714 extension of MTP to a remote entity. 716 4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP 718 UAL: M3UA (SS7 MTP3 User Adaptation) 720 M3UA protocol supports the transport of any SS7 MTP3-User signalling 721 such as TUP, ISUP and SCCP over IP using the services of SCTP. 723 Interconnection of SS7 and IP nodes: 725 ******** SS7 ***************** IP ******** 726 * SEP *---------* SGP *--------* ASP * 727 ******** ***************** ******** 729 +------+ +---------------+ +------+ 730 | ISUP | | (NIF) | | ISUP | 731 +------+ +------+ +------+ +------+ 732 | MTP3 | | MTP3 | | M3UA | | M3UA | 733 +------| +------+-+------+ +------+ 734 | MTP2 | | MTP2 | | SCTP | | SCTP | 735 +------+ +------+ +------+ +------+ 736 | L1 | | L1 | | IP | | IP | 737 +------+ +------+ +------+ +------+ 739 SEP - SS7 Signalling End Point 740 SCTP - Stream Control Transmission Protocol 741 NIF - Nodal Interworking Function 743 Communication between two IP nodes: 745 ******** IP ******** 746 * IPSP *----------* IPSP * 747 ******** ******** 749 +------+ +------+ 750 |SCCP- | |SCCP- | 751 | User | | User | 752 +------+ +------+ 753 | SCCP | | SCCP | 754 +------+ +------+ 755 | M3UA | | M3UA | 756 +------+ +------+ 757 | SCTP | | SCTP | 758 +------+ +------+ 759 | IP | | IP | 760 +------+ +------+ 762 M3UA uses a client-server architecture. It is recommended that the 763 ISEP acts as the client and initiate the SCTP assocaitions with the 764 SG. The port reserved by IANA is 2905. This is the port upon which 765 the SG should listen for possible client connections. 767 The assigned payload protocol identifier for the SCTP DATA chunks is 768 "3". 770 4.4 SCCP-Users over IP 772 UAL: SUA (SS7 SCCP User Adaptation) 774 SUA protocol supports the transport of any SS7 SCCP-User signalling 775 such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of 776 SCTP. Each of the applications using SUA have their own set of 777 timing requirements that can be found in their respective 778 standards documents. 780 Possible configurations are showed in the pictures below. 782 - Interconnection of SS7 and IP: 784 ******** *************** ******** 785 * SEP * IP * * IP * * 786 * or *---------* SG *--------* ASP * 787 * STP * * * * * 788 ******** *************** ******** 790 +------ +------+ 791 | SUAP | | SUAP | 792 +------+ +------+------+ +------+ 793 | SCCP | | SCCP | SUA | | SUA | 794 +------+ +------+------+ +------+ 795 | | | | | | | 796 | MTP3 | | MTP3 | SCTP | | SCTP | 797 | | | | | | | 798 +------+ +------+------+ +------+ 799 | MTP2 | | MTP2 | IP | | IP | 800 +------+ +------+------+ +------+ 802 SUAP - SCCP/SUA User Protocol (TCAP, for example) 803 STP - SS7 Signalling Transfer Point 805 - IP Node to IP Node communication: 807 ******** ******** 808 * * IP * * 809 * IPSP *--------* IPSP * 810 * * * * 811 ******** ******** 813 +------+ +------+ 814 | SUAP | | SUAP | 815 +------+ +------+ 816 | SUA | | SUA | 817 +------+ +------+ 818 | SCTP | | SCTP | 819 +------+ +------+ 820 | IP | | IP | 821 +------+ +------+ 823 IANA has registered SCTP Port Number 14001 for SUA. It is 824 recommended that SGs use this SCTP port number for listening for new 825 connections. The payload protocol identifier for the SCTP DATA chunks 826 is "4". 828 5 Security considerations 830 UALs are designated to carry signalling messages for telephony 831 services. As such, UALs must involve the security needs of several 832 parties: the end users of the services; the network providers and 833 the applications involved. Additional requirements may come from 834 local regulation. While having some overlapping security needs, any 835 security solution should fulfill all of the different parties' 836 needs. See specific Security considerations in each UAL technical 837 specification. 839 SCTP only tries to increase the availability of a network. SCTP does 840 not contain any protocol mechanisms which are directly related to 841 communication security, i.e. user message authentication, integrity 842 or confidentiality functions. For such features, it depends on 843 security protocols. In the field of system security, SCTP includes 844 mechanisms for reducing the risk of blind denial-of-service attacks 845 as it is described in section 11 in RFC2960. 847 This document does not add any new components to the protocols 848 included in the discussion. For secure use of the SIGTRAN protocols 849 the readers should go through the "Security Considerations for 850 SIGTRAN protocols" [RFCSIGSEC]). According to that document, the use 851 of the IPsec is the main recommendation to secure SIGTRAN protocols 852 in the Internet, but TLS is also considered as a perfectly valid 853 option to be used in certain scenarios. Recomendations of usage are 854 also included. 856 6 References and related work 858 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 859 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 860 L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 861 October 2000. 863 [RF3257] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, 864 R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., 865 "Stream Control Transmission Protocol Applicability statement", 866 RFC3257, April 2002. 868 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 869 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 870 Architecture for Signalling Transport", RFC2719, October 1999. 872 [RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., 873 "ISDN Q.921-User Adaptation Layer", RFC3057, February 2001. 875 [RFC3331] Morneault, K., Dantu, R., Sidebottom, G., George, T., 876 Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer 877 Part (MTP) 2 - User Adaptation Layer", RFC3331, September 2002. 879 [RFC3332] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau, 880 G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K., 881 Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User 882 Adaptation Layer (M3UA)", RFC3332, September 2002. 884 [RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S., 885 Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss, 886 S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz, 887 May 2002. 889 [RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., 890 Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation 891 Layer", RFCwwww, June 2002. 893 [RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User 894 Adaptation Layer (V5UA)", RFCqqqq, June 2002 896 [RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault, 897 K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, August 898 2002. 900 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 901 Network Path Properties", Proc. SIGCOMM'99, 1999. 903 [RFCSIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J.,"Security 904 Considerations for SIGTRAN Protocols", 905 draft-ietf-sigtran-security-00.txt, work in progress 907 7 Acknowledgments 909 This document was initially developed by a design team consisting of 910 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 911 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 912 Jungmaier, Gery Verwimp and Lyndon Ong. 914 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, 915 G. Sidebottom, K. Morneault, T. George, M. Stillman, B. Bidulock 916 and many others for their invaluable comments. 918 8 Author's Address 920 Lode Coene Phone: +32-14-252081 921 Siemens Atea EMail: lode.coene@siemens.com 922 Atealaan 34 923 B-2200 Herentals 924 Belgium 926 Javier Pastor-Balbas Phone: +34-91-3393819 927 Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com- 928 C/ Retama 1 929 28045 Madrid 930 Spain 932 Full Copyright Statement 934 Copyright (C) The Internet Society (2003). All Rights Reserved. 936 This document and translations of it may be copied and furnished 937 to others, and derivative works that comment on or otherwise 938 explain it or assist in its implementation may be prepared, 939 copied, published and distributed, in whole or in part, without 940 restriction of any kind, provided that the above copyright notice 941 and this paragraph are included on all such copies and derivative 942 works. However, this document itself may not be modified in any 943 way, such as by removing the copyright notice or references to the 944 Internet Society or other Internet organizations, except as needed 945 for the purpose of developing Internet standards in which case the 946 procedures for copyrights defined in the Internet Standards 947 process must be followed, or as required to translate it into 948 languages other than English. 950 The limited permissions granted above are perpetual and will not 951 be revoked by the Internet Society or its successors or assigns. 953 This document and the information contained herein is provided on 954 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 955 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 956 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 957 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 958 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 960 -