idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-06.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 921 looks like a reference -- Missing reference section? 'RFC2960' on line 911 looks like a reference -- Missing reference section? 'ALLMAN99' on line 956 looks like a reference -- Missing reference section? 'RF3257' on line 916 looks like a reference -- Missing reference section? 'RFC3057' on line 925 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 (==), 13 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: November 2002 J. Pastor 5 Expires: May 2003 Ericsson 7 Telephony Signalling Transport over SCTP applicability statement 8 draft-ietf-sigtran-signalling-over-sctp-applic-06.txt 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 Draft Telephony Signalling AS October 2002 40 Table of contents 42 Telephony signalling over SCTP Applicability statement ......... ii 43 Chapter 1: Introduction ........................................ 2 44 Chapter 1.1: Scope ..... ....................................... 3 45 Chapter 1.2: Terminology ....................................... 3 46 Chapter 1.3: Contributors ...................................... 3 47 Chapter 2: SIGTRAN architecture ................................ 4 48 Chapter 2.1: Overview ......................................... 4 49 Chapter 3: Issues for transporting Telephony signalling 50 information over SCTP .......................................... 6 51 Chapter 3.1: Congestion control ................................ 6 52 Chapter 3.2: Detection of failures ............................. 6 53 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 7 54 Chapter 3.2.2: Heartbeat ....................................... 7 55 Chapter 3.2.3: Maximum Number of retransmissions ............... 7 56 Chapter 3.3: Shorten end-to-end message delay ................. 7 57 Chapter 3.4: Bundling considerations ........................... 8 58 Chapter 3.5: Stream Usage ...................................... 8 59 Chapter 4: User Adaptation Layers............................... 8 60 Chapter 4.1: Access Signalling.................................. 11 61 Chapter 4.1.1: IUA (ISDN Q.921 User Adaptation) ................ 11 62 Chapter 4.1.2: V5UA (V5.2-User Adaptation) Layer ............... 12 63 Chapter 4.1.3: DUA (DPNSS/DASS User adaptation) Layer .......... 13 64 Chapter 4.2: Network Signalling ................................ 13 65 Chapter 4.2.1: MTP lvl3 over IP ................................ 14 66 Chapter 4.2.1.1: M2UA (SS7 MTP2-User Adaptation) Layer ......... 14 67 Chapter 4.2.1.2: M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) .. 15 68 Chapter 4.2.1.3: Main difference between M2PA and M2UA ......... 16 69 Chapter 4.2.2: M3UA (SS7 MTP3 User Adaptation) Layer ........... 17 70 Chapter 4.2.3: SUA (SS7 SCCP User Adaptation) Layer ............ 18 71 Chapter 5: Security considerations ............................. 20 72 Chapter 6: References and related work ......................... 20 73 Chapter 7: Acknowledgments ..................................... 21 74 Chapter 8: Author's address .................................... 22 76 1 INTRODUCTION 77 Draft Telephony Signalling AS October 2002 79 This document intends to inform how to transport telephony 80 signalling protocols, used in classic telephony systems, over IP 81 networks. The whole architecture is called SIGTRAN (Signalling 82 Transport) as described in RFC2719 and is composed of a transport 83 protocol(SCTP) and several User Adaptation layers(UAL). The 84 transport protocol SCTP has been been developed to fulfill the 85 stringent requirements that telephony signalling networks have. The 86 set of User Adaptation layers have also been introduced to make it 87 possible that different signalling protocols can use the SCTP layer. 89 1.1 Scope 91 The scope of this document is to explain the way that user 92 adaptation layers and SCTP protocols have to be used to transport 93 Telephony signalling information over IP. 95 1.2 Terminology 97 The following terms are commonly identified in related work: 99 Association: SCTP connection between two endpoints. 101 Stream: A uni-directional logical channel established within an 102 association, within which all user messages are delivered in 103 sequence except for those submitted to the unordered delivery 104 service. 106 SPU: Signalling protocol user, the application on top of the User 107 adaptation layer. 109 CTSP: Classical Telephony Signalling protocol(examples: MTP level2, 110 MTP level 3, SCCP....). 112 UAL: User adaptation layer: the protocol that encapsulate the upper 113 layer telephony signalling protocols that are to be transported over 114 SCTP/IP. 116 ISEP: IP signalling endpoint: a IP node that implements SCTP and a 117 User adapatation layer. 119 SP: signalling point 121 1.3 Contributors 122 Draft Telephony Signalling AS October 2002 124 The following people contributed to the document: L. Coene(Editor), 125 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 126 M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong. 128 2 SIGTRAN architecture 130 The SIGTRAN architecture describes the transport of signalling 131 information over IP infrastructure. 133 Telephony Signalling transport over IP normally uses the following 134 architecture: 136 Telephony Signalling Application 137 | 138 +------------------------------------+ 139 | Signalling Adaptation Layers | 140 +------------------------------------+ 141 | 142 +------------------------------------+ 143 |Stream Control Transmission Protocol| 144 | (SCTP) | 145 +------------------------------------+ 146 | 147 Internet Protocol (IPv4/IPv6) 149 Figure 1.1: Telephony signalling transport protocol stack 151 The components of the protocol stack are : 153 (1) Adaptation modules are used when the telephony application needs 154 to preserve an existing primitive interface. (e.g. management 155 indications, data operation primitives, ... for a particular 156 user/application protocol). 158 (2) SCTP, specially configured to meet the telephony application 159 performance requirements. 161 (3) The standard Internet Protocol. 163 The telephony signalling protocols to be transported can be: 165 - SS7 MTP3 users: SCCP, ISUP, TUP... 167 - SS7 MTP2 users: MTP3 169 - SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 171 Draft Telephony Signalling AS October 2002 173 - ISDN Q.921 users: Q.931 175 - V5.2/DSS1 177 - .... 179 Every classic telephony protocol can have a corresponding UAL 180 developed. 182 The user adaptation layers(UALs) are a set of protocols that 183 encapsulate a specific signalling protocol to be transported over 184 SCTP. The adapation is done in a way that the upper signalling 185 protocols that are relayed remain unaware that the lower layers are 186 different to the originail lower telephony signalling layers. In 187 that sense, the upper interface of the user adapatation layers need 188 to be the same as the upper layer interface to its original lower 189 layer. If a MTP user is being relayed over the IP network, the 190 related UAL used to transport the MTP user will have the same upper 191 interface as MTP has. 193 The Stream Control Transmission protocol was designed to fulfill the 194 stringent transport requirements that classical signalling protocols 195 have and is therefore the recommended transport protocol to use for 196 this purpose. 198 The following functions are provided by SCTP: 200 - Reliable Data Transfer 202 - Multiple streams to help avoid head-of-line blocking 204 - Ordered and unordered data delivery on a per-stream basis 206 - Bundling and fragmentation of user data 208 - Congestion and flow control 210 - Support continuous monitoring of reachability 212 - Graceful termination of association 214 - Support of multi-homing for added reliability 216 - Protection against blind denial-of-service attacks 218 - Protection against blind masquerade attacks 220 SCTP is used as the transport protocol for telephony signalling 221 applications. Message boundaries are preserved during data 222 transport by SCTP and so each UAL can specify its own message 223 structure withing the SCTP user data. The SCTP user data can be 224 delivered by the order of transmission within a stream(in sequence 225 delivery) or unordered. 227 Draft Telephony Signalling AS October 2002 229 SCTP can be used to provide redundancy at the 230 transport layer and below. Telephony applications needing this level 231 of redundancy can make use of SCTP's multi-homing support. 233 SCTP can be used for telephony applications where head-of-line 234 blocking is a concern. Such an application should use multiple 235 streams to provide independent ordering of telephony signalling 236 messages. 238 3 Issues for transporting telephony signalling over SCTP 240 Transport of telephony signalling requires special 241 considerations. In order to use SCTP, special care must be taken to 242 meet the performance, timing and failure management requirements. 244 3.1 Congestion Control 246 The basic mechanism of congestion control in SCTP have been 247 described in [RFC2960]. SCTP congestion control sometimes conflicts 248 with the timing requirements of telephony signalling application 249 messages which are transported by SCTP. During congestion, messages 250 may be delayed by SCTP, thus sometimes violating the timing 251 requirements of those telephony applications. 253 In an engineered network (e.g. a private intranet), in which network 254 capacity and maximum traffic are very well understood, some 255 telephony signalling applications may choose to relax the congestion 256 control rules of SCTP in order to satisfy the timing 257 requirements. In order to do this, they should employ their own 258 congestion control mechanisms. But this should be done without 259 destabilising the network, otherwise this would lead to potential 260 congestion collapse of the network. 262 Some telephony signalling applications may have their own congestion 263 control and flow control techniques. These techniques may interact 264 with the congestion control procedures in SCTP. 266 3.2 Detection of failures 268 Telephony systems often must have no single point of failure in 269 operation. 271 The UAL must meet certain service availability and performance 272 requirements according to the classical signalling layers they are 274 Draft Telephony Signalling AS October 2002 276 replacing. Those requirements may be specific for each UAL. 278 For example, telephony systems are often required to be able to 279 preserve stable calls during a component failure. Therefore error 280 situations at the transport layer and below must be detected quickly 281 so that the UAL can take approriate steps to recover and preserve the 282 calls. This poses special requirements on SCTP to discover 283 unreachablility of a destination address or a peer. 285 3.2.1 Retransmission TimeOut (RTO) calculation 287 The SCTP protocol parameter RTO.Min value has a direct impact on the 288 calculation of the RTO itself. Some telephony applications want to 289 lower the value of the RTO.Min to less than 1 second. This would 290 allow the message sender to reach the maximum 291 number-of-retransmission threshold faster in the case of network 292 failures. However, lowering RTO.Min may have a negative impact on 293 network behaviour [ALLMAN99]. 295 In some rare cases, telephony applications might not want to use the 296 exponential timer back-off concept in RTO calculation in order to 297 speed up failure detection. The danger of doing this is that, when 298 network congestion occurs, not backing off the timer may worsen the 299 congestion situation. Therefore, this strategy should never be used 300 in public Internet. 302 It should be noted that not using delayed SACK will also help faster 303 failure detection. 305 3.2.2 Heartbeat 307 For faster detection of (un)availability of idle paths, the 308 telephony application may consider lowering the SCTP parameter 309 HB.interval. It should be noted this might result in a higher traffic 310 load. 312 3.2.3 Maximum number of retransmissions 314 Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters 315 to lower values will speed up both destination address and peer 316 failure detection. However, if these values are set too low, the 317 probability of false fault detections might increase. 319 Draft Telephony Signalling AS October 2002 321 3.3 Shorten end-to-end message delay 323 Telephony applications often require short end-to-end message 324 delays. The method described in section 3.2.1 on lowering RTO may 325 be considered. The different paths within a single association will 326 have a different RTO, so using the path with the lowest RTO will 327 lead to a shorter end-to-end message delay for the application 328 running on top of the UAL's. 330 3.4 Bundling considerations 332 Bundling small telephony signalling messages at transmission helps 333 improve the bandwidth usage efficiency of the network. On the 334 downside, bundling may introduce additional delay to some of the 335 messages. This should be taken into consideration when end-to-end 336 delay is a concern. 338 3.5 Stream Usage 340 Telephony signalling traffic is often composed of multiple, 341 independent message sequences. It is highly desirable to transfer 342 those independent message sequences in separate SCTP streams. This 343 reduces the probability of head-of-line blocking in which the 344 retransmission of a lost message affects the delivery of other 345 messages not belonging to the same message sequence. 347 4. User Adaptation Layers 349 Users Adaptation Layers (UALs) are defined to encapsulate different 350 signalling protocols in order to transport them over SCTP/IP 352 There are UALs for both access signalling (DSS1) and trunk signalling 353 (SS7). A brief description of the standardized UALs follows in the 354 next sub-sections. 356 The delivery mechanism in the several UALs 358 - Supports seamless operation of UALs user peers over an IP 359 network connection. 361 - Supports the interface boundary that the UAL user had with the 362 traditional lower layer. 364 Draft Telephony Signalling AS October 2002 366 - Supports management of SCTP transport associations and traffic 367 between SGs and ISEPs or two ISEPs 369 - Supports asynchronous reporting of status changes to management. 371 Signalling User Adaptation Layers have been developed for both: 372 Access and Trunk Telephony Signalling. They are defined as follows. 374 Access Signalling: This is the signalling that is needed between and 375 access device and an exchange in the core network in order to 376 establish, manage or release the voice or data call paths. There 377 are several protocols that have been developed for this purpose. 379 Trunk Signalling: This is the signalling that is used between the 380 exchanges inside the core network in order to establish, manage or 381 release the voice or data call paths. The most common protocols 382 used for this purpose are known as the SS7 system that belongs to 383 the Common Channel Signalling (CCS) philosophy. The SS7 protocol 384 stack is depicted below: 386 +------+-----+-------+- -+-------+------+-----+------+ 387 | | | | | | MAP | CAP | INAP | 388 + | + RANAP |...| BSSAP +-------------------+ 389 | ISUP | TUP | | | | TCAP | 390 + | +---------------------------------------+ 391 | | | SCCP | 392 +----------------------------------------------------+ 393 | MTP3 | 394 +----------------------------------------------------+ 395 | MTP2 | 396 +----------------------------------------------------+ 397 | MTP1 | 398 +----------------------------------------------------+ 400 The Telephony Signalling Protocols to be transported with the already 401 designed UALS are: 403 - ISDN Q.921 Users: Q.931 404 - V5.2/DSS1 405 - DPNSS/DASS2 406 - SS7 MTP3 Users: SCCP, ISUP, TUP 407 - SS7 MTP2 Users: MTP3 408 - SS7 SCCP Users: TCAP, RANAP, BSSAP, ... 410 Two main scenarios have been developed to use the different UALS for 411 IP Signalling Transport: 413 Draft Telephony Signalling AS October 2002 415 (1) Intercommunication of traditional Signalling transport nodes and 416 IP based nodes. 418 Traditional Telephony 419 Telephony Signalling 420 ********* Signalling ********** over IP ******** 421 * SEP *----------------* SG *--------------* ISEP * 422 ********* ********** ******** 424 +-------+ +-------+ 425 |SigProt| |SigProt| 426 +-------+ +----+----+ +-------+ 427 | | | |UAL | | UAL | 428 | | | +----+ +-------+ 429 | TTST | |TTST|SCTP| | SCTP | 430 | | | +----+ +-------+ 431 | | | | IP | | IP | 432 +-------+ +---------+ +-------+ 434 SEP - Signalling Endpoint 435 SG - Signalling Gateway 436 ISEP - IP Signalling Endpoint 437 SigProt - Signalling Protocol 438 TTST - Traditional Telephony Signalling Transport 439 UAL - User Adaptation Layer 440 SCTP - Stream Control Transport Protocol 442 It is also referred as SG to AS communication. AS I the name that 443 UAL usually gives to the ISEP nodes. It stands for Application 444 Server. 446 (2) Communication inside the IP network. 448 Telephony 449 Signalling 450 ********* over IP ********* 451 * ISEP *------------------* ISEP * 452 ********* ********* 454 +-------+ +-------+ 455 |SigProt| |SigProt| 456 +-------+ +-------+ 457 | UAL | | UAL | 458 +-------+ +-------+ 459 | SCTP | | SCTP | 460 +-------+ +-------+ 461 | IP | | IP | 462 +-------+ +-------+ 464 This is also referred to as IPSP communication. IPSP is the name 466 Draft Telephony Signalling AS October 2002 468 of the role that an UAL plays on an IP-based node. It stands for 469 IP Signalling Point. 471 The first scenario is applied for both types of signalling (access 472 and trunk signalling). On the other hand the peer to peer basis can 473 only be used for trunk signalling. 475 4.1 Access Signalling 477 The SIGTRAN WG have developed UALs to transport the following Access 478 Signalling protocols: 480 - ISDN Q.931 481 - V5.2 482 - DPNSS/DASS2 484 4.1.1 ISDN Q.931 over IP 486 UAL: IUA (ISDN Q.921 User Adaptation) 488 This document supports both ISDN Primary Rate Access (PRA) as well as 489 Basic Rate Access (BRA) including the support for both point-to-point 490 and point-to-multipoint modes of communication. This support 491 includes Facility Associated Signalling (FAS), Non-Facility 492 Associated Signalling (NFAS) and NFAS with backup D channel. 494 It implements the client/server architecture. The default orientation 495 would be for the SG to take on the role of server while the ISEP is 496 the client. The SCTP (and UDP/TCP) Registered User Port Number 497 Assignment for IUA is 9900. 499 Examples of the upper layers to be transported would be Q.931 and 500 QSIG. 502 The main scenario supported by this UAL is the SG to ISEP 503 communication where the ISEP role is typically played by a node 504 called MGC defined in [RFC2719]. 506 ****** ISDN ****** IP ******* 507 *PBX *---------------* SG *--------------* MGC * 508 ****** ****** ******* 510 +-----+ +-----+ 511 |Q.931| (NIF) |Q.931| 512 +-----+ +----------+ +-----+ 513 | | | | IUA| | IUA | 514 | | | +----+ +-----+ 515 |Q.921| |Q.921|SCTP| |SCTP | 516 | | | +----+ +-----+ 517 | | | | IP | | IP | 518 +-----+ +-----+----+ +-----+ 520 Draft Telephony Signalling AS October 2002 522 NIF - Nodal Interworking Function 523 PBX - Private Branch Exchange 524 SCTP - Stream Control Transmission Protocol 525 IUA - ISDN User Adaptation Layer Protocol 527 The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA 528 is 9900. 530 The value assigned by IANA for the Payload Protocol Identifier in the 531 SCTP Payload Data chunk is �1� 533 4.1.2 V5UA over IP 535 UAL: V5UA (V5.2-User Adaptation) 537 It is an extension from the IUA layer with the modifications needed 538 to support the differences between Q.921 / Q.931, and V5.2 layer 2 / 539 layer 3. It supports analog telephone access, ISDN basic rate access 540 and ISDN primary rate access over a V5.2 interface. It is basically 541 implemented in an interworking scenario with SG. 543 ****** V5.2 ****** IP ******* 544 * AN *---------------* SG *--------------* MGC * 545 ****** ****** ******* 547 +-----+ +-----+ 548 |V5.2 | (NIF) |V5.2 | 549 +-----+ +----------+ +-----+ 550 | | | |V5UA| |V5UA | 551 | | | +----+ +-----+ 552 |LAPV5| |LAPV5|SCTP| |SCTP | 553 | | | +----+ +-----+ 554 | | | | IP + | IP | 555 +-----+ +-----+----+ +-----+ 557 AN � Access Network 558 NIF � Nodal Interworking Function 559 LAPV5 � Link Access Protocol for the V5 channel 560 SCTP - Stream Control Transmission Protocol 562 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 563 V5UA is 5675. 565 Draft Telephony Signalling AS October 2002 567 The value assigned by IANA for the Payload Protocol Identifier in the 568 SCTP Payload Data chunk is "6". 570 4.1.3 DPNSS/DASS2 over IP 572 UAL: DUA (DPNSS/DASS2 User Adaptation) 574 The DUA is built on top of IUA defining the necessary extensions to 575 IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private 576 Network Signalling System and DASS2 for Digital Access Signalling 577 System No 2 579 ****** DPNSS ****** IP ******* 580 *PBX *---------------* SG *--------------* MGC * 581 ****** ****** ******* 583 +-----+ +-----+ 584 |DPNSS| (NIF) |DPNSS| 585 | L3 | | L3 | 586 +-----+ +-----+----+ +-----+ 587 | | | | DUA| | DUA | 588 |DPNSS| |DPNSS+----+ +-----+ 589 | L2 | | L2 |SCTP| |SCTP | 590 | | | +----+ +-----+ 591 | | | | IP + | IP | 592 +-----+ +-----+----+ +-----+ 594 PBX - Private Branch eXchange 595 NIF - Nodal Interworking function 596 SCTP - Stream Control Transmission Protocol 597 DUA - DPNSS User Adaptation Layer Protocol 599 The value assigned by IANA for the Payload Protocol Identifier in the 600 SCTP Payload Data chunk is "TBD". 602 4.2 Network Signalling 604 The SIGTRAN WG have developed UALs to transport the following SS7 605 protocols: 607 - MTP2 Users: MTP3 608 - MTP3 Users: ISUP, TUP, SCCP 609 - SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ... 611 4.2.1 MTP lvl3 over IP 613 Draft Telephony Signalling AS October 2002 615 UALs: 617 - M2UA (SS7 MTP2 User Adaptation) 618 - M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) 620 4.2.1.1 M2UA (SS7 MTP2 User Adaptation) 622 M2UA protocol is mainly used between a Signalling Gateway (SG) and 623 Media Gateway Controller (MGC). The SG will terminate up to MTP Level 624 2 and the MGC will terminate MTP Level 3 and above. In other words, 625 the SG will transport MTP Level 3 messages over an IP network to a 626 MGC. 628 The only SS7 MTP2 User is MTP3 that is the protocol transported by 629 this UAL. 631 The SG provides a interworking of transport functions with the IP 632 transport, in order to transfer the MTP2-User signalling messages to 633 and from an Application Server (e.g. MGC) where the peer MTP2- 634 User protocol layer exists. 636 ****** SS7 ****** IP ******* 637 *SEP *-----------* SG *-------------* MGC * 638 ****** ****** ******* 640 +----+ +----+ 641 |S7UP| |S7UP| 642 +----+ +----+ 643 |MTP3| |MTP3| 644 | | (NIF) | | 645 +----+ +----+----+ +----+ 646 | | | |M2UA| |M2UA| 647 | | | +----+ +----+ 648 |MTP2| |MTP2|SCTP| |SCTP| 649 | | | +----+ +----+ 650 | | | |IP | |IP | 651 +----+ +---------+ +----+ 653 MGC - Media Gateway Controler 654 SG - Signalling Gateway 655 SEP - SS7 Signalling Endpoint 656 NIF - Nodal Interworking Function 657 IP - Internet Protocol 658 SCTP - Stream Control Transmission Protocol 660 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 661 M2UA is 2904. 663 Draft Telephony Signalling AS October 2002 665 The value assigned by IANA for the Payload Protocol Identifier in the 666 SCTP Payload Data chunk is "2" 668 4.2.1.2 M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer 670 M2PA protocol is used between SS7 Signalling Points employing the MTP 671 Level 3 protocol. The SS7 Signalling Points may also employ standard 672 SS7 links using the SS7 MTP Layer 2 to provide transport of MTP Layer 673 3 signalling messages. 675 Both configurations: intercommunication of SS7 and IP with SG and 676 communication between ISEPs are possible. 678 Communication between two IP nodes: 680 ******** IP ******** 681 * IPSP *--------* IPSP * 682 ******** ******** 684 +------+ +------+ 685 | TCAP | | TCAP | 686 +------+ +------+ 687 | SCCP | | SCCP | 688 +------+ +------+ 689 | MTP3 | | MTP3 | 690 +------+ +------+ 691 | M2PA | | M2PA | 692 +------+ +------+ 693 | SCTP | | SCTP | 694 +------+ +------+ 695 | IP | | IP | 696 +------+ +------+ 698 IP - Internet Protocol 699 IPSP - IP Signalling Point 700 SCTP - Stream Control Transmission Protocol 702 Interconnection of SS7 and IP nodes: 704 Draft Telephony Signalling AS October 2002 706 ******** SS7 *************** IP ******** 707 * SEP *--------* SG *--------* IPSP * 708 ******** *************** ******** 710 +------+ +------+ 711 | TCAP | | TCAP | 712 +------+ +------+ 713 | SCCP | | SCCP | 714 +------+ +-------------+ +------+ 715 | MTP3 | | MTP3 | | MTP3 | 716 +------+ +------+------+ +------+ 717 | | | | M2PA | | M2PA | 718 | | | +------+ +------+ 719 | MTP2 | | MTP2 | SCTP | | SCTP | 720 | | | +------+ +------+ 721 | | | | IP | | IP | 722 +------+ +------+------+ +------+ 724 SEP - SS7 Signalling Endpoint 726 These figures are only an example. Other configurations are possible. 727 For example, IPSPs without traditional SS7 links could use the 728 protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network 729 with all IP links. 731 Another example is that two SGs could be connected over an IP network 732 to form an SG mated pair similar to the way STPs are provisioned in 733 traditional SS7 networks. 735 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 736 M2PA is TBD. 738 The value assigned by IANA for the Payload Protocol Identifier in the 739 SCTP Payload Data chunk is TBD 741 4.2.1.3 Main differences between M2PA and M2UA: 743 a. M2PA: IPSP processes MTP3/MTP2 primitives. 744 M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 745 and the MGC's MTP3 (via the NIF) for processing. 747 b. M2PA: SG-IPSP connection is an SS7 link. 748 M2UA: SG-MGC connection is not an SS7 link. It is an 749 extension of MTP to a remote entity. 751 c. M2PA: SG is an SS7 node with a point code. 752 M2UA: SG is not an SS7 node and has no point code. 754 d. M2PA: SG can have upper SS7 layers, e.g., SCCP. 755 M2UA: SG does not have upper SS7 layers since it has no MTP3. 757 Draft Telephony Signalling AS October 2002 759 e. M2PA: relies on MTP3 for management procedures. 760 M2UA: uses M2UA management procedures. 762 4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP 764 UAL: M3UA (SS7 MTP3 User Adaptation) 766 M3UA protocol supports the transport of any SS7 MTP3-User signalling 767 such as TUP, ISUP and SCCP over IP using the services of SCTP. 769 Interconnection of SS7 and IP nodes: 771 ******** SS7 ***************** IP ******** 772 * SEP *---------* SGP *--------* ASP * 773 ******** ***************** ******** 775 +------+ +---------------+ +------+ 776 | ISUP | | (NIF) | | ISUP | 777 +------+ +------+ +------+ +------+ 778 | MTP3 | | MTP3 | | M3UA | | M3UA | 779 +------| +------+-+------+ +------+ 780 | MTP2 | | MTP2 | | SCTP | | SCTP | 781 +------+ +------+ +------+ +------+ 782 | L1 | | L1 | | IP | | IP | 783 +------+ +------+ +------+ +------+ 785 SEP - SS7 Signalling End Point 786 SCTP - Stream Control Transmission Protocol 787 NIF - Nodal Interworking Function 789 Communication between two IP nodes: 791 Draft Telephony Signalling AS October 2002 793 ******** IP ******** 794 * IPSP *----------* IPSP * 795 ******** ******** 797 +------+ +------+ 798 |SCCP- | |SCCP- | 799 | User | | User | 800 +------+ +------+ 801 | SCCP | | SCCP | 802 +------+ +------+ 803 | M3UA | | M3UA | 804 +------+ +------+ 805 | SCTP | | SCTP | 806 +------+ +------+ 807 | IP | | IP | 808 +------+ +------+ 810 It works using the client-server philosophy. ISEP is recommended to 811 be client when talking with a SG. The reserved port by IANA is 2905 812 to listen to possible client connections. 814 The assigned payload protocol identifier for the SCTP DATA chunks is 815 �3�. 817 4.4 SCCP-Users over IP 819 UAL: SUA (SS7 SCCP User Adaptation) 821 SUA protocol supports the transport of any SS7 SCCP-User signalling 822 such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of 823 SCTP. SUA can support only non-call related signalling. 825 SUA does not pose stringent timing constraints on SCTP due to the 826 fact that SUA applications have broad timing requirement (from 10 of 827 seconds to hours) which the applications guard themselves and the 828 timing supervision of the application is end-to-end, not hop-by- 829 hop(as with ISUP). 831 Possible configurations are showed in the pictures below. 833 - Interconnection of SS7 and IP: 835 Draft Telephony Signalling AS October 2002 837 ******** *************** ******** 838 * SEP * IP * * IP * * 839 * or *---------* SG *--------* ASP * 840 * STP * * * * * 841 ******** *************** ******** 843 +------ +------+ 844 | SUAP | | SUAP | 845 +------+ +------+------+ +------+ 846 | SCCP | | SCCP | SUA | | SUA | 847 +------+ +------+------+ +------+ 848 | | | | | | | 849 | MTP3 | | MTP3 | SCTP | | SCTP | 850 | | | | | | | 851 +------+ +------+------+ +------+ 852 | MTP2 | | MTP2 | IP | | IP | 853 +------+ +------+------+ +------+ 855 SUAP - SCCP/SUA User Protocol (TCAP, for example) 856 STP - SS7 Signalling Transfer Point 858 - IP Node to IP Node communication: 860 ******** ******** 861 * * IP * * 862 * IPSP *--------* IPSP * 863 * * * * 864 ******** ******** 866 +------+ +------+ 867 | SUAP | | SUAP | 868 +------+ +------+ 869 | SUA | | SUA | 870 +------+ +------+ 871 | SCTP | | SCTP | 872 +------+ +------+ 873 | IP | | IP | 874 +------+ +------+ 876 IANA has registered SCTP Port Number 14001 for SUA. It is 877 recommended that SGs use this SCTP port number for listening for new 878 connections. The payload protocol identifier for the SCTP DATA chunks 879 is "4". 881 Draft Telephony Signalling AS October 2002 883 5 Security considerations 885 UALs are designated to carry signalling messages for telephony 886 services. As such, UALs must involve the security needs of several 887 parties: the end users of the services; the network providers and 888 the applications involved. Additional requirements may come from 889 local regulation. While having some overlapping security needs, any 890 security solution should fulfill all of the different parties' 891 needs. See specific Security considerations in each UAL technical 892 specification. 894 SCTP only tries to increase the availability of a network. SCTP does 895 not contain any protocol mechanisms which are directly related to 896 user message authentication, integrity and confidentiality 897 functions. For such features, it depends on the IPSEC protocols and 898 architecture and/or on security features of its user protocols. 900 Mechanisms for reducing the risk of blind denial-of-service attacks 901 and masquerade attacks are built into SCTP protocol. See RFC2960, 902 section 11 for detailed information. 904 Currently the IPSEC working group is investigating the support of 905 multihoming by IPSEC protocols. At the present time to use IPSEC, 906 one must use 2 * N * M security associations if one endpoint uses N 907 addresses and the other M addresses. 909 6 References and related work 911 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 912 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 913 L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 914 October 2000. 916 [RF3257] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, 917 R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., 918 "Stream Control Transmission Protocol Applicability statement", 919 RFC3257, April 2002. 921 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 922 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 923 Architecture for Signalling Transport", RFC2719, October 1999. 925 [RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., 927 Draft Telephony Signalling AS October 2002 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 7 Acknowledgments 961 This document was initially developed by a design team consisting of 962 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 963 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 964 Jungmaier, Gery Verwimp and Lyndon Ong. 966 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, 967 G. Sidebottom, K. Morneault, T. George, M. Stillman and many others 968 for their invaluable comments. 970 8 Author's Address 971 Draft Telephony Signalling AS October 2002 973 Lode Coene Phone: +32-14-252081 974 Siemens Atea EMail: lode.coene@siemens.atea.be 975 Atealaan 34 976 B-2200 Herentals 977 Belgium 979 Javier Pastor-Balbas Phone: 980 Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com 981 C/ Retama 1 982 28045 Madrid 983 Spain 985 Expires: August 2002 987 Full Copyright Statement 989 Copyright (C) The Internet Society (2002). All Rights Reserved. 991 This document and translations of it may be copied and furnished 992 to others, and derivative works that comment on or otherwise 993 explain it or assist in its implementation may be prepared, 994 copied, published and distributed, in whole or in part, without 995 restriction of any kind, provided that the above copyright notice 996 and this paragraph are included on all such copies and derivative 997 works. However, this document itself may not be modified in any 998 way, such as by removing the copyright notice or references to the 999 Internet Society or other Internet organizations, except as needed 1000 for the purpose of developing Internet standards in which case the 1001 procedures for copyrights defined in the Internet Standards 1002 process must be followed, or as required to translate it into 1003 languages other than English. 1005 The limited permissions granted above are perpetual and will not 1006 be revoked by the Internet Society or its successors or assigns. 1008 This document and the information contained herein is provided on 1009 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1010 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1011 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1012 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1013 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1015 Draft Telephony Signalling AS October 2002