idnits 2.17.1 draft-ietf-sigtran-framework-arch-03.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 6 months document validity. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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 21 instances of too long lines in the document, the longest one being 77 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 116 has weird spacing: '...traffic to th...' == Line 784 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 ---------------------------------------------------------------------------- == Missing Reference: 'SG' is mentioned on line 280, but not defined == Missing Reference: 'MGC' is mentioned on line 389, but not defined == Missing Reference: 'MG' is mentioned on line 395, but not defined == Missing Reference: 'SG1' is mentioned on line 314, but not defined == Missing Reference: 'RFC2401' is mentioned on line 808, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) -- Looks like a reference, but probably isn't: '2409' on line 829 == Missing Reference: 'RFC2246' is mentioned on line 831, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Unused Reference: 'NAT' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'SS7 MTP' is defined on line 885, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 3 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 June 1999 HannsJuergen Schwarzbauer, Lode Coene, Siemens 6 Expires: January 2000 Huai-an Paul Lin, Telcordia 7 Imre Juhasz, Telia 8 Matt Holdrege, Ascend 9 Chip Sharp, Cisco Systems 11 Framework Architecture for Signaling Transport 12 < draft-ietf-sigtran-framework-arch-03.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 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 defines an architecture framework and functional 31 requirements for transport of signaling information over IP. The 32 framework describes relationships between functional and physical 33 entities exchanging signaling information, such as Signaling Gateways 34 and Media Gateway Controllers. It identifies interfaces where 35 signaling transport may be used and the functional and performance 36 requirements that apply from existing Switched Circuit Network (SCN) 37 signaling protocols. 39 Table of Contents 41 1. Introduction..............................................2 42 1.1 Overview.................................................2 43 1.2 Terminology..............................................2 44 1.3 Scope...................................................4 45 2. Signaling Transport Architecture.........................5 46 2.1 Gateway Component Functions.............................5 47 2.2 SS7 Interworking for Connection Control.................6 48 2.3 ISDN Interworking for Connection Control................8 49 2.4 Architecture for Database Access........................9 50 3. Protocol Architecture....................................10 51 3.1. Signaling Transport Components.........................10 52 3.2. SS7 access for Media Gateway Control...................11 53 3.3. Q.931 Access to MGC....................................12 54 3.4. SS7 Access to IP/SCP...................................12 55 3.5. SG to SG...............................................13 56 4. Functional Requirements..................................15 57 5. Management...............................................18 58 6. Security.................................................18 59 7. Abbreviations............................................20 60 8. Acknowledgements.........................................20 61 9. References...............................................20 62 Authors' Contact Information................................21 64 1. Introduction 66 1.1 Overview 68 This document defines an architecture framework for transport of 69 message-based signaling protocols over IP networks. The scope of 70 this work includes definition of encapsulation methods, end-to-end 71 protocol mechanisms and use of existing IP capabilities to support 72 the functional and performance requirements for signaling transport. 74 The framework portion describes the relationships between functional 75 and physical entities used in signaling transport, including the 76 framework for control of Media Gateways, and other scenarios where 77 signaling transport may be required. 79 The requirements portion describes functional and performance 80 requirements for signaling transport such as flow control, in-sequence 81 delivery and other functions that may be required for specific SCN 82 signaling protocols. 84 1.2 Terminology 86 The following are general terms are used in this document: 88 Backhaul: 90 Backhaul refers to the transport of signaling from the point of interface for 91 the associated data stream (i.e., SG function in the MGU) back to the 92 point of call processing (i.e., the MGCU), if this is not local. 94 Signaling Transport (SIG): 96 SIG refers to a protocol stack for transport of SCN signaling protocols 97 over an IP network. It will support standard primitives to interface 98 with an unmodified SCN signaling application being transported, and 99 supplements a standard IP transport protocol underneath with functions 100 designed to meet transport requirements for SCN signaling. 102 Switched Circuit Network (SCN): 104 The term SCN is used to refer to a network that carries traffic within 105 channelized bearers of pre-defined sizes. Examples include Public 106 Switched Telephone Networks (PSTNs) and Public Land Mobile Networks 107 (PLMNs). Examples of signaling protocols used in SCN include Q.931, 108 SS7 MTP Level 3 and SS7 Application/User parts. 110 The following are terms for functional entities relating to signaling 111 transport in a distributed gateway model. 113 Media Gateway (MG): 115 A MG terminates SCN media streams, packetizes the media data,, if it 116 is not already packetized, and delivers packetized traffic to the 117 packet network. It performs these functions in reverse order for media 118 streams flowing from the packet network to the SCN. 120 Media Gateway Controller (MGC): 122 An MGC handles the registration and management of resources at the MG. 123 The MGC may have the ability to authorize resource usage based on local 124 policy. For signaling transport purposes, the MGC serves as a possible 125 termination and origination point for SCN application protocols, such 126 as SS7 ISDN User Part and Q.931/DSS1. 128 Signaling Gateway (SG): 130 An SG is a signaling agent that receives/sends SCN native signaling at 131 the edge of the IP network. The SG function may relay, translate or 132 terminate SS7 signaling in an SS7-Internet Gateway. The SG function may 133 also be co-resident with the MG function to process SCN signaling associated 134 with line or trunk terminations controlled by the MG (e.g., signaling backhaul). 136 The following are terms for physical entities relating to signaling 137 transport in a distributed gateway model: 139 Media Gateway Unit (MGU) 141 An MG-Unit is a physical entity that contains the MG function. It may 142 contain other functions, esp. an SG function for handling facility- 143 associated signaling. 145 Media Gateway Control Unit (MGCU) 147 An MGC-Unit is a physical entity containing the MGC function. 149 Signaling Gateway Unit (SGU) 151 An SG-Unit is a physical entity containing the SG function. 153 Signaling End Point (SEP): 155 This is a node in an SS7 network that originates or terminates signaling 156 messages. One example is a central office switch. 158 Signal Transfer Point (STP): 160 This is a node in an SS7 network that routes signaling messages based on 161 their destination point code in the SS7 network 163 1.3 Scope 165 Signaling transport provides transparent transport of message-based 166 signaling protocols over IP networks. The scope of this work includes 167 definition of encapsulation methods, end-to-end protocol mechanisms and 168 use of IP capabilities to support the functional and performance 169 requirements for signaling. 171 Signaling transport shall be used for transporting SCN signaling 172 between a Signaling Gateway Unit and Media Gateway Controller Unit. 173 Signaling transport may also be used for transport of message-based 174 signaling between a Media Gateway Unit and Media Gateway Controller 175 Unit, between dispersed Media Gateway Controller Units, and between two 176 Signaling Gateway Units connecting signaling endpoints or signal 177 transfer points in the SCN. 179 Signaling transport will be defined in such a way as to support 180 encapsulation and carriage of a variety of SCN protocols. It 181 is defined in such a way as to be independent of any SCN protocol 182 translation functions taking place at the endpoints of the signaling 183 transport, since its function is limited to the transport of 184 the SCN protocol. 186 Since the function being provided is transparent transport, the following 187 areas are considered outside the scope of the signaling transport work: 189 - definition of the SCN protocols themselves 190 - signaling interworking such as conversion from Channel Associated 191 Signaling (CAS) to message signaling protocols 192 - specification of the functions taking place within the SGU or MGU 193 - in particular, this work does not address whether the SGU provides 194 mediation/interworking, as this is transparent to the transport 195 function. 196 - similarly, some management and addressing functions taking place 197 within the SGU or MGU are also considered out of scope, 198 such as determination of the destination IP address for signaling, 199 or specific procedures for assessing the performance of the transport 200 session (i.e., testing and proving functions). 202 2. Signaling Transport Architecture 204 2.1 Gateway Component Functions 206 Figure 1 defines a commonly defined functional model 207 that separates out the functions of SG, MGC and MG. This model may be 208 implemented in a number of ways, with functions implemented in separate 209 devices or combined in single physical units. 211 Where physical separation exists between functional entities, Signaling 212 Transport can be applied to ensure that SCN signaling information is 213 transported between entities with the required functionality and 214 performance. 216 +---------------+ +--------------+ 217 | | | | 218 SCN<-------->[SG] <--+---------O------------+--> [SG] <------> SCN 219 signal | | | | | | signal 220 +-------|-------+ +-----|--------+ 221 Signaling|gateway Signaling|gateway (opt) 222 O O 223 | | 224 +-------|-------+ +-----|--------+ 225 | | | | | | 226 | [MGC] <--+--------O-------------+--> [MGC] | 227 | | | | | | 228 | | | | | | 229 +-------|-------+ +-----|--------+ 230 Gateway | controller Gateway | controller (opt) 231 O O 232 | | 233 +-------|-------+ +-----|--------+ 234 Media | | | | | | Media 235 <------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+--------> 236 stream| | | | stream 237 +---------------+ +--------------+ 238 Media gateway Media gateway 240 Figure 1: Sigtran Functional Model 242 As discussed above, the interfaces pertaining to signaling transport 243 include SG to MGC, SG to SG. Signaling transport may potentially be 244 applied to the MGC to MGC or MG to MGC interfaces as well, depending 245 on requirements for transport of the associated signaling protocol. 247 2.2 SS7 Interworking for Connection Control 249 Figure 2 below shows some example implementations of these functions in 250 physical entities as used for interworking of SS7 and IP networks for 251 Voice over IP, Voice over ATM, Network Access Servers, etc. No 252 recommendation is made as to functional distribution and many other 253 examples are possible but are not shown to be concise. The use of 254 signaling transport is independent of the implementation. 256 For interworking with SS7-controlled SCN networks, the SG terminates the 257 SS7 link and transfers the signaling information to the MGC using 258 signaling transport. The MG terminates the interswitch trunk and 259 controls the trunk based on the control signaling it receives from the 260 MGC. As shown below in case (a), the SG, MGC and MG 261 may be implemented in separate physical units, or as in case (b), the 262 MGC and MG may be implemented in a single physical unit. 264 In alternative case (c), a facility-associated SS7 link is terminated 265 by the same device (i.e., the MGU) that terminates the interswitch trunk. 266 In this case, the SG function is co-located with the MG function, as shown 267 below, and signaling transport is used to "backhaul" control signaling to 268 the MGCU. 270 Note: SS7 links may also be terminated directly on the MGCU by 271 cross-connecting at the physical level before or at the MGU. 273 SGU 274 +--------+ 275 SS7<------>[SG] | 276 (ISUP) | | | 277 +---|----+ 278 ST | SGU MGCU 279 +---|----+ +--------+ +--------+ 280 | [MGC] | SS7---->[SG] | | [MGC] | 281 | | | | | | | | | | 282 +---|----+ +---|----+ +--|-|---+ 283 MGCU | ST | | | 284 | | ST | | 285 Media +---|----+ Media +---|----+ +--|-|---+ 286 ------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| | 287 stream | | stream | | Media------> [MG] | 288 +--------+ +--------+ stream +--------+ 289 MGU MGU MGU 291 (a) (b) (c) 292 Notes: ST = Signaling Transport used to carry SCN signaling 294 Figure 2: Example Implementations 296 In some implementations, the function of the SG may be divided into 297 multiple physical entities to support scaling, signaling network 298 management and addressing concerns. Thus, Signaling Transport can be 299 used between SGs as well as from SG to MGC. This is shown in Figure 3 300 below. 302 SGU MGCU 303 +---------+ +---------+ 304 | | ST | | 305 | [SG2]------------------------------>[MGC] | 306 | ^ ^ | | | 307 +---|-|---+ +---------+ 308 | | 309 | | ST 310 ST| +--------------------------------+ 311 | | 312 | | 313 SS7 +---|----------+ SS7 +----|---------+ 314 -----------> [SG1] | -----------> [SG1] | 315 media | | media | | 316 ------------------->[MG] | ------------------->[MG] | 317 stream +--------------+ stream +--------------+ 318 MGU MGU 320 Figure 3: Multiple SG Case 322 In this configuration, there may be more than one MGU handling 323 facility associated signaling (i.e. more than one containing it's 324 own SG function), and only a single SGU. It will therefore be 325 possible to transport one SS7 layer between SG1 and SG2, and 326 another SS7 layer between SG2 and MGC. For example, SG1 could 327 transport MTP3 to SG2, and SG2 could transport ISUP to MGC. 329 2.3 ISDN Interworking for Connection Control 331 In ISDN access signaling, the signaling channel is carried along with 332 data channels, so that the SG function for handling Q.931 signaling 333 is co-located with the MG function for handling the data stream. Where 334 Q.931 is then transported to the MGC for call processing, signaling 335 transport would be used between the SG function and MGC. This is shown 336 in Figure 3 below. 338 MGCU 339 +-------------+ 340 | [MGC] | 341 | | | | 342 +-----|-|-----+ 343 | | 344 | O device control 345 | | 346 Q.931/ST O | 347 | | 348 +-----|-|-----+ 349 | | | | 350 Q.931---->[SG]| | 351 signals| | | 352 | | | 353 Media---->[MG] | 354 stream | | 355 +-------------+ 356 MGU 358 Figure 4: Q.931 transport model 360 2.4 Architecture for Database Access 362 Transaction Capabilities (TCAP) is the application part within SS7 363 that is used for non-circuit-related signaling. 365 TCAP signaling within IP networks may be used for cross-access between 366 entities in the SS7 domain and the IP domain, such as, for example: 367 - access from an SS7 network to a Service Control Point (SCP) in IP 368 - access from an SS7 network to an MGC 369 - access from an MGC to an SS7 network element 370 - access from an IP SCP to an SS7 network element 372 A basic functional model for TCAP over IP is shown in Figure 5. 374 +--------------+ 375 | IP SCP | 376 +--|----|------+ 377 | | 378 SGU | | SGU 379 +--------------+ | | +--------------+ 380 | | | | | | 381 SS7<--------->[SG] ---------+ | | [SG]<---------> SS7 382 (TCAP) | | | | | | | 383 +------|-------+ | +------|-------+ 384 | | | 385 O +------------+ O 386 MGCU | | | MGCU 387 +-------|----|--+ +-----|--------+ 388 | | | | | | | 389 | [MGC] | | [MGC] | 390 | | | | | | 391 +-------|-------+ +-----|--------+ 392 | | 393 +-------|-------+ +-----|------+ 394 Media | | | | | | Media 395 <------+---->[MG] <---+--RTP stream---+--> [MG] <-+--------> 396 stream| | | | stream 397 +---------------+ +------------+ 398 MGU MGU 400 Figure 5: TCAP Signaling over IP 402 3. Protocol Architecture 404 This section provides a series of examples of protocol architecture 405 for the use of Signaling Transport (SIG). 407 3.1 Signaling Transport Components 409 Signaling Transport in the protocol architecture figures below is 410 assumed to consist of three components (see Figure 6): 412 1) an adaptation sub-layer that supports specific primitives, e.g., 413 management indications, required by a particular SCN signaling 414 application protocol. 415 2) a Common Signaling Transport Protocol that supports a common set 416 of reliable transport functions for signaling transport. 417 3) a standard, unmodified IP transport protocol. 419 +-- +--------------------------------+ 420 | | SCN adaptation module | 421 | +--------------------------------+ 422 | | 423 S | +--------------------------------+ 424 I | | Common Signaling Transport | 425 G | +--------------------------------+ 426 | | 427 | +--------------------------------+ 428 | | standard IP transport | 429 +-- +--------------------------------+ 431 Figure 6: Signaling Transport Components 433 3.2. SS7 access for Media Gateway Control 435 This section provides a protocol architecture for signaling transport 436 supporting SS7 access for Media Gateway Control. 438 ****** SS7 ******* SS7 ****** IP ******* 439 *SEP *--------* STP *------* SG *------------* MGC * 440 ****** ******* ****** ******* 442 +----+ +-----+ 443 |ISUP| | ISUP| 444 +----+ +-----+ +---------+ +-----+ 445 |MTP | |MTP | |MTP | SIG| | SIG | 446 |L1-3| |L1-3 | |L1-3+----+ +-----+ 447 | | | | | | IP | | IP | 448 +----+ +-----+ +---------+ +-----+ 450 STP - Signal Transfer Point SEP - Signaling End Point 451 SG - Signaling Gateway SIG - Signaling Transport 452 MGC - Media Gateway Controller 454 Figure 7: SS7 Access to MGC 456 3.3. Q.931 Access to MGC 458 This section provides a protocol architecture for signaling transport 459 supporting ISDN point-to-point access (Q.931) for Media Gateway Control. 461 ****** ISDN ********* IP ******* 462 * EP *--------------* SG/MG *------------* MGC * 463 ****** ********* ******* 465 +----+ +-----+ 466 |Q931| | Q931| 467 +----+ +---------+ +-----+ 468 |Q921| |Q921| SIG| | SIG | 469 + + + +----+ +-----+ 470 | | | | IP | | IP | 471 +----+ +---------+ +-----+ 473 MG/SG - Media Gateway with SG function for backhaul 474 EP - ISDN End Point 476 Figure 8: ISDN Access 478 3.4. SS7 Access to IP/SCP 480 This section provides a protocol architecture for database 481 access, for example providing signaling between two IN 482 nodes or two mobile network nodes. There are a number of 483 scenarios for the protocol stacks and the functionality 484 contained in the SIG, depending on the SS7 application. 486 In the diagrams, SS7 Application Part (S7AP) is used for 487 generality to cover all Application Parts (e.g. MAP, IS-41, 488 INAP, etc). Depending on the protocol being transported, S7AP may or 489 may not include TCAP. The interface to the SS7 layer below 490 S7AP can be either the TC-user interface or the SCCP-user 491 interface. 493 Figure 9a shows the scenario where SCCP is the signaling 494 protocol being transported between the SG and an IP Signaling 495 Endpoint (ISEP), that is, an IP destination supporting some 496 SS7 application protocols. 498 ****** SS7 ******* SS7 ****** IP ******* 499 *SEP *--------* STP *------* SG *-------------* ISEP* 500 ****** ******* ****** ******* 502 +-----+ +-----+ 503 |S7AP | |S7AP | 504 +-----+ +-----+ 505 |SCCP | |SCCP | 506 +-----+ +-----+ +---------+ +-----+ 507 |MTP | |MTP | |MTP |SIG | |SIG | 508 + + + + + +----+ +-----+ 509 | | | | | | IP | |IP | 510 +-----+ +-----+ +---------+ +-----+ 512 Figure 9a: SS7 Access to IP node - SCCP being transported 514 Figure 9b shows the scenario where S7AP is the signaling 515 protocol being transported between SG and ISEP. Depending on 516 the protocol being transported, S7AP may or may not include TCAP, 517 which implies that SIG must be able to support both the TC-user 518 and the SCCP-user interfaces. 520 ****** SS7 ******* SS7 ****** IP ******* 521 *SEP *--------* STP *------* SG *-------------* ISEP* 522 ****** ******* ****** ******* 524 +-----+ +-----+ 525 |S7AP | |S7AP | 526 +-----+ +----+----+ +-----+ 527 |SCCP | |SCCP| | | | 528 +-----+ +-----+ +----|SIG | |SIG | 529 |MTP | |MTP | |MTP | | | | 530 + + + + + +----+ +-----+ 531 | | | | | |IP | |IP | 532 +-----+ +-----+ +---------+ +-----+ 534 Figure 9b: SS7 Access to IP node - S7AP being transported 536 3.5. SG to SG 538 This section identifies a protocol architecture for support of 539 signaling between two endpoints in an SCN signaling 540 network, using signaling transport directly between two SGs. 542 The following figure describes protocol architecture for a 543 scenario with two SGs providing different levels of function 544 for interworking of SS7 and IP. This corresponds to the scenario 545 given in Figure 3. 547 The SS7 User Part (S7UP) shown is an SS7 protocol using MTP directly 548 for transport within the SS7 network, for example, ISUP. 550 In this scenario, there are two different usage cases of SIG, 551 one which transports MTP3 signaling, the other which transports 552 ISUP signaling. 554 ****** SS7 ****** IP ****** IP ****** 555 *SEP *-------* SG1*----------* SG2*-------*MGC * 556 ****** ****** ****** ****** 558 +----+ +----+ 559 |S7UP| |S7UP| 560 +----+ +----+----+ +----+ 561 |MTP3| |MTP3| | | | 562 +----+ +---------+ +----+ SIG| |SIG | 563 |MTP2| |MTP2|SIG | |SIG | | | | 564 + + + +----+ +----+----+ +----+ 565 | | | | IP | | IP | | IP | 566 +----+ +----+----+ +----+----+ +----+ 568 S7UP - SS7 User Part 570 Figure 10: SG to SG Case 1 572 The following figure describes a more generic use of 573 SS7-IP interworking for transport of SS7 upper layer 574 signaling across an IP network, where the endpoints are 575 both SS7 SEPs. 577 ****** SS7 ****** IP ****** SS7 ****** 578 *SEP *--------* SG *-----------* SG *--------*SEP * 579 ****** ****** ****** ****** 581 +----+ +-----+ 582 |S7UP| | S7UP| 583 +----+ +-----+ 584 |MTP3| | MTP3| 585 +----+ +---------+ +---------+ +-----+ 586 |MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2| 587 + + + +----+ +----+ + + + 588 | | | | IP | | IP | | | | 589 +----+ +----+----+ +----+----+ +-----+ 591 Figure 11: SG to SG Case 2 593 4. Functional Requirements 595 Signaling transport provides for the transport of native SCN protocol 596 messages over a packet switched network. 598 Signaling transport shall: 600 1) Transport of a variety of SCN protocol types, such as the application 601 and user parts of SS7 (including MTP Level 3, ISUP, SCCP, TCAP, MAP, INAP, 602 IS-41, etc.) and layer 3 of the DSS1/PSS1 protocols (i.e. Q.931 and QSIG). 604 2) Provide a means to identify the particular SCN protocol being 605 transported. 607 3) Provide a common base protocol defining header formats, security 608 extensions and procedures for signaling transport, and support 609 extensions as necessary to add individual SCN protocols if and when 610 required. 612 4) In conjunction with the underlying network protocol (IP), provide the relevant functionality as defined by the appropriate SCN lower layer. 614 Relevant functionality may include (according to the protocol being 615 transported): 617 - flow control 618 - in sequence delivery of signaling messages within a control stream 619 - logical identification of the entities on which the signaling messages 620 originate or terminate 621 - logical identification of the physical interface controlled by the 622 signaling message 623 - error detection 624 - recovery from failure of components in the transit path 625 - retransmission and other error correcting methods 626 - detection of unavailability of peer entities. 628 For example: 630 - if the native SCN protocol is ISUP or SCCP, the relevant functionality 631 provided by MTP2/3 shall be provided. 632 - if the native SCN protocol is TCAP, the relevant functionality 633 provided by SCCP connectionless classes and MTP 2/3 shall be supported. 634 - if the native SCN protocol is Q.931, the relevant functionality 635 provided by Q.921 shall be supported. 636 - if the native SCN protocol is MTP3, the relevant functionality of MTP2 637 shall be supported. 639 5) Support the ability to multiplex several higher layer SCN sessions on 640 one underlying signaling transport session. This allows, for example, 641 several DSS1 D-Channel sessions to be carried in one signaling 642 transport session. 644 In general, in-sequence delivery is required for signaling messages 645 within a single control stream, but is not necessarily required 646 for messages that belong to different control streams. The protocol 647 should if possible take advantage of this property to avoid blocking 648 delivery of messages in one control stream due to sequence error within 649 another control stream. The protocol should also allow the SG to send 650 different control streams to different destination ports if desired. 652 6) Be able to transport complete messages of greater length than the 653 underlying SCN segmentation/reassembly limitations. For example, 654 signaling transport should not be constrained by the length limitations 655 defined for SS7 lower layer protocol (e.g. 272 bytes in the case of 656 narrowband SS7) but should be capable of carrying longer messages 657 without requiring segmentation. 659 7) Allow for a range of suitably robust security schemes to protect 660 signaling information being carried across networks. For example, 661 signaling transport shall be able to operate over proxyable sessions, 662 and be able to be transported through firewalls. 664 8) Provide for congestion avoidance on the Internet, by supporting 665 appropriate controls on signaling traffic generation (including 666 signaling generated in SCN) and reaction to network congestion. 668 4.2 Performance of SCN Signaling Protocols 670 This section provides basic values regarding performance requirements 671 of key SCN protocols to be transported. Currently only message-based 672 SCN protocols are considered. Failure to meet these requirements 673 is likely to result in adverse and undesirable signaling and call 674 behavior. 676 4.2.1 SS7 MTP requirements 678 The performance requirements below have been specified for 679 transport of MTP Level 3 network management messages. The requirements 680 given here are only applicable if all MTP Level 3 messages are to be 681 transported over the IP network. 683 - Message Delay 684 - MTP Level 3 peer-to-peer procedures require response within 685 500 to 1200 ms. This value includes round trip time and processing 686 at the remote end. 687 Failure to meet this limitation will result in the initiation of 688 error procedures for specific timers, e.g., timer T4 of ITU-T 689 Recommendation Q.704. 691 4.2.2 SS7 MTP Level 3 requirements 693 The performance requirements below have been specified for transport of 694 MTP Level 3 user part messages as part of ITU-T SS7 Recommendations [SS7]. 696 - Message Loss 697 - no more than 1 in 10E+7 messages will be lost due to transport 698 failure 700 - Sequence Error 701 - no more than 1 in 10E+10 messages will be delivered out-of-sequence 702 (including duplicated messages) due to transport failure 704 - Message Errors 705 - no more than 1 in 10E+10 messages will contain an error that is 706 undetected by the transport protocol (requirement is 10E+9 for 707 ANSI specifications) 709 - Availability 710 - availability of any signaling route set is 99.9998% or better, 711 i.e., downtime 10 min/year or less. A signaling route set is 712 the complete set of allowed signaling paths from a given 713 signaling point towards a specific destination. 715 - Message length (payload accepted from SS7 user parts) 716 - 272 bytes for narrowband SS7, 4091 bytes for broadband SS7 718 4.2.3 SS7 User Part Requirements 720 More detailed analysis of SS7 User Part Requirements can be found in 721 [Lin]. 723 ISUP Message Delay - Protocol Timer Requirements 725 - one example of ISUP timer requirements is the Continuity Test 726 procedure, which requires that a tone generated at the sending 727 end be returned from the receiving end within 2 seconds of 728 sending an IAM indicating continuity test. This implies that 729 one way signaling message transport, plus accompanying nodal 730 functions need to be accomplished within 2 seconds. 732 ISUP Message Delay - End-to-End Requirements 734 - the requirement for end-to-end call setup delay in ISUP is 735 that an end-to-end response message be received within 20-30 seconds 736 of the sending of the IAM. Note: while this is the protocol guard 737 timer value, users will generally expect faster response time. 739 TCAP Requirements - Delay Requirements 741 - TCAP does not itself define a set of delay requirements. Some 742 work has been done [Lin2] to identify application-based delay 743 requirements for TCAP applications. 745 4.2.4 ISDN Signaling Requirements 747 Q.931 Message Delay 749 - round-trip delay should not exceed 4 seconds. 750 A timer of this length is used for a number of procedures, esp. 751 RELEASE/RELEASE COMPLETE and CONNECT/CONNECT ACK where 752 excessive delay may result in management action on the 753 channel, or release of a call being set up. Note: while this 754 value is indicated by protocol timer specifications, faster 755 response time is normally expected by the user. 757 - 12 sec. timer (T309) is used to maintain an active call 758 in case of loss of the data link, pending re-establishment. 759 The related ETSI documents specify a maximum value of 4 seconds 760 while ANSI specifications [T1.607] default to 90 seconds. 762 5. Management 764 Operations, Administration & Management (OA&M) of IP networks or SCN 765 networks is outside the scope of SIGTRAN. Examples of OA&M include 766 legacy telephony management systems or IETF SNMP managers. OA&M 767 implementors and users should be aware of the functional interactions 768 of the SG, MGC and MG and the physical units they occupy. 770 6. Security 772 6.1 Security requirements 774 When SCN related signaling is transported over an IP network 775 two possible network scenarios can be distinguished: 777 - Signaling transported only within an Intranet; 778 Security measures are applied at the discretion of the network 779 owner. 781 - Signaling transported, at least to some extent, in the public 782 Internet; 783 The public Internet should be regarded generally as an "insecure" 784 network and usage of security measures is required. 786 Generally security comprises several aspects 788 - Authentication: 789 It is required to ensure that the information is sent to/from a known 790 and trusted partner. 792 - Integrity: 793 It is required to ensure that the information hasn't been modified 794 while in transit. 796 - Confidentiality: 797 It might be sometimes required to ensure that the transported 798 information is encrypted to avoid illegal use. 800 - Availability: 801 It is required that the communicating endpoints remain in 802 service for authorized use even if under attack. 804 6.2 Security mechanisms currently available in IP networks 806 Several security mechanisms are currently available for use in IP networks. 808 - IPSEC ([RFC2401]): 809 IPSEC provides security services at the IP layer that address the above 810 mentioned requirements. It defines the two protocols AH and ESP 811 respectively that 812 essentially provide data integrity and data 813 confidentiality services. 815 The ESP mechanism can be used in two different modes: 816 - Transport mode; 817 - Tunnel mode. 818 In Transport mode IPSEC protects the higher layer protocol data 819 portion of an IP packet, while in Tunnel mode a complete IP packet 820 is encapsulated in a secure IP tunnel. 822 If the SIG embeds any IP addresses outside of the SA/DA in the IP 823 header, passage through a NAT function will cause problems. The same 824 is true for using IPsec in general, unless an IPsec ready RSIP 825 function is used as described in draft-ietf-nat-terminology-02.txt. 827 The use of IPSEC does not hamper the use of TCP or UDP as the 828 underlying basis of SIG. If automated distribution of keys is 829 required the IKE protocol (RFC[2409]) can be applied. 831 - SSL, TLS ([RFC2246]): 832 SSL and TLS also provide appropriate security services but operate on 833 top of TCP/IP only. 835 It is not required to define new security mechanisms in SIG, as the 836 use of currently available mechanisms is sufficient to provide the 837 necessary security. It is recommended that IPSEC or some equivalent 838 method be used, especially when transporting SCN signaling over 839 public Internet. 841 7. Abbreviations 843 CAS Channel-Associated Signaling 844 DSS1 Digital Subscriber Signaling 845 INAP Intelligent Network Application Part 846 ISEP IP Signaling End Point 847 ISUP Signaling System 7 ISDN User Part 848 MAP Mobile Application Part 849 MG Media Gateway 850 MGU Media Gateway Unit 851 MGC Media Gateway Controller 852 MGCU Media Gateway Controller Unit 853 MTP Signaling System 7 Message Transfer Part 854 PLMN Public Land Mobile Network 855 PSTN Public Switched Telephone Network 856 S7AP SS7 Application Part 857 S7UP SS7 User Part 858 SCCP SS7 Signaling Connection Control Part 859 SCN Switched Circuit Network 860 SEP Signaling End Point 861 SG Signaling Gateway 862 SIG Signaling Transport protocol stack 863 SS7 Signaling System No. 7 864 TCAP Signaling System 7 Transaction Capabilities Part 866 8. Acknowledgements 868 The authors would like to thank K. Chong, I. Elliott, Ian Spiers, 869 Al Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom 870 for their valuable comments and suggestions. 872 9. References 874 [NAT] IP Network Address Translator (NAT) Terminology and Considerations 875 , P. Srisuresh and M. Holdrege, April 876 1999, work in progress. 878 [PSS1/QSIG] ECMA Standard ECMA-143 -Inter-Exchange Signalling Procedures 879 and Protocol (QSIG-BC) 881 [Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network interface layer 3 882 specification (5/98) 883 [SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7 885 [SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part of SS7 887 [T1.607] ANSI T1.607-1998, Digital Subscriber Signaling System Number 1 (DSS1) 888 - Layer 3 Signaling Specification for Circuit-Switched Bearer Services 890 [Lin] Performance Requirements for Signaling in Internet Telephony, , H. Lin, T. Seth, et al, work in progress. 892 [Lin2] Performance Requirements for TCAP Signaling in Internet Telephony, , H. Lin, et al, work in progress. 894 Authors' Contact Information 896 Lyndon Ong Ian Rytina 897 Nortel Networks Ericsson Australia 898 4401 Great America Parkway 37/360 Elizabeth Street 899 Santa Clara, CA 95054, USA Melbourne, Victoria 3000, Australia 900 long@nortelnetworks.com ian.rytina@ericsson.com 902 Matt Holdrege Lode Coene 903 Ascend Communications Siemens Atea 904 1701 Harbor Bay Parkway Atealaan 34 905 Alameda, CA 94502 USA Herentals, Belgium 906 matt@ascend.com lode.coene@ntnet.atea.be 908 Miguel-Angel Garcia Chip Sharp 909 Ericsson Espana Cisco Systems 910 Retama 7 7025 Kit Creek Road 911 28005 Madrid, Spain Res Triangle Pk, NC 27709, USA 912 Miguel.A.Garcia@ericsson.com chsharp@cisco.com 914 Imre Juhasz Haui-an Paul Lin 915 Telia Telcordia Technologies 916 Sweden Piscataway, NJ, USA 917 imre.i.juhasz@telia.se hlin@research.telcordia.com 919 HannsJuergen Schwarzbauer 920 SIEMENS AG 921 Hofmannstr. 51 922 81359 Munich, Germany 923 HannsJuergen.Schwarzbauer@icn.siemens.de