idnits 2.17.1 draft-ietf-sigtran-framework-arch-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1031 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 27 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 125 has weird spacing: '...traffic to th...' == Line 772 has weird spacing: '...ures is requi...' -- 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 44 -- Looks like a reference, but probably isn't: '3' on line 95 -- Looks like a reference, but probably isn't: '4' on line 148 -- Looks like a reference, but probably isn't: '5' on line 199 == Missing Reference: 'SG' is mentioned on line 287, but not defined == Missing Reference: 'MGC' is mentioned on line 401, but not defined == Missing Reference: 'MG' is mentioned on line 407, but not defined -- Looks like a reference, but probably isn't: '6' on line 249 -- Looks like a reference, but probably isn't: '7' on line 303 == Missing Reference: 'SG1' is mentioned on line 322, but not defined -- Looks like a reference, but probably isn't: '8' on line 346 -- Looks like a reference, but probably isn't: '9' on line 382 -- Looks like a reference, but probably isn't: '10' on line 435 -- Looks like a reference, but probably isn't: '11' on line 480 -- Looks like a reference, but probably isn't: '12' on line 531 -- Looks like a reference, but probably isn't: '13' on line 584 -- Looks like a reference, but probably isn't: '14' on line 639 -- Looks like a reference, but probably isn't: '15' on line 693 -- Looks like a reference, but probably isn't: '16' on line 748 == Missing Reference: 'RFC2401' is mentioned on line 796, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) -- Looks like a reference, but probably isn't: '17' on line 803 -- Looks like a reference, but probably isn't: '2409' on line 819 == Missing Reference: 'RFC2246' is mentioned on line 821, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) -- Looks like a reference, but probably isn't: '18' on line 856 -- Looks like a reference, but probably isn't: '19' on line 913 == Unused Reference: 'NAT' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'SS7 MTP' is defined on line 878, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET-DRAFT Authors 3 Transport Working Group Lyndon Ong, Nortel Networks 4 Category: Informational Ian Rytina, Miguel Garcia, Ericsson 5 April 1999 HannsJuergen Schwarzbauer, Lode Coene, Siemens 6 Expires: November 1999 Huai-an Paul Lin, Telcordia 7 Imre Juhasz, Telia 8 Matt Holdrege, Ascend 9 Chip Sharp, Cisco Systems 11 Architectural Framework for Signaling Transport 12 < draft-ietf-sigtran-framework-arch-01.txt > 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance 17 with all provisions of Section 10 of RFC2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document defines an architecture framework and functional 36 requirements for transport of signaling information over IP. The 37 framework describes relationships between functional and physical 38 entities exchanging signaling information, such as Signaling Gateways 39 and Media Gateway Controllers. It identifies interfaces where 40 signaling transport may be used and the functional and performance 41 requirements that apply from existing Switched Circuit Network (SCN) 42 signaling protocols. 44 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [2] 46 Table of Contents 48 1. Introduction..............................................2 49 1.1 Overview.................................................2 50 1.2 Terminology..............................................2 51 1.3 Scope...................................................4 52 2. Signaling Transport Architecture.........................5 53 2.1 Gateway Component Functions.............................5 54 2.2 SS7 Interworking for Connection Control.................5 55 2.3 ISDN Interworking for Connection Control................6 56 2.4 CAS Backhaul............................................7 57 2.5 Architecture for Database Access........................8 58 3. Protocol Architecture.....................................9 59 3.1. SS7 access for Media Gateway Control....................9 60 3.2. Q.931 Access to MGC....................................10 61 3.3. SS7 Access to IP/SCP...................................10 62 3.4. SG to SG...............................................11 63 4. Functional Requirements..................................13 64 5. Management...............................................16 65 6. Security.................................................17 66 7. Abbreviations............................................17 67 8. Acknowledgements.........................................18 68 9. References...............................................18 69 Authors' Contact Information................................19 71 1. Introduction 73 1.1 Overview 75 This document defines an architecture framework for transport of 76 message-based signaling protocols over IP networks. The scope of 77 this work includes definition of encapsulation methods, end-to-end 78 protocol mechanisms and use of existing IP capabilities to support 79 the functional and performance requirements for signaling transport. 81 The framework portion describes the relationships between functional 82 and physical entities used in signaling transport, including the 83 framework for control of Media Gateways, and other scenarios where 84 signaling transport may be required. 86 The requirements portion describes functional and performance 87 requirements for signaling transport such as flow control, in-sequence 88 delivery and other functions that may be required for specific SCN 89 signaling protocols. 91 1.2 Terminology 93 The following are general terms are used in this document: 95 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [3] 97 Backhaul: 99 Backhaul refers to the transport of signaling from the point of interface for 100 the associated data stream (i.e., the MGU) back to the 101 point of call processing (i.e., the MGCU), if this is not local. 103 Common Transport Protocol (CTP): 105 CTP is the transport layer protocol, which provides the interface 106 for signaling transport across and within IP networks. CTP refers 107 to both the transport function and the adaptation function (required 108 to provide the SCN protocols with the same interface that exists 109 towards the lower layers today). 111 Switched Circuit Network (SCN): 113 The term SCN is used to refer to a network that carries traffic within 114 channelized bearers of pre-defined sizes. Examples include Public 115 Switched Telephone Networks (PSTNs) and Public Land Mobile Networks 116 (PLMNs). Examples of signaling protocols used in SCN include Q.931, 117 SS7 MTP Level 3 and SS7 Application/User parts. 119 The following are terms for functional entities relating to signaling 120 transport in a distributed gateway model. 122 Media Gateway (MG): 124 A MG terminates SCN media streams, packetizes the media data,, if it 125 is not already packetized, and delivers packetized traffic to the 126 packet network. It performs these functions in reverse order for media 127 streams flowing from the packet network to the SCN. 129 Media Gateway Controller (MGC): 131 An MGC handles the registration and management of resources at the MG. 132 The MGC may have the ability to authorize resource usage based on local 133 policy. For signaling transport purposes, the MGC serves as a possible 134 termination and origination point for SCN application protocols, such 135 as SS7 ISDN User Part and Q.931/DSS1. 137 Signaling Gateway (SG): 139 An SG is a signaling agent that receives/sends SCN native signaling at 140 the edge of the IP network. The SG function may relay, translate or 141 terminate SS7 signaling in an SS7-Internet Gateway. The SG function may 142 also be co-resident with the MG function to process SCN signaling associated 143 with line or trunk terminations controlled by the MG (e.g., signaling backhaul). 145 The following are terms for physical entities relating to signaling 146 transport in a distributed gateway model: 148 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [4] 150 Media Gateway Unit (MGU) 152 An MG-Unit is a physical entity that contains the MG function. It may 153 contain other functions, esp. an SG function for handling facility- 154 associated signaling. 156 Media Gateway Control Unit (MGCU) 158 An MGC-Unit is a physical entity containing the MGC function. 160 Signaling Gateway Unit (SGU) 162 An SG-Unit is a physical entity containing the SG function. 164 Signaling End Point (SEP): 166 This is a node in an SS7 network that originates or terminates signaling 167 messages. One example is a central office switch. 169 Signal Transfer Point (STP): 171 This is a node in an SS7 network that routes signaling messages based on 172 their destination point code in the SS7 network 174 1.3 Scope 176 Signaling transport provides transparent transport of message-based 177 signaling protocols over IP networks. The scope of this work includes 178 definition of encapsulation methods, end-to-end protocol mechanisms and 179 use of IP capabilities to support the functional and performance 180 requirements for signaling. 182 Signaling transport shall be used for transporting SCN signaling 183 between a Signaling Gateway Unit and Media Gateway Controller Unit. 184 Signaling transport may also be used for transport of message-based 185 signaling between a Media Gateway Unit and Media Gateway Controller 186 Unit, between dispersed Media Gateway Controller Units, and between two 187 Signaling Gateway Units connecting signaling endpoints in the SCN. 189 Signaling transport will be defined in such a way as to support 190 encapsulation and carriage of a variety of SCN protocols. It 191 is defined in such a way as to be independent of any protocol 192 translation functions taking place within the Signaling Gateway Unit or 193 Media Gateway Unit, since its function is limited to the transport of 194 the protocol. 196 Since the function being provided is transparent transport, the following 197 areas are considered outside the scope of the signaling transport work: 199 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [5] 201 - definition of the SCN protocols themselves 202 - signaling interworking such as conversion from Channel Associated 203 Signaling (CAS) to message signaling protocols 204 - specification of the functions taking place within the SGU or MGU - in 205 particular, this work does not address whether the SGU provides 206 mediation/interworking, as this is transparent to the transport 207 function. 209 2. Signaling Transport Architecture 211 2.1 Gateway Component Functions 213 Figure 1 defines a commonly defined functional model 214 that separates out the functions of SG, MGC and MG. This model may be 215 implemented in a number of ways, with functions implemented in separate 216 devices or combined in single physical units. 218 Where physical separation exists between functional entities, Signaling 219 Transport can be applied to ensure that SCN signaling information is 220 transported between entities with the required functionality and 221 performance. 223 +---------------+ +--------------+ 224 | | | | 225 SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN 226 signal | | | | | | signal 227 +-------|-------+ +-----|--------+ 228 Signaling|gateway Signaling|gateway (opt) 229 O O 230 | | 231 +-------|-------+ +-----|--------+ 232 | | | | | | 233 | [MGC] <--+--------O-------------+--> [MGC] | 234 | | | | | | 235 | | | | | | 236 +-------|-------+ +-----|--------+ 237 Gateway | controller Gateway | controller (opt) 238 O O 239 | | 240 +-------|-------+ +-----|--------+ 241 Media | | | | | | Media 242 <------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+--------> 243 stream| | | | stream 244 +---------------+ +--------------+ 245 Media gateway Media gateway 247 Figure 1: Sigtran Functional Model 249 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [6] 251 As discussed above, the interfaces pertaining to signaling transport 252 include SG to MGC, SG to SG and may potentially include MGC to MGC or 253 MG to MGC as well. 255 2.2 SS7 Interworking for Connection Control 257 Figure 2 below shows some example implementations of these functions in 258 physical entities as used for interworking of SS7 and IP networks for 259 Voice over IP, Voice over ATM, Network Access Servers, etc. No 260 recommendation is made as to functional distribution and other 261 implementations are possible. 263 For interworking with SS7-controlled SCN networks, the SG terminates the 264 SS7 link and transfers the signaling information to the MGC using 265 signaling transport. The MG terminates the interswitch trunk and 266 controls the trunk based on the control signaling it receives from the 267 MGC. As shown below in case (a), the SG, MGC and MG 268 may be implemented in separate physical units, or as in case (b), the 269 MGC and MG may be implemented in a single physical unit. 271 In alternative case (c), a facility-associated SS7 link is terminated 272 by the same device (i.e., the MGU) that terminates the interswitch trunk. 273 In this case, the SG function is co-located with the MG function, as shown 274 below, and signaling transport is used to "backhaul" control signaling to 275 the MGCU. 277 Note: SS7 links may also be terminated directly on the MGCU by 278 cross-connecting at the physical level before or at the MGU. 280 SGU 281 +--------+ 282 SS7<------>[SG] | 283 (ISUP) | | | 284 +---|----+ 285 ST | SGU MGCU 286 +---|----+ +--------+ +--------+ 287 | [MGC] | SS7---->[SG] | | [MGC] | 288 | | | | | | | | | | 289 +---|----+ +---|----+ +--|-|---+ 290 MGCU | ST | | | 291 | | ST | | 292 Media +---|----+ Media +---|----+ +--|-|---+ 293 ------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| | 294 stream | | stream | | Media------> [MG] | 295 +--------+ +--------+ stream +--------+ 296 MGU MGU MGU 298 (a) (b) (c) 299 Notes: ST = Signaling Transport used to carry SCN signaling 301 Figure 2: Example Implementations 303 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [7] 305 In some implementations, the function of the SG may be divided into 306 multiple physical entities to support scaling and addressing concerns. 307 Thus, Signaling Transport can be used between SGs as well as from SG 308 to MGC. This is shown in Figure 3 below. 310 SGU MGCU 311 +---------+ +---------+ 312 | | ST | | 313 | [SG2]------------------------------>[MGC] | 314 | ^ ^ | | | 315 +---|-|---+ +---------+ 316 | | 317 | | ST 318 ST| +--------------------------------+ 319 | | 320 | | 321 SS7 +---|----------+ SS7 +----|---------+ 322 -----------> [SG1] | -----------> [SG1] | 323 media | | media | | 324 ------------------->[MG] | ------------------->[MG] | 325 stream +--------------+ stream +--------------+ 326 MGU MGU 328 Figure 3: Multiple SG Case 330 In this configuration, there may be more than one MGU handling 331 facility associated signaling (i.e. more than one containing it's 332 own SG function), and only a single SGU. It will therefore be 333 possible to transport one SS7 layer between SG1 and SG2, and 334 another SS7 layer between SG2 and MGC. For example, SG1 could 335 transport MTP3 to SG2, and SG2 could transport ISUP to MGC. 337 2.3 ISDN Interworking for Connection Control 339 In ISDN access signaling, the signaling channel is carried along with 340 data channels, so that the SG function for handling Q.931 signaling 341 is co-located with the MG function for handling the data stream. Where 342 Q.931 is then transported to the MGC for call processing, signaling 343 transport would be used between the SG function and MGC. This is shown 344 in Figure 3 below. 346 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [8] 348 MGCU 349 +-------------+ 350 | [MGC] | 351 | | | | 352 +-----|-|-----+ 353 | | 354 | O device control 355 | | 356 Q.931/ST O | 357 | | 358 +-----|-|-----+ 359 | | | | 360 Q.931---->[SG]| | 361 signals| | | 362 | | | 363 Media---->[MG] | 364 stream | | 365 +-------------+ 366 MGU 368 Figure 4: Q.931 transport model 370 2.4 Architecture for Database Access 372 Transaction Capabilities (TCAP) is the application part within SS7 373 that is used for non-circuit-related signaling. 375 TCAP signaling within IP networks may be used for cross-access between 376 entities in the SS7 domain and the IP domain, such as: 377 - access from an SS7 network to a Service Control Point (SCP) in IP 378 - access from an SS7 network to an MGC 379 - access from an MGC to an SS7 network element 380 - access from an IP SCP to an SS7 network element 382 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [9] 384 A basic functional model for TCAP over IP is shown in Figure 4. 386 +--------------+ 387 | IP SCP | 388 +--|----|------+ 389 | | 390 SGU | | SGU 391 +--------------+ | | +--------------+ 392 | | | | | | 393 SS7<--------->[SG] ---------+ | | [SG]<---------> SS7 394 (TCAP) | | | | | | | 395 +------|-------+ | +------|-------+ 396 | | | 397 O +------------+ O 398 MGCU | | | MGCU 399 +-------|----|--+ +-----|--------+ 400 | | | | | | | 401 | [MGC] | | [MGC] | 402 | | | | | | 403 +-------|-------+ +-----|--------+ 404 | | 405 +-------|-------+ +-----|------+ 406 Media | | | | | | Media 407 <------+---->[MG] <---+--RTP stream---+--> [MG] <-+--------> 408 stream| | | | stream 409 +---------------+ +------------+ 410 MGU MGU 412 Figure 5: TCAP Signaling over IP 414 3. Protocol Architecture 416 This section provides a series of examples of protocol architecture 417 for the use of Signaling Transport Common Transport Protocol (CTP). 419 3.1. SS7 access for Media Gateway Control 421 This section provides a protocol architecture for signaling transport 422 supporting SS7 access for Media Gateway Control. 424 ****** SS7 ******* SS7 ****** IP ******* 425 *SEP *--------* STP *------* SG*------------* MGC* 426 ****** ******* ****** ******* 428 +----+ +-----+ 429 |ISUP| | ISUP| 430 +----+ +-----+ +---------+ +-----+ 431 |MTP | |MTP | |MTP | CTP| | CTP | 432 + + + + + +----+ +-----+ 433 | | | | | | IP | | IP | 434 +----+ +-----+ +---------+ +-----+ 435 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [10] 437 STP - Signal Transfer Point SEP - Signaling End Point 438 SG - Signaling Gateway CTP - Common Transport Protocol 439 MGC - Media Gateway Controller 441 Figure 6: SS7 Access to MGC 443 3.2. Q.931 Access to MGC 445 This section provides a protocol architecture for signaling transport 446 supporting ISDN point-to-point access (Q.931) for Media Gateway Control. 448 ****** ISDN ********* IP ******* 449 * EP *--------------* SG/MG *------------* MGC * 450 ****** ********* ******* 452 +----+ +-----+ 453 |Q931| | Q931| 454 +----+ +---------+ +-----+ 455 |Q921| |Q921| CTP| | CTP | 456 + + + +----+ +-----+ 457 | | | | IP | | IP | 458 +----+ +---------+ +-----+ 460 MG/SG - Media Gateway with SG function for backhaul 461 EP - ISDN End Point 463 Figure 7: ISDN Access 465 3.3. SS7 Access to IP/SCP 467 This section provides a protocol architecture for database 468 access, for example providing signaling between two IN 469 nodes or two mobile network nodes. There are a number of 470 scenarios for the protocol stacks and the functionality 471 contained in the CTP, depending on the SS7 application. 473 In the diagrams, SS7 Application Part (S7AP) is used for 474 generality to cover all Application Parts (e.g. MAP, IS-41, 475 INAP, etc). Depending on the protocol being transported, S7AP may or 476 may not include TCAP. The interface to the SS7 layer below 477 S7AP can be either the TC-user interface or the SCCP-user 478 interface. 480 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [11] 482 Figure 8a shows the scenario where SCCP is the signaling 483 protocol being transported between the SG and an IP Signaling 484 Endpoint (ISEP), that is, an IP destination supporting some 485 SS7 application protocols. 487 ****** SS7 ******* SS7 ****** IP ******* 488 *SEP *--------* STP *------* SG *-------------* ISEP* 489 ****** ******* ****** ******* 491 +-----+ +-----+ 492 |S7AP | |S7AP | 493 +-----+ +-----+ 494 |SCCP | |SCCP | 495 +-----+ +-----+ +---------+ +-----+ 496 |MTP | |MTP | |MTP |CTP | |CTP | 497 + + + + + +----+ +-----+ 498 | | | | | | IP | |IP | 499 +-----+ +-----+ +---------+ +-----+ 501 Figure 8a: SS7 Access to IP node - SCCP being transported 503 Figure 8b shows the scenario where S7AP is the signaling 504 protocol being transported between SG and ISEP. Depending on 505 the usage case, S7AP may or may not include TCAP, which implies 506 that CTP must be able to support both the TC-user and the 507 SCCP-user interfaces. 509 ****** SS7 ******* SS7 ****** IP ******* 510 *SEP *--------* STP *------* SG *-------------* ISEP* 511 ****** ******* ****** ******* 513 +-----+ +-----+ 514 |S7AP | |S7AP | 515 +-----+ +----+----+ +-----+ 516 |SCCP | |SCCP| | | | 517 +-----+ +-----+ +----|CTP | |CTP | 518 |MTP | |MTP | |MTP | | | | 519 + + + + + +----+ +-----+ 520 | | | | | |IP | |IP | 521 +-----+ +-----+ +---------+ +-----+ 523 Figure 8b: SS7 Access to IP node - S7AP being transported 525 3.4. SG to SG 527 This section identifies a protocol architecture for support of 528 signaling between two endpoints in an SCN signaling 529 network, using signaling transport directly between two SGs. 531 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [12] 533 The following figure describes protocol architecture for a 534 scenario with two SGs providing different levels of function 535 for interworking of SS7 and IP. This corresponds to the scenario 536 given in Figure 3. 538 The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly 539 for transport within the SS7 network, for example, ISUP. 541 In this scenario, there are two different usage cases of CTP, 542 one which transports MTP3 signaling, the other which transports 543 ISUP signaling. 545 ****** SS7 ****** IP ****** IP ****** 546 *SEP *-------* SG1*----------* SG2*-------*MGC * 547 ****** ****** ****** ****** 549 +----+ +----+ 550 |S7UP| |S7UP| 551 +----+ +----+----+ +----+ 552 |MTP3| |MTP3| | | | 553 +----+ +---------+ +----+ CTP| |CTP | 554 |MTP2| |MTP2|CTP | |CTP | | | | 555 + + + +----+ +----+----+ +----+ 556 | | | | IP | | IP | | IP | 557 +----+ +----+----+ +----+----+ +----+ 559 S7UP - SS7 User Part 561 Figure 9: SG to SG Case 1 563 The following figure describes a more generic use of 564 SS7-IP interworking for transport of SS7 upper layer 565 signaling across an IP network, where the endpoints are 566 both SS7 SEPs. 568 ****** SS7 ****** IP ****** SS7 ****** 569 *SEP *--------* SG *-----------* SG *--------*SEP * 570 ****** ****** ****** ****** 572 +----+ +-----+ 573 |S7UP| | S7UP| 574 +----+ +-----+ 575 |MTP3| | MTP3| 576 +----+ +---------+ +---------+ +-----+ 577 |MTP2| |MTP2| CTP| |CTP |MTP2| | MTP2| 578 + + + +----+ +----+ + + + 579 | | | | IP | | IP | | | | 580 +----+ +----+----+ +----+----+ +-----+ 582 Figure 10: SG to SG Case 2 584 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [13] 586 4. Functional Requirements 588 Signaling transport provides for the transport of native SCN protocol 589 messages over a packet switched network. 591 Signaling transport shall: 593 1) Transport of a variety of SCN protocol types, such as the application 594 and user parts of SS7 (including MTP Level 3, ISUP, SCCP, TCAP, MAP, INAP, 595 IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG). 597 2) Provide a means to identify the particular SCN protocol being 598 transported. 600 3) Provide a common base protocol defining header formats, security 601 extensions and procedures for signaling transport, and support 602 extensions as necessary to add individual SCN protocols if and when 603 required. 605 4) In conjunction with the underlying network protocol (IP) and transport 606 protocol (CTP), provide the relevant functionality as defined 607 by the appropriate SCN lower layer. 609 Relevant functionality may include (according to the protocol being 610 transported): 612 - flow control 613 - in sequence delivery of signaling messages within a control stream 614 - logical identification of the entities on which the signaling messages 615 originate or terminate 616 - logical identification of the physical interface controlled by the 617 signaling message 618 - error detection 619 - recovery from failure of components in the transit path 620 - retransmission and other error correcting methods 621 - detection of unavailability of peer entities. 623 For example: 625 - if the native SCN protocol is ISUP or SCCP, the relevant functionality 626 provided by MTP2/3 shall be provided. 627 - if the native SCN protocol is TCAP, the relevant functionality 628 provided by SCCP and MTP 2/3 shall be supported. 629 - if the native SCN protocol is Q.931, the relevant functionality 630 provided by Q.921 shall be supported. 631 - if the native SCN protocol is MTP3, the relevant functionality of MTP2 632 shall be supported. 634 5) Support the ability to multiplex several higher layer SCN sessions on 635 one underlying signaling transport session. This allows, for example, 636 several DSS1 D-Channel sessions to be carried in one signaling 637 transport session. 639 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [14] 641 In general, in-sequence delivery is required for signaling messages 642 within a single control stream, but is not necessarily required 643 for messages that belong to different control streams. The protocol 644 should if possible take advantage of this property to avoid blocking 645 delivery of messages in one control stream due to sequence error within 646 another control stream. However, the SG will not be required to process 647 the SCN application protocol in order to identify control streams. 649 6) Be able to transport complete messages of greater length than the 650 underlying SCN segmentation/reassembly limitations. For example, 651 signaling transport should not be constrained by the length limitations 652 defined for SS7 lower layer protocol (e.g. 272 bytes in the case of 653 narrowband SS7) but should be capable of carrying longer messages 654 without requiring segmentation. 656 7) Allow for a range of suitably robust security schemes to protect 657 signaling information being carried across networks. For example, 658 signaling transport shall be able to operate over proxyable sessions, 659 and be able to be transported through firewalls. 661 8) Provide for congestion avoidance on the Internet, by supporting 662 appropriate controls on signaling traffic generation (including 663 signaling generated in SCN) and reaction to network congestion. 665 4.2 Performance of SCN Signaling Protocols 667 This section provides basic values regarding performance requirements 668 of key SCN protocols to be transported. Currently only messaged based 669 SCN protocols are considered. Failure to meet these requirements 670 is likely to result in adverse and undesirable signaling and call 671 behavior. 673 4.2.1 SS7 MTP requirements 675 The performance requirements below have been specified for 676 transport of MTP Level 3 network management messages. The requirements 677 given here are only applicable if all MTP Level 3 messages are to be 678 transported over the IP network. 680 - Message Delay 681 - MTP Level 3 peer-to-peer procedures require response within 682 500 to 1200 ms when terrestrial signaling links are used. This 683 value includes round trip time and processing at the remote end. 684 Failure to meet this limitation will result in the initiation of 685 error procedures for specific timers, e.g., timer T4 of ITU-T 686 Recommendation Q.704. 688 4.2.2 SS7 MTP Level 3 requirements 690 The performance requirements below have been specified for transport of 691 MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7]. 693 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [15] 695 - Message Loss 696 - no more than 1 in 10E+7 messages will be lost due to transport 697 failure 699 - Sequence Error 700 - no more than 1 in 10E+10 messages will be delivered out-of-sequence 701 (including duplicated messages) due to transport failure 703 - Message Errors 704 - no more than 1 in 10E+10 messages will contain an error that is 705 undetected by the transport protocol (requirement is 10E+9 for 706 ANSI specifications) 708 - Availability 709 - availability of any signaling route set is 99.9998% or better, 710 i.e., downtime 10 min/year or less. A signaling route set is 711 the complete set of allowed signaling paths from a given 712 signaling point towards a specific destination. 714 - Message length (payload accepted from SS7 user parts) 715 - 272 bytes for narrowband SS7, 4091 bytes for broadband SS7 717 4.2.3 SS7 User Part Requirements 719 ISUP Message Delay - Protocol Timer Requirements 721 - to be provided. 723 ISUP Message Delay - End-to-End Requirements 725 - to be provided. 727 TCAP Requirements - End-to-End Requirements 729 - to be provided. 731 4.2.4 ISDN Signaling Requirements 733 Q.931 Message Delay 735 - round-trip delay should not exceed 4 seconds. 736 A timer of this length is used for a number of procedures, esp. 737 RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where 738 excessive delay may result in management action on the 739 channel, or release of a call being set up. Note: while this 740 value is indicated by protocol timer specifications, faster 741 response time is normally expected by the user. 743 - 12 sec. timer (T309) is used to maintain an active call 744 in case of loss of the data link, pending re-establishment. 745 The related ETSI documents specify a maximum value of 4 seconds 746 while ANSI specifications [T1.607] default to 90 seconds. 748 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [16] 750 5. Management 752 Operations, Administration & Management (OA&M) of IP networks or SCN 753 networks is outside the scope of SIGTRAN. Examples of OA&M include 754 legacy telephony management systems or IETF SNMP managers. OA&M 755 implementors and users should be aware of the functional interactions 756 of the SG, MGC and MG and the physical units they occupy. 758 6. Security 760 6.1 Security requirements 762 When SCN related signaling is transported over an IP network 763 two possible network scenarios can be distinguished: 765 - Signaling transported only within an Intranet; 766 Security measures are applied at the discretion of the network 767 owner. 769 - Signaling transported, at least to some extent, in the public 770 Internet; 771 The public Internet should be regarded generally as an "insecure" 772 network and usage of security measures is required. 774 Generally security comprises several aspects 776 - Authentication: 777 It is required to ensure that the information is sent to/from a known 778 and trusted partner. 780 - Integrity: 781 It is required to ensure that the information hasn't been modified 782 while in transit. 784 - Confidentiality: 785 It might be sometimes required to ensure that the transported 786 information is encrypted to avoid illegal use. 788 - Availability: 789 It is required that the communicating endpoints remain in 790 service for authorized use even if under attack. 792 6.2 Security mechanisms currently available in IP networks 794 Several security mechanisms are currently available for use in IP networks. 796 - IPSEC ([RFC2401]): 797 IPSEC provides security services at the IP layer that address the above 798 mentioned requirements. It defines the two protocols AH and ESP 799 respectively that 800 essentially provide data integrity and data 801 confidentiality services. 803 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [17] 805 The ESP mechanism can be used in two different modes: 806 - Transport mode; 807 - Tunnel mode. 808 In Transport mode IPSEC protects the higher layer protocol data 809 portion of an IP packet, while in Tunnel mode a complete IP packet 810 is encapsulated in a secure IP tunnel. 812 If the CTP embeds any IP addresses outside of the SA/DA in the IP 813 header, passage through a NAT function will cause problems. The same 814 is true for using IPsec in general, unless an IPsec ready RSIP 815 function is used as described in draft-ietf-nat-terminology-02.txt. 817 The use of IPSEC does not hamper the use of TCP or UDP as the 818 underlying basis of CTP. If automated distribution of keys is 819 required the IKE protocol (RFC[2409]) can be applied. 821 - SSL, TLS ([RFC2246]): 822 SSL and TLS also provide appropriate security services but operate on 823 top of TCP/IP only. 825 It is not required to define new security mechanisms in CTP, as the 826 use of currently available mechanisms is sufficient to provide the 827 necessary security. It is recommended that IPSEC or some equivalent 828 method be used, especially when transporting SCN signaling over 829 public Internet. 831 7. Abbreviations 833 CAS Channel-Associated Signaling 834 CTP Common Transport Protocol 835 DSS1 Digital Subscriber Signaling 836 INAP Intelligent Network Application Part 837 ISEP IP Signaling End Point 838 ISUP Signaling System 7 ISDN User Part 839 MAP Mobile Application Part 840 MG Media Gateway 841 MGU Media Gateway Unit 842 MGC Media Gateway Controller 843 MGCU Media Gateway Controller Unit 844 MTP Signaling System 7 Message Transfer Part 845 PLMN Public Land Mobile Network 846 PSTN Public Switched Telephone Network 847 S7AP SS7 Application Part 848 S7UP SS7 User Part 849 SCCP SS7 Signaling Connection Control Part 850 SCN Switched Circuit Network 851 SEP Signaling End Point 852 SG Signaling Gateway 853 SS7 Signaling System No. 7 854 TCAP Signaling System 7 Transaction Capabilities Part 856 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01.txt [18] 858 8. Acknowledgements 860 The authors would like to thank K. Chong, I. Elliott, Ian Spiers, 861 Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom 862 for their valuable comments and suggestions. 864 9. References 866 [NAT] IP Network Address Translator (NAT) Terminology and Considerations 867 , P. Srisurech and M. Holdrege, April 868 1999, work in progress. 870 [PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures 871 and Protocol (QSIG-BC) 873 [Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface layer 3 874 specification (5/98) 876 [SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7 878 [SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of SS7 880 [T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1) 881 - Layer 3 Signaling Specification for Circuit-Switched Bearer Services 883 Authors' Contact Information 885 Lyndon Ong Ian Rytina 886 Nortel Networks Ericsson Australia 887 4401 Great America Parkway 37/360 Elizabeth Street 888 Santa Clara, CA 95054, USA Melbourne, Victoria 3000, Australia 889 long@nortelnetworks.com ian.rytina@ericsson.com 891 Matt Holdrege Lode Coene 892 Ascend Communications Siemens Atea 893 1701 Harbor Bay Parkway Atealaan 34 894 Alameda, CA 94502 USA Herentals, Belgium 895 matt@ascend.com lode.coene@ntnet.atea.be 897 Miguel-Angel Garcia Chip Sharp 898 Ericsson Espana Cisco Systems 899 Retama 7 7025 Kit Creek Road 900 28005 Madrid, Spain Res Triangle Pk, NC 27709, USA 901 Miguel.A.Garcia@ericsson.com chsharp@cisco.com 903 Imre Juhasz Haui-an Paul Lin 904 Telia Telcordia Technologies 905 Sweden Piscataway, NJ, USA 906 imre.i.juhasz@telia.se hlin@research.telcordia.com 908 Hanns Juergen Schwarzbauer 909 Siemens AG 910 Munich, Germany 911 HannsJuergen.Schwarzbauer@ICN.SIEMENS.DE 913 INTERNET-DRAFT draft-ietf-sigtran-framework-arch-01. txt [19]