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