idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-09.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 22 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) == Unused Reference: 'RF3257' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'RFC3057' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'RFC3331' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'RFC3332' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'RFCzzzz' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'RFCwwww' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFCqqqq' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'RFCtttt' is defined on line 942, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3057 (Obsoleted by RFC 4233) -- Obsolete informational reference (is this intentional?): RFC 3332 (Obsoleted by RFC 4666) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 5 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: August 2003 J. Pastor 5 Expires: February 2004 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 several 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 over SCTP AS February 2004 40 Table of contents 42 Telephony signalling over SCTP Applicability statement ......... ii 43 Chapter 1: Introduction ........................................ 3 44 Chapter 1.1: Scope ..... ....................................... 3 45 Chapter 1.2: Terminology ....................................... 3 46 Chapter 1.3: Contributors ...................................... 4 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 ................. 8 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 ................................ 14 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 6.1: Informative References ............................ 20 74 Chapter 7: Acknowledgments ..................................... 21 75 Chapter 8: Author's address .................................... 22 77 Draft Telephony Signalling over SCTP AS February 2004 79 1 INTRODUCTION 81 This document is intended to describe how to transport telephony 82 signalling protocols, used in classic telephony systems, over IP 83 networks. The whole architecture is called SIGTRAN (Signalling 84 Transport) as described in RFC2719 and is composed of a transport 85 protocol(SCTP) and several User Adaptation Layers(UAL). The 86 transport protocol SCTP has been developed to fulfill the stringent 87 requirements that telephony signalling networks have. The set of 88 User Adaptation Layers has also been introduced to make it possible 89 for different signalling protocols to use the SCTP layer. 91 1.1 Scope 93 The scope of this document is the Sigtran user adaptation layers and 94 SCTP protocols and how they are used to transport Telephony 95 signalling information over IP networks. 97 1.2 Terminology 99 The following terms are commonly identified in related work: 101 Association: SCTP connection between two endpoints. 103 Stream: A uni-directional logical channel established within an 104 association, within which all user messages are delivered in 105 sequence except for those submitted to the unordered delivery 106 service. 108 SPU: Signalling protocol user, the application on top of the User 109 adaptation layer. 111 CTSP: Classical Telephony Signalling protocol(examples: MTP level2, 112 MTP level 3, SCCP....). 114 UAL: User adaptation layer: the protocol that encapsulate the upper 115 layer telephony signalling protocols that are to be transported over 116 SCTP/IP. 118 ISEP: IP signalling endpoint: a IP node that implements SCTP and a 119 User adapatation layer. 121 SP: signalling point 123 Draft Telephony Signalling over SCTP AS February 2004 125 1.3 Contributors 127 The following people contributed to the document: L. Coene(Editor), 128 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 129 M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong. 131 2 SIGTRAN architecture 133 The SIGTRAN architecture describes the transport of signalling 134 information over IP infrastructure. 136 Telephony Signalling transport over IP normally uses the following 137 architecture: 139 Telephony Signalling Application 140 | 141 +------------------------------------+ 142 | Signalling Adaptation Layers | 143 +------------------------------------+ 144 | 145 +------------------------------------+ 146 |Stream Control Transmission Protocol| 147 | (SCTP) | 148 +------------------------------------+ 149 | 150 Internet Protocol (IPv4/IPv6) 152 Figure 1.1: Telephony signalling transport protocol stack 154 The components of the protocol stack are : 156 (1) Adaptation modules used when the telephony application needs 157 to preserve an existing primitive interface. (e.g. management 158 indications, data operation primitives, ... for a particular 159 user/application protocol). 161 (2) SCTP, specially configured to meet the telephony application 162 performance requirements. 164 (3) The standard Internet Protocol. 166 The telephony signalling protocols to be transported can be: 168 - SS7 MTP3 users: SCCP, ISUP, TUP... 170 - SS7 MTP2 users: MTP3 172 Draft Telephony Signalling over SCTP AS February 2004 174 - SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 176 - ISDN Q.921 users: Q.931 178 - V5.2/DSS1 180 - .... 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 for 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 within 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 over SCTP AS February 2004 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 controlled, 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 must 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 over SCTP AS February 2004 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 over SCTP AS February 2004 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 over SCTP AS February 2004 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 over SCTP AS February 2004 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 TTSP - Traditional Telephony Signalling Protocol 439 UAL - User Adaptation Layer 440 SCTP - Stream Control Transport Protocol 442 It is also referred as SG to AS communication. AS is 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 stands for IP 466 Draft Telephony Signalling over SCTP AS February 2004 468 Signalling Point and describes the role that the UAL plays on a 469 IP-based node. 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 is 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 are Q.931 and 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 an MGC, as 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 NIF - Nodal Interworking Function 521 Draft Telephony Signalling over SCTP AS February 2004 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 V5UA 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 typically 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 The value assigned by IANA for the Payload Protocol Identifier in the 567 Draft Telephony Signalling over SCTP AS February 2004 569 SCTP Payload Data chunk is "6". 571 4.1.3 DPNSS/DASS2 over IP 573 UAL: DUA (DPNSS/DASS2 User Adaptation) 575 The DUA is built on top of IUA and defines the necessary extensions 576 to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private 577 Network Signalling System and DASS2 for Digital Access Signalling 578 System No 2. 580 ****** DPNSS ****** IP ******* 581 *PBX *---------------* SG *--------------* MGC * 582 ****** ****** ******* 584 +-----+ +-----+ 585 |DPNSS| (NIF) |DPNSS| 586 | L3 | | L3 | 587 +-----+ +-----+----+ +-----+ 588 | | | | DUA| | DUA | 589 |DPNSS| |DPNSS+----+ +-----+ 590 | L2 | | L2 |SCTP| |SCTP | 591 | | | +----+ +-----+ 592 | | | | IP + | IP | 593 +-----+ +-----+----+ +-----+ 595 PBX - Private Branch eXchange 596 NIF - Nodal Interworking function 597 SCTP - Stream Control Transmission Protocol 598 DUA - DPNSS User Adaptation Layer Protocol 600 The value assigned by IANA for the Payload Protocol Identifier in the 601 SCTP Payload Data chunk is "10". 603 Draft Telephony Signalling over SCTP AS February 2004 605 4.2 Network Signalling 607 The SIGTRAN WG have developed UALs to transport the following SS7 608 protocols: 610 - MTP2 Users: MTP3 611 - MTP3 Users: ISUP, TUP, SCCP 612 - SCCP Users: TCAP, RNSAP, RANAP, BSSAP, ... 614 4.2.1 MTP lvl3 over IP 616 UALs: 618 - M2UA (SS7 MTP2 User Adaptation) 619 - M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) 621 4.2.1.1 M2UA (SS7 MTP2 User Adaptation) 623 M2UA protocol is typically used between a Signalling Gateway (SG) 624 and Media Gateway Controller (MGC). The SG will terminate up to MTP 625 Level 2 and the MGC will terminate MTP Level 3 and above. In other 626 words, the SG will transport MTP Level 3 messages over an IP network 627 to a MGC. 629 MTP3 and MTP3b are the only SS7 MTP2 User protocols that are 630 transported by this UAL. 632 The SG provides a interworking of transport functions with the IP 633 transport to transfer MTP2-User signalling messages with an 634 Application Server (e.g. MGC) where the peer MTP2-User 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 655 Draft Telephony Signalling over SCTP AS February 2004 657 SG - Signalling Gateway 658 SEP - SS7 Signalling Endpoint 659 NIF - Nodal Interworking Function 660 IP - Internet Protocol 661 SCTP - Stream Control Transmission Protocol 663 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 664 M2UA is 2904. 666 The value assigned by IANA for the Payload Protocol Identifier in the 667 SCTP Payload Data chunk is "2". 669 4.2.1.2 M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer 671 M2PA protocol is used between SS7 Signalling Points employing the MTP 672 Level 3 protocol. The SS7 Signalling Points may also use standard 673 SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 674 3 signalling messages. 676 Both configurations: communication of SS7 and IP with SG and 677 communication between ISEPs are possible. 679 Communication between two IP nodes: 681 ******** IP ******** 682 * IPSP *--------* IPSP * 683 ******** ******** 685 +------+ +------+ 686 | TCAP | | TCAP | 687 +------+ +------+ 688 | SCCP | | SCCP | 689 +------+ +------+ 690 | MTP3 | | MTP3 | 691 +------+ +------+ 692 | M2PA | | M2PA | 693 +------+ +------+ 694 | SCTP | | SCTP | 695 +------+ +------+ 696 | IP | | IP | 697 +------+ +------+ 699 IP - Internet Protocol 700 IPSP - IP Signalling Point 701 SCTP - Stream Control Transmission Protocol 703 Draft Telephony Signalling over SCTP AS February 2004 705 Connection of SS7 and IP nodes: 707 ******** SS7 *************** IP ******** 708 * SEP *--------* SG *--------* IPSP * 709 ******** *************** ******** 711 +------+ +------+ 712 | TCAP | | TCAP | 713 +------+ +------+ 714 | SCCP | | SCCP | 715 +------+ +-------------+ +------+ 716 | MTP3 | | MTP3 | | MTP3 | 717 +------+ +------+------+ +------+ 718 | | | | M2PA | | M2PA | 719 | | | +------+ +------+ 720 | MTP2 | | MTP2 | SCTP | | SCTP | 721 | | | +------+ +------+ 722 | | | | IP | | IP | 723 +------+ +------+------+ +------+ 725 SEP - SS7 Signalling Endpoint 727 These figures are only an example. Other configurations are possible. 728 For example, IPSPs without traditional SS7 links could use the 729 protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network 730 with all IP links. 732 Another example is that two SGs could be connected over an IP network 733 to form an SG mated pair similar to the way STPs are provisioned in 734 traditional SS7 networks. 736 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 737 M2PA is 3565. 739 The value assigned by IANA for the Payload Protocol Identifier in the 740 SCTP Payload Data chunk is "5". 742 4.2.1.3 Main differences between M2PA and M2UA: 744 a. M2PA: IPSP processes MTP3/MTP2 primitives. 745 M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 746 and the MGC's MTP3 (via the NIF) for processing. 748 b. M2PA: SG-IPSP connection is an SS7 link. 749 M2UA: SG-MGC connection is not an SS7 link. It is an 750 extension of MTP to a remote entity. 752 Draft Telephony Signalling over SCTP AS February 2004 754 4.3 MTP lvl3-Users (ISUP, TUP, SCCP) over IP 756 UAL: M3UA (SS7 MTP3 User Adaptation) 758 M3UA protocol supports the transport of any SS7 MTP3-User signalling 759 such as TUP, ISUP and SCCP over IP using the services of SCTP. 761 Interconnection of SS7 and IP nodes: 763 ******** SS7 ***************** IP ******** 764 * SEP *---------* SGP *--------* ASP * 765 ******** ***************** ******** 767 +------+ +---------------+ +------+ 768 | ISUP | | (NIF) | | ISUP | 769 +------+ +------+ +------+ +------+ 770 | MTP3 | | MTP3 | | M3UA | | M3UA | 771 +------| +------+-+------+ +------+ 772 | MTP2 | | MTP2 | | SCTP | | SCTP | 773 +------+ +------+ +------+ +------+ 774 | L1 | | L1 | | IP | | IP | 775 +------+ +------+ +------+ +------+ 777 SEP - SS7 Signalling End Point 778 SCTP - Stream Control Transmission Protocol 779 NIF - Nodal Interworking Function 781 Draft Telephony Signalling over SCTP AS February 2004 783 Communication between two IP nodes: 785 ******** IP ******** 786 * IPSP *----------* IPSP * 787 ******** ******** 789 +------+ +------+ 790 |SCCP- | |SCCP- | 791 | User | | User | 792 +------+ +------+ 793 | SCCP | | SCCP | 794 +------+ +------+ 795 | M3UA | | M3UA | 796 +------+ +------+ 797 | SCTP | | SCTP | 798 +------+ +------+ 799 | IP | | IP | 800 +------+ +------+ 802 M3UA uses a client-server architecture. It is recommended that the 803 ISEP acts as the client and initiate the SCTP assocaitions with the 804 SG. The port reserved by IANA is 2905. This is the port upon which 805 the SG should listen for possible client connections. 807 The assigned payload protocol identifier for the SCTP DATA chunks is 808 "3". 810 4.4 SCCP-Users over IP 812 UAL: SUA (SS7 SCCP User Adaptation) 814 SUA protocol supports the transport of any SS7 SCCP-User signalling 815 such as MAP, INAP, SMS, BSSAP, RANAP over IP using the services of 816 SCTP. Each of the applications using SUA has their own set of 817 timing requirements that can be found in their respective 818 standards documents. 820 Possible configurations are showed in the pictures below. 822 Draft Telephony Signalling over SCTP AS February 2004 824 - Interconnection of SS7 and IP: 826 ******** *************** ******** 827 * SEP * IP * * IP * * 828 * or *---------* SG *--------* ASP * 829 * STP * * * * * 830 ******** *************** ******** 832 +------ +------+ 833 | SUAP | | SUAP | 834 +------+ +------+------+ +------+ 835 | SCCP | | SCCP | SUA | | SUA | 836 +------+ +------+------+ +------+ 837 | | | | | | | 838 | MTP3 | | MTP3 | SCTP | | SCTP | 839 | | | | | | | 840 +------+ +------+------+ +------+ 841 | MTP2 | | MTP2 | IP | | IP | 842 +------+ +------+------+ +------+ 844 SUAP - SCCP/SUA User Protocol (TCAP, for example) 845 STP - SS7 Signalling Transfer Point 847 - IP Node to IP Node communication: 849 ******** ******** 850 * * IP * * 851 * IPSP *--------* IPSP * 852 * * * * 853 ******** ******** 855 +------+ +------+ 856 | SUAP | | SUAP | 857 +------+ +------+ 858 | SUA | | SUA | 859 +------+ +------+ 860 | SCTP | | SCTP | 861 +------+ +------+ 862 | IP | | IP | 863 +------+ +------+ 865 IANA has registered SCTP Port Number 14001 for SUA. It is 866 recommended that SGs use this SCTP port number for listening for new 867 connections. The payload protocol identifier for the SCTP DATA chunks 868 is "4". 870 Draft Telephony Signalling over SCTP AS February 2004 872 5 Security considerations 874 UALs are designated to carry signalling messages for telephony 875 services. As such, UALs must involve the security needs of several 876 parties: the end users of the services; the network providers and 877 the applications involved. Additional requirements may come from 878 local regulation. While having some overlapping security needs, any 879 security solution should fulfill all of the different parties' 880 needs. See specific Security considerations in each UAL technical 881 specification for details. 883 SCTP only tries to increase the availability of a network. SCTP does 884 not contain any protocol mechanisms which are directly related to 885 communication security, i.e. user message authentication, integrity 886 or confidentiality functions. For such features, it depends on 887 security protocols. In the field of system security, SCTP includes 888 mechanisms for reducing the risk of blind denial-of-service attacks 889 as it is described in section 11 in RFC2960. 891 This document does not add any new components to the protocols 892 included in the discussion. For secure use of the SIGTRAN protocols 893 the readers should go through the "Security Considerations for 894 SIGTRAN protocols" [RFCSIGSEC]). According to that document, the use 895 of the IPsec is the main requirement to secure SIGTRAN protocols 896 in the Internet, but TLS is also considered as a perfectly valid 897 option to be used in certain scenarios. Recomendations of usage are 898 also included. 900 6 References and related work 902 6.1 Informative References 904 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 905 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 906 L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 907 October 2000. 909 [RF3257] Coene, L., "Stream Control Transmission Protocol 910 Applicability statement", RFC3257, April 2002. 912 Draft Telephony Signalling over SCTP AS February 2004 914 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 915 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 916 Architecture for Signalling Transport", RFC2719, October 1999. 918 [RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., 919 "ISDN Q.921-User Adaptation Layer", RFC3057, February 2001. 921 [RFC3331] Morneault, K., Dantu, R., Sidebottom, G., George, T., 922 Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer 923 Part (MTP) 2 - User Adaptation Layer", RFC3331, September 2002. 925 [RFC3332] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau, 926 G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K., 927 Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User 928 Adaptation Layer (M3UA)", RFC3332, September 2002. 930 [RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S., 931 Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss, 932 S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz, 933 Sept 2003. 935 [RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., 936 Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation 937 Layer", RFCwwww, Sept 2003. 939 [RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User 940 Adaptation Layer (V5UA)", RFCqqqq, Sept 2003 942 [RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault, 943 K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, Sept 944 2003. 946 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 947 Network Path Properties", Proc. SIGCOMM'99, 1999. 949 [RFCSIGSEC] Loughney, J., Tuexen, M. and Pastor-Balbas, J.,"Security 950 Considerations for SIGTRAN Protocols", 951 draft-ietf-sigtran-security-03.txt, work in progress, Sept 2003 953 7 Acknowledgments 955 This document was initially developed by a design team consisting of 956 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 958 Draft Telephony Signalling over SCTP AS February 2004 960 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 961 Jungmaier, Gery Verwimp and Lyndon Ong. 963 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, 964 G. Sidebottom, K. Morneault, T. George, M. Stillman, B. Bidulock 965 and many others for their invaluable comments. 967 8 Author's Addresses 969 Lode Coene Phone: +32-14-252081 970 Siemens Atea EMail: lode.coene@siemens.com 971 Atealaan 34 972 B-2200 Herentals 973 Belgium 975 Javier Pastor-Balbas Phone: +34-91-3393819 976 Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com- 977 C/ Retama 1 978 28045 Madrid 979 Spain 981 Full Copyright Statement 983 Copyright (C) The Internet Society (2003). All Rights Reserved. 985 This document and translations of it may be copied and furnished 986 to others, and derivative works that comment on or otherwise 987 explain it or assist in its implementation may be prepared, 988 copied, published and distributed, in whole or in part, without 989 restriction of any kind, provided that the above copyright notice 990 and this paragraph are included on all such copies and derivative 991 works. However, this document itself may not be modified in any 992 way, such as by removing the copyright notice or references to the 993 Internet Society or other Internet organizations, except as needed 994 for the purpose of developing Internet standards in which case the 995 procedures for copyrights defined in the Internet Standards 996 process must be followed, or as required to translate it into 997 languages other than English. 999 The limited permissions granted above are perpetual and will not 1000 be revoked by the Internet Society or its successors or assigns. 1002 This document and the information contained herein is provided on 1003 Draft Telephony Signalling over SCTP AS February 2004 1005 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1006 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1007 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1008 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1009 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1011 -