idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-05.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 8 instances of too long lines in the document, the longest one being 8 characters 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. 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 786 looks like a reference -- Missing reference section? 'RFC2960' on line 776 looks like a reference -- Missing reference section? 'ALLMAN99' on line 818 looks like a reference -- Missing reference section? 'RFccccc' on line 781 looks like a reference -- Missing reference section? 'RFC3057' on line 790 looks like a reference -- Missing reference section? 'RFCxxxx' on line 793 looks like a reference -- Missing reference section? 'RFCyyyy' on line 797 looks like a reference -- Missing reference section? 'RFCzzzz' on line 802 looks like a reference -- Missing reference section? 'RFCwwww' on line 807 looks like a reference -- Missing reference section? 'RFCqqqq' on line 811 looks like a reference -- Missing reference section? 'RFCtttt' on line 814 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene(Ed) 2 Internet Engineering Task Force Siemens 3 Issued: April 2002 J. Pastor 4 Expires: September 2002 Ericsson 6 Telephony Signalling Transport over SCTP applicability statement 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1ID-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 This document describes the applicability of the new protocols 31 developed under the signaling transport framework[RFC2719]. A 32 description of the main issues regarding the use of the Stream 33 Control Transmission Protocol (SCTP)[RFC2960] and each adaptation 34 layer for transport of telephony signalling information over IP 35 infrastructure is explained. 37 Table of contents 39 Telephony signalling over SCTP Applicability statement ......... ii 40 Chapter 1: Introduction ........................................ 2 41 Chapter 1.1: Scope ..... ....................................... 3 42 Chapter 1.2: Terminology ....................................... 3 43 Chapter 1.3: Contributors ...................................... 3 44 Chapter 2: SIGTRAN architecture ................................ 4 45 Chapter 2.1: Overview ......................................... 4 46 Chapter 3: Issues for transporting Telephony signalling 47 information over SCTP .......................................... 6 48 Chapter 3.1: Congestion control ................................ 6 49 Chapter 3.2: Detection of failures ............................. 6 50 Chapter 3.2.1: Retransmission TimeOut (RTO) calculation ........ 7 51 Chapter 3.2.2: Heartbeat ....................................... 7 52 Chapter 3.2.3: Maximum Number of retransmissions ............... 7 53 Chapter 3.3: Shorten end-to-end message delay ................. 7 54 Chapter 3.4: Bundling considerations ........................... 8 55 Chapter 3.5: Stream Usage ...................................... 8 56 Chapter 4: User Adaptation Layers............................... 8 57 Chapter 4.1: IUA (ISDN Q.921 User Adaptation) .................. 10 58 Chapter 4.2: V5UA (V5.2-User Adaptation) Layer ................. 11 59 Chapter 4.3: DUA (DPNSS/DASS User adaptation) Layer ............ 12 60 Chapter 4.4: M2UA (SS7 MTP2 User Adaptation) Layer ............. 12 61 Chapter 4.5: M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer. 13 62 Chapter 4.6: M3UA (SS7 MTP3 User Adaptation) Layer ............. 15 63 Chapter 4.7: SUA (SS7 SCCP User Adaptation) Layer .............. 16 64 Chapter 5: Security considerations ............................. 18 65 Chapter 6: References and related work ......................... 18 66 Chapter 7: Acknowledgments ..................................... 19 67 Chapter 8: Author's address .................................... 19 69 1 INTRODUCTION 71 This document intends to inform how to transport telephony 72 signalling protocols, used in classic telephony systems, over IP 73 networks. The whole architecture is called SIGTRAN (Signalling 74 Transport) as described in RFC2719 and is composed of a transport 75 protocol(SCTP) and several User Adaptation (UAL) layers. The 76 transport protocol SCTP has been been developed to fulfill the 77 stringent requirements that telephony signalling networks have. The 78 set of User Adaptation layers have also been introduced to make it 79 possible that different signalling protocols can use the SCTP layer. 81 1.1 Scope 83 The scope of this document is to explain the way that user 84 adaptation layers and SCTP protocols have to be used to transport 85 Telephony signalling information over IP. 87 1.2 Terminology 89 The following terms are commonly identified in related work: 91 Association: SCTP connection between two endpoints. 93 Stream: A uni-directional logical channel established within an 94 association, within which all user messages are delivered in 95 sequence except for those submitted to the unordered delivery 96 service. 98 SPU: Signalling protocol user, the application on top of the User 99 adaptation layer. 101 CTSP: Classical Telephony Signalling protocol(examples: MTP level2, 102 MTP level 3, SCCP....). 104 UAL: User adaptation layer: the protocol that encapsulate the upper 105 layer telephony signalling protocols that are to be transported over 106 SCTP/IP. 108 ISEP: IP signalling endpoint: a IP node that implements SCTP and a 109 User adapatation layer. 111 SP: signalling point 113 1.3 Contributors 115 The following people contributed to the document: L. Coene(Editor), 116 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 117 M. Holdrege, M.C. Belinchon, A. Jungmaier, J. Pastor and L. Ong. 119 2 SIGTRAN architecture 121 The SIGTRAN architecture describes the transport of signalling 122 information over IP infrastructure. 124 Telephony Signalling transport over IP normally uses the following 125 architecture: 127 Telephony Signalling Application 128 | 129 +------------------------------------+ 130 | Signalling Adaptation Layers | 131 +------------------------------------+ 132 | 133 +------------------------------------+ 134 |Stream Control Transmission Protocol| 135 | (SCTP) | 136 +------------------------------------+ 137 | 138 Internet Protocol (IPv4/IPv6) 140 Figure 1.1: Telephony signalling transport protocol stack 142 The components of the protocol stack are : 144 (1) Adaptation modules are used when the telephony application needs 145 to preserve an existing primitive interface. (e.g. management 146 indications, data operation primitives, ... for a particular 147 user/application protocol). 149 (2) SCTP, specially configured to meet the telephony application 150 performance requirements. 152 (3) The standard Internet Protocol. 154 The telephony signalling protocols to be transported can be: 156 - SS7 MTP3 users: SCCP, ISUP, TUP... 158 - SS7 MTP2 users: MTP3 160 - SS7 SCCP users: RANAP, MAP(+TCAP), INAP(+TCAP)... 162 - ISDN Q.921 users: Q.931 164 - V5.2/DSS1 166 - .... 168 Every classic telephony protocol can have a corresponding UAL 169 developed. 171 The user adaptation layers(UALs) are a set of protocols that 172 encapsulate a specific signalling protocol to be transported over 173 SCTP. The adapation is done in a way that the upper signalling 174 protocols that are relayed remain unaware that the lower layers are 175 different to the originail lower telephony signalling layers. In 176 that sense, the upper interface of the user adapatation layers need 177 to be the same as the upper layer interface to its original lower 178 layer. If a MTP user is being relayed over the IP network, the 179 related UAL used to transport the MTP user will have the same upper 180 interface as MTP has. 182 The Stream Control Transmission protocol was designed to fulfill the 183 stringent transport requirements that classical signalling protocols 184 have and is therefore the recommended transport protocol to use for 185 this purpose. 187 The following functions are provided by SCTP: 189 - Reliable Data Transfer 191 - Multiple streams to help avoid head-of-line blocking 193 - Ordered and unordered data delivery on a per-stream basis 195 - Bundling and fragmentation of user data 197 - Congestion and flow control 199 - Support continuous monitoring of reachability 201 - Graceful termination of association 203 - Support of multi-homing for added reliability 205 - Protection against blind denial-of-service attacks 207 - Protection against blind masquerade attacks 209 SCTP is used as the transport protocol for telephony signalling 210 applications. Message boundaries are preserved during data 211 transport by SCTP and so each UA can specify its own message 212 structure withing the SCTP user data. The SCTP user data can be 213 delivered by the order of transmission within a stream(in sequence 214 delivery) or unordered. 216 SCTP can be used to provide redundancy at the 217 transport layer and below. Telephony applications needing this level 218 of redundancy can make use of SCTP's multi-homing support. 220 SCTP can be used for telephony applications where head-of-line 221 blocking is a concern. Such an application should use multiple 222 streams to provide independent ordering of telephony signalling 223 messages. 225 3 Issues for transporting telephony signalling over SCTP 227 Transport of telephony signalling requires special 228 considerations. In order to use SCTP, special care must be taken to 229 meet the performance, timing and failure management requirements. 231 3.1 Congestion Control 233 The basic mechanism of congestion control in SCTP have been 234 described in [RFC2960]. SCTP congestion control sometimes conflicts 235 with the timing requirements of telephony signalling application 236 messages which are transported by SCTP. During congestion, messages 237 may be delayed by SCTP, thus sometimes violating the timing 238 requirements of those telephony applications. 240 In an engineered network (e.g. a private intranet), in which network 241 capacity and maximum traffic are very well understood, some 242 telephony signalling applications may choose to relax the congestion 243 control rules of SCTP in order to satisfy the timing 244 requirements. In order to do this, they should employ their own 245 congestion control mechanisms. But this should be done without 246 destabilising the network, otherwise this would lead to potential 247 congestion collapse of the network. 249 Some telephony signalling applications may have their own congestion 250 control and flow control techniques. These techniques may interact 251 with the congestion control procedures in SCTP. 253 3.2 Detection of failures 255 Telephony systems often must have no single point of failure in 256 operation. 258 The UA must meet certain service availability and performance 259 requirements according to the classical signalling layers they are 260 replacing. Those requirements may be specific for each UA. 262 For example, telephony systems are often required to be able to 263 preserve stable calls during a component failure. Therefore error 264 situations at the transport layer and below must be detected quickly 265 so that the UA can take approriate steps to recover and preserve the 266 calls. This poses special requirements on SCTP to discover 267 unreachablility of a destination address or a peer. 269 3.2.1 Retransmission TimeOut (RTO) calculation 271 The SCTP protocol parameter RTO.Min value has a direct impact on the 272 calculation of the RTO itself. Some telephony applications want to 273 lower the value of the RTO.Min to less than 1 second. This would 274 allow the message sender to reach the maximum 275 number-of-retransmission threshold faster in the case of network 276 failures. However, lowering RTO.Min may have a negative impact on 277 network behaviour [ALLMAN99]. 279 In some rare cases, telephony applications might not want to use the 280 exponential timer back-off concept in RTO calculation in order to 281 speed up failure detection. The danger of doing this is that, when 282 network congestion occurs, not backing off the timer may worsen the 283 congestion situation. Therefore, this strategy should never be used 284 in public Internet. 286 It should be noted that not using delayed SACK will also help faster 287 failure detection. 289 3.2.2 Heartbeat 291 For faster detection of (un)availability of idle paths, the 292 telephony application may consider lowering the SCTP parameter 293 HB.interval. It should be noted this might result in a higher traffic 294 load. 296 3.2.3 Maximum number of retransmissions 298 Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters 299 to lower values will speed up both destination address and peer 300 failure detection. However, if these values are set too low, the 301 probability of false fault detections might increase. 303 3.3 Shorten end-to-end message delay 305 Telephony applications often require short end-to-end message 306 delays. The method described in section 3.2.1 on lowering RTO may 307 be considered. The different paths within a single association will 308 have a different RTO, so using the path with the lowest RTO will 309 lead to a shorter end-to-end message delay for the application 310 running on top of the UA's. 312 3.4 Bundling considerations 314 Bundling small telephony signalling messages at transmission helps 315 improve the bandwidth usage efficiency of the network. On the 316 downside, bundling may introduce additional delay to some of the 317 messages. This should be taken into consideration when end-to-end 318 delay is a concern. 320 3.5 Stream Usage 322 Telephony signalling traffic is often composed of multiple, 323 independent message sequences. It is highly desirable to transfer 324 those independent message sequences in separate SCTP streams. This 325 reduces the probability of head-of-line blocking in which the 326 retransmission of a lost message affects the delivery of other 327 messages not belonging to the same message sequence. 329 4 User Adaptation Layers 331 Users Adaptation Layers have been defined to encapsulate different 332 signalling protocols in order to transport them over SCTP/IP. 334 There are UALs for both access signalling (DSS1) and trunk signalling 335 (SS7). A brief description of the standardized UALs follows in the 336 next sub-sections. 338 The delivery mechanism in the several UALs 340 - Supports seamless operation of UALs user peers over an IP network 341 connection. 343 - Supports the interface boundary that the UAL user had with the 344 traditional lower layer. 346 - Supports management of SCTP transport associations and traffic 347 between SGs and ISEPs or two ISEPs 349 - Supports asynchronous reporting of status changes to management. 351 Two main scenarios have been developed for Signalling Transport: 353 - Intercommunication of traditional Signalling transport nodes and IP 354 based nodes. 356 Traditional Telephony 357 Telephony Signalling 358 ******* Signalling ********** over IP ******** 359 * SEP *----------------* SG *--------------* ISEP * 360 ******* ********** ******** 362 +-----+ +------+ 363 | SPU | | SPU | 364 +-----+ +----+----+ +------+ 365 | | | |UAL | | UAL | 366 | | | +----+ +------+ 367 |CTSP | |CTSP|SCTP| | SCTP | 368 | | | +----+ +------+ 369 | | | | IP | | IP | 370 +-----+ +---------+ +------+ 372 SEP: Signalling Endpoint 373 SG: Signalling Gateway 374 ISEP: IP Signalling Endpoint 375 SPU: Signalling Protocol User 376 CTSP: Classical Telephony Signalling Protocol 377 UAL: User Adaptation Layer 378 SCTP: Stream Control Transport Protocol 380 It is also referred as SG to AS communication. AS is the name that 381 UAL usually gives to the ISEP nodes. It stands for Application 382 Server. 384 - Communication inside the IP networks. 386 Telephony 387 Signalling 388 ******** over IP ******** 389 * ISEP *------------------* ISEP * 390 ******** ******** 392 +------+ +------+ 393 | SPU | | SPU | 394 +------+ +------+ 395 | UAL | | UAL | 396 +------+ +------+ 397 | SCTP | | SCTP | 398 +------+ +------+ 399 | IP | | IP | 400 +------+ +------+ 402 This is also referred to as IPSP communication. IPSP is the name 403 given to the role that a UAL plays on an IP-based node. It stands 404 for IP Signalling Point. 406 4.1 IUA (ISDN Q.921 User Adaptation) 408 This protocol supports both ISDN Primary Rate Access (PRA) as well 409 as Basic Rate Access (BRA) including the support for both 410 point-to-point and point-to-multipoint modes of communication. This 411 support includes Facility Associated Signalling (FAS), Non-Facility 412 Associated Signalling (NFAS) and NFAS with backup D channel. 414 It implements the client/server architecture. The default 415 orientation is for the SG to take on the role of server while the 416 ISEP is the client. The SCTP (and UDP/TCP) Registered User Port 417 Number Assignment for IUA is 9900. 419 Examples of the upper layers to be transported are Q.931 and QSIG. 421 The main scenario supported by this UAL is the SG to ISEP 422 communication where the ISEP role is typically played by a node 423 called an MGC, as defined in [RFC2719]. 425 ****** ISDN ****** IP ******* 426 * EP *---------------* SG *--------------* MGC * 427 ****** ****** ******* 429 +-----+ +-----+ 430 |Q.931| (NIF) |Q.931| 431 +-----+ +----------+ +-----+ 432 | | | | IUA| | IUA | 433 | | | +----+ +-----+ 434 |Q.921| |Q.921|SCTP| |SCTP | 435 | | | +----+ +-----+ 436 | | | | IP | | IP | 437 +-----+ +-----+----+ +-----+ 439 NIF - Nodal Interworking Function 440 EP - ISDN End Point 441 SCTP - Stream Control Transmission Protocol 442 IUA - ISDN User Adaptation Layer Protocol 444 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 445 IUA is 9900. 447 The value assigned by IANA for the Payload Protocol Identifier in 448 the SCTP Payload Data chunk is "1". 450 4.2 V5UA (V5.2-User Adaptation) Layer 452 It is an extension from the IUA layer with the modifications needed 453 to support the differences between Q.921 / Q.931, and V5.2 layer 2 / 454 layer 3. It supports analog telephone access, ISDN basic rate access 455 and ISDN primary rate access over a V5.2 interface. It is typically 456 implemented in an interworking scenario with SG. 458 ****** V5.2 ****** IP ******* 459 * AN *---------------* SG *--------------* MGC * 460 ****** ****** ******* 462 +-----+ +-----+ 463 |V5.2 | (NIF) |V5.2 | 464 +-----+ +----------+ +-----+ 465 | | | |V5UA| |V5UA | 466 | | | +----+ +-----+ 467 |LAPV5| |LAPV5|SCTP| |SCTP | 468 | | | +----+ +-----+ 469 | | | | IP + | IP | 470 +-----+ +-----+----+ +-----+ 472 AN - Access Network 473 NIF - Nodal Interworking Function 474 LAPV5 - Link Access Protocol for the V5 channel 475 SCTP - Stream Control Transmission Protocol 477 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 478 V5UA is 5675. 480 The value assigned by IANA for the Payload Protocol Identifier in 481 the SCTP Payload Data chunk is "6". 483 4.3 DUA (DPNSS/DASS 2 User Adaptation) Layer 485 The DUA is built on top of IUA and defines the necessary extensions 486 to IUA for a DPNSS/DASS2 transport. DPNSS stands for Digital Private 487 Network Signalling System and DASS2 for Digital Access Signalling 488 System No 2. 490 ****** DPNSS ****** IP ******* 491 *PBX *---------------* SG *--------------* MGC * 492 ****** ****** ******* 494 +-----+ +-----+ 495 |DPNSS| (NIF) |DPNSS| 496 | L3 | | L3 | 497 +-----+ +----------+ +-----+ 498 | | | | DUA| | DUA | 499 |DPNSS| |DPNSS+----+ +-----+ 500 | L2 | | L2 |SCTP| |SCTP | 501 | | | +----+ +-----+ 502 | | | | IP + | IP | 503 +-----+ +-----+----+ +-----+ 505 PBX - Private Branch eXchange 506 NIF - Nodal Interworking function 507 SCTP - Stream Control Transmission Protocol 508 DUA - DPNSS User Adaptation Layer Protocol 510 The value assigned by IANA for the Payload Protocol Identifier in 511 the SCTP Payload Data chunk is "TBD". 513 4.4 M2UA (SS7 MTP2 User Adaptation) Layer 515 This protocol is typically used between a Signalling Gateway (SG) and 516 Media Gateway Controler (MGC). The SG will terminate up to MTP Level 517 2 and the MGC will terminate MTP Level 3 and above. In other words, 518 the SG will transport MTP Level 3 messages over an IP network to a 519 MGC. 521 MTP3 and MTP3b are the only MTP2 Users that are transported by this 522 UAL. 524 The SG provides a interworking of transport functions with the IP 525 transport, to transfer the MTP2-User signalling messages with MTP2- 526 User at an application server(e.g. MGC). 528 ****** SS7 ****** IP ******* 529 *SEP *-----------* SG *-------------* MGC * 530 ****** ****** ******* 532 +----+ +----+ 533 |S7UP| |S7UP| 534 +----+ +----+ 535 |MTP + |MTP | 536 | L3 | (NIF) |L3 | 537 +----+ +----+----+ +----+ 538 |MTP | |MTP |M2UA| |M2UA| 539 | | | +----+ +----+ 540 | L2 | | L2 |SCTP| |SCTP| 541 | L1 | | L1 +----+ +----+ 542 | | | |IP | |IP | 543 +----+ +---------+ +----+ 545 MGC - Media Gateway Controler 546 SG - Signalling Gateway 547 SEP - SS7 Signalling Endpoint 548 NIF - Nodal Interworking Function 549 IP - Internet Protocol 550 SCTP - Stream Control Transmission Protocol 552 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 553 M2UA is 2904. 555 The value assigned by IANA for the Payload Protocol Identifier in 556 the SCTP Payload Data chunk is "2". 558 4.5 M2PA (SS7 MTP2-User Peer-to-Peer Adaptation) Layer 560 This protocol is used between SS7 Signalling Points using the MTP 561 Level 3 protocol. The SS7 Signalling Points may also employ standard 562 SS7 links using the SS7 MTP Level 2 to provide transport of MTP 563 Level 3 signalling messages. 565 Both configurations: interworking of SS7 and IP with SG and 566 communication between ISEPs are possible. 568 ******** IP ******** 569 * IPSP *--------* IPSP * 570 ******** ******** 572 +------+ +------+ 573 | TCAP | | TCAP | 574 +------+ +------+ 575 | SCCP | | SCCP | 576 +------+ +------+ 577 | MTP3 | | MTP3 | 578 +------+ +------+ 579 | M2PA | | M2PA | 580 +------+ +------+ 581 | SCTP | | SCTP | 582 +------+ +------+ 583 | IP | | IP | 584 +------+ +------+ 586 IP - Internet Protocol 587 IPSP - IP Signalling Point 588 SCTP - Stream Control Transmission Protocol 590 ******** SS7 *************** IP ******** 591 * SEP *--------* SG *--------* IPSP * 592 ******** *************** ******** 594 +------+ +------+ 595 | TCAP | | TCAP | 596 +------+ +------+ 597 | SCCP | | SCCP | 598 +------+ +-------------+ +------+ 599 | MTP3 | | MTP3 | | MTP3 | 600 +------+ +------+------+ +------+ 601 | MTP2 | | MTP2 | M2PA | | M2PA | 602 +------+ +------+------+ +------+ 603 | MTP1 | | MTP1 | SCTP | | SCTP | 604 | | | +------+ +------+ 605 | | | | IP | | IP | 606 +------+ +------+------+ +------+ 608 SEP - SS7 Signalling Endpoint 610 These figures are only an example. Other configurations are 611 possible. 613 The SCTP (and UDP/TCP) Registered User Port Number Assignment for 614 M2PA is TBD. 616 The value assigned by IANA for the Payload Protocol Identifier in 617 the SCTP Payload Data chunk is "5". 619 Differences between M2PA and M2UA include: 621 a. M2PA: IPSP processes MTP3/MTP2 primitives. 622 M2UA: MGC transports MTP3/MTP2 primitives between the SG's MTP2 623 and the MGC's MTP3 (via the NIF) for processing. 625 b. M2PA: SG-IPSP connection is an SS7 link. 626 M2UA: SG-MGC connection is not an SS7 link. It is an 627 extension of MTP to a remote entity. 629 c. M2PA: SG is an SS7 node with a point code. 630 M2UA: SG is not necessarily an SS7 node and may not have a point code. 632 d. M2PA: SG can have upper SS7 layers, e.g., SCCP. 633 M2UA: SG does not have upper SS7 layers since it has no MTP3. 635 e. M2PA: relies on MTP3 for management procedures. 636 M2UA: uses M2UA management procedures. 638 4.6 M3UA (SS7 MTP3 User Adaptation) Layer 640 This adaptation layer supports the transport of any SS7 MTP3-User 641 signalling such as TUP, ISUP and SCCP over IP using the services of 642 SCTP. 644 This protocol allows both: 646 - Interworking of SS7 and IP nodes 647 - Communication between two IP nodes 649 ******** SS7 ***************** IP ******** 650 * SEP *---------* SGP *--------* ASP * 651 ******** ***************** ******** 653 +------+ +---------------+ +------+ 654 | ISUP | | (NIF) | | ISUP | 655 +------+ +------+ +------+ +------+ 656 | MTP3 | | MTP3 | | M3UA | | M3UA | 657 +------| +------+-+------+ +------+ 658 | MTP2 | | MTP2 | | SCTP | | SCTP | 659 +------+ +------+ +------+ +------+ 660 | L1 | | L1 | | IP | | IP | 661 +------+ +------+ +------+ +------+ 663 SEP - SS7 Signalling End Point 664 SCTP - Stream Control Transmission Protocol 665 NIF - Nodal Interworking Function 666 ******** IP ******** 667 * IPSP *----------* IPSP * 668 ******** ******** 670 +------+ +------+ 671 |SCCP- | |SCCP- | 672 | User | | User | 673 +------+ +------+ 674 | SCCP | | SCCP | 675 +------+ +------+ 676 | M3UA | | M3UA | 677 +------+ +------+ 678 | SCTP | | SCTP | 679 +------+ +------+ 680 | IP | | IP | 681 +------+ +------+ 683 It works using the client-server architecture. It is recommended 684 that the ISEP act as the client and initiate SCTP associations with 685 the SG. The port reserved by IANA is port number 2905. this is the 686 port upon which the SG should listen for client connections. 688 The assigned payload protocol identifier for the SCTP DATA chunks is 689 "3". 691 4.7 SUA (SS7 SCCP User Adaptation) Layer 693 This adaptation layer supports the transport of any SS7 SCCP-User 694 signalling such as MAP, INAP, SMS, BSSAP, RANAP over IP using the 695 services of SCTP. 697 For message relaying, SUA should have the same timing constraints as 698 SCCP . For the end-to-end approach, SUA applications may have 699 broader timing requirements (from 100 of milliseconds to hours) 700 which allows the applications to guard themselves. 702 Possible configurations showed in the pictures below: 704 - Interworking of SS7 and IP 705 - IP Node to IP Node communication 706 ******** SS7 *************** IP ******** 707 * SEP *---------* *--------* * 708 * or * * SG * * ASP * 709 * STP * * * * * 710 ******** *************** ******** 712 +------ +------+ 713 | SUAP | | SUAP | 714 +------+ +------+------+ +------+ 715 | SCCP | | SCCP | SUA | | SUA | 716 +------+ +------+------+ +------+ 717 | MTP3 | | MTP3 | | | | 718 +------+ +------+ SCTP | | SCTP | 719 | MTP2 | | MTP2 | | | | 720 +------+ +------+------+ +------+ 721 | L1 | | L1 | IP | | IP | 722 +------+ +------+------+ +------+ 724 SUAP - SCCP/SUA User Protocol (TCAP, for example) 725 STP - SS7 Signalling Transfer Point 727 ******** IP ******** 728 * *--------* * 729 * IPSP * * IPSP * 730 * * * * 731 ******** ******** 733 +------+ +------+ 734 | SUAP | | SUAP | 735 +------+ +------+ 736 | SUA | | SUA | 737 +------+ +------+ 738 | SCTP | | SCTP | 739 +------+ +------+ 740 | IP | | IP | 741 +------+ +------+ 743 IANA has registered SCTP Port Number 14001 for SUA. It is 744 recommended that SGs use this SCTP port number for listening for new 745 connections. The payload protocol identifier for the SCTP DATA 746 chunks is "4". 748 5 Security considerations 750 UALs are designated to carry signalling messages for telephony 751 services. As such, UALs must involve the security needs of several 752 parties: the end users of the services; the network providers and 753 the applications involved. Additional requirements may come from 754 local regulation. While having some overlapping security needs, any 755 security solution should fulfill all of the different parties' 756 needs. See specific Security considerations in each UAL technical 757 specification. 759 SCTP only tries to increase the availability of a network. SCTP does 760 not contain any protocol mechanisms which are directly related to 761 user message authentication, integrity and confidentiality 762 functions. For such features, it depends on the IPSEC protocols and 763 architecture and/or on security features of its user protocols. 765 Mechanisms for reducing the risk of blind denial-of-service attacks 766 and masquerade attacks are built into SCTP protocol. See RFC2960, 767 section 11 for detailed information. 769 Currently the IPSEC working group is investigating the support of 770 multihoming by IPSEC protocols. At the present time to use IPSEC, 771 one must use 2 * N * M security associations if one endpoint uses N 772 addresses and the other M addresses. 774 6 References and related work 776 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 777 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, 778 L. and Paxson, V, "Stream Control Transmission Protocol", RFC2960, 779 October 2000. 781 [RFccccc] Coene, L., Tuexen, M., Verwimp, G., Loughney, J., Stewart, 782 R. R., Xie, Q., Holdrege, M., Belinchon, M.C., and Jungmayer, A., 783 "Stream Control Transmission Protocol Applicability statement", 784 RFCzzzz, April 2002. 786 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 787 L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework 788 Architecture for Signalling Transport", RFC2719, October 1999. 790 [RFC3057] Morneault, K., Rengasami, S., Kalla, M., Sidebottom, G., 791 "ISDN Q.921-User Adaptation Layer", RFC3057, February 2001. 793 [RFCxxxx] Morneault, K., Dantu, R., Sidebottom, G., George, T., 794 Bidulock, B., Heitz , J., "Signaling System 7 (SS7) Message Transfer 795 Part (MTP) 2 - User Adaptation Layer", RFCxxxx, May 2002. 797 [RFCyyyy] Sidebottom, G., Pastor-Balbas, J., Rytina, I., Mousseau, 798 G., Ong, L., Schwarzbauer, H.J., Gradischnig, K., Morneault, K., 799 Kalla, M., Glaude, N., Bidulock, B., Loughney, J., "SS7 MTP3-User 800 Adaptation Layer (M3UA)", RFCyyyy, May 2002. 802 [RFCzzzz] Loughney, J., Sidebottom, G., Mousseau, G., Lorusso, S., 803 Coene, L., Verwimp, G., Keller, J., Escobar, F., Sully, W., Furniss, 804 S., Bidulock, B.,"SS7 SCCP-User Adaptation Layer (SUA)", RFCzzzz, 805 May 2002. 807 [RFCwwww] George, T., Dantu, R., Kalla, M., Schwarzbauer, H.J., 808 Sidebottom, G., Morneault, K.,"SS7 MTP2-User Peer-to-Peer Adaptation 809 Layer", RFCwwww, June 2002. 811 [RFCqqqq] Weilandt, E., Khanchandani, N., Rao, S.,"V5.2-User 812 Adaptation Layer (V5UA)", RFCqqqq, June 2002 814 [RFCtttt] Vydyam, A., Mukundan, R., Mangalpally, N., Morneault, 815 K.,"DPNSS/DASS 2 extensions to the IUA protocol", RFCtttt, August 816 2002. 818 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End 819 Network Path Properties", Proc. SIGCOMM'99, 1999. 821 7 Acknowledgments 823 This document was initially developed by a design team consisting of 824 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, 825 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas 826 Jungmaier, Gery Verwimp and Lyndon Ong. 828 The authors wish to thank Renee Revis, H.J. Schwarzbauer, T. Taylor, 829 G. Sidebottom, K. Morneault, T. George, M. Stillman and many others 830 for their invaluable comments. 832 8 Author's Address 834 Lode Coene Phone: +32-14-252081 835 Siemens Atea EMail: lode.coene@siemens.atea.be 836 Atealaan 34 837 B-2200 Herentals 838 Belgium 840 Javier Pastor-Balbas Phone: 841 Ericsson Espana S.A. Email: j.javier.pastor@ericsson.com 842 C/ Ombu 3 843 28045 Madrid 844 Spain 846 Expires: August 2002 848 Full Copyright Statement 850 Copyright (C) The Internet Society (2002). All Rights Reserved. 852 This document and translations of it may be copied and furnished 853 to others, and derivative works that comment on or otherwise 854 explain it or assist in its implementation may be prepared, 855 copied, published and distributed, in whole or in part, without 856 restriction of any kind, provided that the above copyright notice 857 and this paragraph are included on all such copies and derivative 858 works. However, this document itself may not be modified in any 859 way, such as by removing the copyright notice or references to the 860 Internet Society or other Internet organizations, except as needed 861 for the purpose of developing Internet standards in which case the 862 procedures for copyrights defined in the Internet Standards 863 process must be followed, or as required to translate it into 864 languages other than English. 866 The limited permissions granted above are perpetual and will not 867 be revoked by the Internet Society or its successors or assigns. 869 This document and the information contained herein is provided on 870 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 871 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 872 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 873 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.