idnits 2.17.1 draft-ong-ss7-internet-gateway-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 document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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 an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 149 has weird spacing: '... |Data e...' == Line 476 has weird spacing: '...etworks jiri...' -- 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 ---------------------------------------------------------------------------- No issues found here. Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Expires: November 1998 Internet-Draft 4 Transport Working Group Authors: 5 Internet-Draft R. Dalias 6 Category: Informational J. Matousek 7 May 1998 L. Ong 8 Bay Networks 10 Bay Networks SS7-Internet Gateway Architecture 11 draft-ong-ss7-internet-gateway-01.txt 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress". 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net, 29 ftp.nis.garr.it (Europe), munnari.oz.au (Pacific Rim), 30 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Copyright Notice 34 Copyright (C) The Internet Society (1998). All Rights Reserved. 36 Abstract 38 This memo describes the Bay Networks Gateway architecture for 39 interworking of PSTN SS7 with Internet. Signaling System 7 (SS7) 40 networking is the primary means used in the PSTN for control of 41 circuit-switched connections and value added PSTN services such as 42 freephone (800/888) number translation, calling card validation and 43 Intelligent Network services. The Gateway architecture provides a 44 scalable method of supporting interworking between SS7 network 45 elements and Internet elements such as a Remote Access Server (RAS). 46 The Gateway architecture can support connection control and database 47 access. Gateway design, functions and protocol are described. 49 Table of Contents 51 1. Introduction.................................................2 52 2. Applications.................................................3 53 2.1 Call Control................................................3 54 2.2 Data Base Applications.....................................4 55 2.3 VOIP (Voice over IP).......................................5 56 3. Gateway Architecture.........................................5 57 3.1 Gateway Design.............................................5 58 3.2 Gateway Functions..........................................6 59 3.3 Gateway Protocol...........................................7 60 3.4 Advantages.................................................8 61 Acronyms.......................................................11 62 Contact Information............................................11 64 1. Introduction 66 Signaling System 7 (SS7) is the protocol that supports signaling 67 between telecom network elements, such as switches and service 68 control points. SS7 is in operation throughout the world linking 69 the telecom switching infrastructure. SS7 is used to support many 70 functions, including basic call control, for which it provides 71 essential functions, and call supplementary services such as number 72 translation and calling card validation. 74 .............. ........................ 75 . . 76 . +------+ . 77 . SS7 | / | . 78 . Network | STP | . 79 . | / | . 80 . +------+ . 81 .............../........\.............. 82 / \ 83 / A-link \ A-link 84 / \ 85 / \ 86 +------+ +------+ 87 | PSTN | TDM | PSTN | 88 ----|Switch|--------------|Switch|---- 89 +------+ Circuits +------+ 91 Figure 1: SS7 Architecture for PSTN 93 A gateway to the SS7 network is an essential element to the 94 integration of telecom networks and the Internet that will allow 95 users to operate in a seamless environment for voice and data 96 services. By accessing the telecom network with SS7, data network 97 elements fit cleanly into the telecom network infrastructure as peer 98 switches and control points and can exchange information with 99 telecom network elements for cleaner routing and treatment of 100 connections. 102 This memo describes the architecture for an SS7 to Internet gateway, 103 as implemented for a Bay Networks remote access server (RAS). The 104 memo discusses the gateway design and functions, the protocol used 105 between the gateway and the RAS, and the advantages of the design. 106 Protocol functions include connection setup between telecom switch 107 and RAS, registration and status information exchange for the RAS, 108 and management functions for the channels between switch and RAS. 110 The initial application of SS7 interconnection is to allow Internet 111 access points such as a remote access server to appear to the 112 telecom network as a peer telecom switch, for purposes of 113 terminating calls for Internet access. Future applications include 114 allowing exchange of information between more general nodes within 115 PSTN and Internet, such as a PSTN SCP and an Internet telephony 116 service, or a PSTN switch and an Internet information server, such 117 as a directory. 119 2. Applications 121 2.1 Call Control 123 Because the SS7 signaling is done out of band on a separate network, 124 the end user can obtain 64KBPS clear channel TDM circuits between 125 the switch and the RAS without incurring the cost of PRI. The SS7 126 signaling (call control) is done between the STP and the RAS, which 127 is now classified as a SSP. All call control messages will be sent 128 over the SS7 network and the payload will be sent on the TDM 129 circuits between the switch and the RAS. A simplified diagram below 130 shows the relationship of the STP, PSTN Switch, and the RAS. The 131 diagram shows a dedicated "signaling Internet" used between the RAS 132 and Gateway to ensure physical separation of signaling and data 133 traffic, however other arrangements are possible. 135 ........................ ...... 136 . . . 137 . +------+ . . 138 . SS7 | / | . SS7 . +-------+ 139 . Network | STP |------------|Gateway| 140 . /| / | . . +-------+ 141 . / +------+ . . |S 142 .........../.../........ . |i 143 / / . A|g I 144 __________ / / A-link . S|n n 145 / / . P|a t 146 / / . |ling e 147 +------+ +------+ . +-----+ r 148 | PSTN | | PSTN |-----TDM---------------| RAS |-------n 149 | SCP | |Switch|-----------------------| |Data e 150 +------+ +------+ Circuits . +-----+ t 151 . 152 . 154 Figure 2: SS7-Internet Interworking for Call Setup 156 2.2 Data Base Applications 158 SS7 has the ability for end-to-end routing of messages across the 159 PSTN, using STPs for message routing, and SS7 Message Transfer Part 160 (MTP), Signaling Connection Control Part (SCCP) and Transaction 161 Capabilities Part (TCAP). This supports PSTN database applications 162 such as 800 or freephone number translation, calling card 163 validation, and calling name identification. 165 It may be possible to take advantage of SS7 for data communications 166 as well, as a reliable transport network for highly sensitive 167 traffic, and as a supporting environment for equivalent database 168 applications for data communications, such as billing applications, 169 maintenance and configuration processes, etc. 171 Another application of database capabilities in SS7 could be for 172 trunk group selection to the RAS. Different standards have 173 developed for modem termination that require connections to be 174 terminated on a RAS equipped for a specific modem standard, 175 depending on the caller's modem. Selection of the trunk group 176 corresponding to a particular modem type could be enabled by 177 triggering a query from the telecom switch to the Gateway (which may 178 pass this on to another node) to ask for trunk group selection based 179 on, e.g., called number, calling number, or some other classmark. 181 2.3 VOIP (Voice over IP) 183 Allowing for call termination and origination through the public 184 telephone networks, with direct control over message delivery, is 185 expected to reduce the cost of delivering toll by-pass services. 186 VOIP may require additional features in the future to make it 187 comparable with standard telephony service, including features that 188 are currently implemented using the SS7 network. Remote Access 189 Servers containing both SS7 and VOIP functionality will provide 190 Internet providers with improved ability to launch new voice 191 offerings. 193 In the long run, Service Providers will need to integrate SS7 and IP 194 control capabilities to provide transparency of service to users on 195 PSTN and VOIP networks. Projections that some significant fraction 196 of voice traffic will utilize IP networks in the future suggest that 197 the ability for PSTN users and VOIP users to locate and talk to each 198 other and access similar services will be essential in the future. 199 Transparency of routing and services will be enabled by the 200 connection of PSTN SS7 signaling with directory and service 201 information in IP networks to support number translation, routing 202 and calling 203 card services for calls transiting from PSTN to IP and vice versa. 205 3. Gateway Architecture 207 3.1 Gateway Design 209 The SS7-Internet Gateway needs to take into account a number of 210 factors in its design: 212 - SS7 links are designed to carry signaling for large telecom 213 switches, which handle many more terminations than a single remote 214 access server. A single 56 Kbps SS7 signaling link can support 215 50,000 busy hour call attempts. 217 - the SS7 network addressing scheme is also designed to handle a 218 limited set of signaling points. The ITU version has an address 219 field of 14 bits to identify all signaling points belonging to the 220 international network, while the U.S. national version uses 24 bits 221 to identify signaling points belonging to North American networks. 223 - SS7 protocol layers come in a number of versions, including ITU 224 and various national versions. An SS7-Internet Gateway needs to be 225 able to support these different versions. 227 Taking these factors into account, the Gateway is designed to be a 228 separate entity providing gateway service to a community of RAS 229 devices. This allows consistency with the scaling assumptions for 230 SS7 links and addressing, and also allows the SS7 protocol handling 231 function to be modularized, so that Gateways can be designed to 232 support different SS7 versions without affecting the RAS. 234 Modularizing the Gateway also opens the arrangements for Gateways 235 and RAS devices to allow multiple Gateway and RAS vendors to provide 236 products that interoperate based on a common Gateway-to-RAS 237 protocol. 238 The Gateway will need to support SNMP to support management by 239 remote network management applications, and enable management 240 visibility into the signaling plane performance and status. 241 The Gateway can also serve as a point of security in the future, 242 providing functions such as access to RADIUS servers for 243 authentication, screening on calling party number, and automatic 244 callback. The Gateway will provide open APIs for service development 245 leveraging its basic call processing functions. The addition of 246 Gateway functions will add to the ability of the service provider to 247 support varieties of Service Level offerings to customers. 249 3.2 Gateway Functions 251 ............................ 252 . . 253 . +-----------------+ . 254 . |mapping functions| . 255 . +-----------------+ . 256 . | | . GATEWAY 257 . +------+ +------+ . 258 . | ISUP | | ASP | . 259 . |------| |------| . 260 . | MTP | |TCP/IP| . 261 . +------+ +------+ . 262 .......|...........|........ 263 | | 264 | | 265 SS7 Internet 266 | | 267 | | 268 Telcom Remote 269 Switch Access Server 271 Figure 3: SS7-Internet Gateway Functions 273 The Gateway supports the following functions: 275 - termination of SS7 protocols on the SS7 side, including Message 276 Transfer Part (MTP), ISDN User Part (ISUP), and potentially 277 Signaling Connection Control Part (SCCP) and Transaction 278 Capabilities (TCAP) for database access traffic. Telephony User 279 Part (TUP) may also be supported for some networks. 281 This includes MTP network management functions as required for any 282 SS7 signaling point. 284 - termination of IP and LAN protocols on the Internet side, 285 including TCP, IP, Ethernet and other LAN protocols. 287 - for connection control, termination of the Gateway-RAS protocol, 288 here called the Access Signaling Protocol (ASP). This maps between 289 SS7 ISUP messages and connection setup to the RAS. 291 - mapping of the Point Code and Circuit Identification Code (CIC) on 292 the SS7 side to an IP address and Channel ID associated with the 293 corresponding RAS device on the Internet side. This mapping is 294 created during configuration of the Gateway, and is a static 295 mapping. 297 More generic mapping of SS7 Point Codes and Subsystem Numbers to IP 298 address and application information is needed for future database 299 access features. 301 - support for Gateway redundancy and security features, to ensure 302 that the Gateway reliability and security is consistent with 303 signaling requirements. 305 3.2.1 State Information 307 Some limited state information needs to be maintained at the Gateway 308 to support network management features, including state information 309 for the attached RAS devices and some state information pertaining 310 to the circuits connecting the telecom switch and RAS. 312 3.3 Gateway Protocol 314 A new protocol, the Access Signaling Protocol (ASP) provides the 315 signaling interface between the SS7 Gateway and the Remote Access 316 Server (RAS). This protocol will be defined in detail in a future 317 document. The functions of the protocol include call setup from the 318 telecom switch to the RAS, registration and status management of the 319 RAS-Gateway relationship, and management of the circuits. 321 3.3.1 Call Setup 323 The protocol must support basic call setup and release and provide 324 similar functions and information to the SS7 ISUP call setup and 325 release messages (esp. IAM, ANM, REL and RLC). The messages and 326 parameters will be a subset of the full ISUP protocol, since ISUP 327 standards take into account many situations that are not needed for 328 remote access. 330 The Gateway provides a mapping from a specific interface and channel 331 at the RAS to the equivalent Circuit Identification Code (CIC) used 332 in SS7 to identify that termination at the telecom switch. 334 3.3.2 Registration and Status 336 The protocol must support management of the relationship between the 337 RAS and the Gateway, providing functions such as notification when 338 the RAS is ready to receive or generate traffic, and status of the 339 circuits interfacing to the RAS. 341 3.3.3 Management 343 The Gateway protocol must support circuit network management 344 functions such as the ability to declare circuits out of service in 345 case of failure, and the ability to block circuits. Blocking in SS7 346 terminology prevents future call attempts by one side or the other 347 for the circuit, and results in graceful shutdown of the circuit to 348 allow maintenance actions to take place. During graceful shutdown 349 of a T1 circuit, for example, all DS0 channels gradually revert to 350 the idle state as existing calls are released. When all channels 351 are idle, the T1 can be removed from service. 353 3.3.4 Security 355 The SS7 gateway acts as a fire-wall between the SS7 networks and 356 the IP signaling network. Remote Access Servers on the IP signaling 357 network do not have direct access to the SS7 network - the gateway 358 must proxy for all the required functionality. 360 Both incoming and outgoing calls (from the RAS perspective) will be 361 supported by the protocol. However, configuration option in the 362 gateway and in the RAS must be provided, which will allow the 363 system administrator to inhibit the placement of outgoing calls 364 (from the RAS into the PSTN network). 366 It is also assumed that the IP signaling network will be physically 367 separate from the RAS user traffic. The RAS needs to support two 368 Ethernet interfaces and must ensure that the IP traffic from the 369 user traffic Ethernet cannot be forwarded to the IP signaling 370 traffic Ethernet and vice versa. 372 3.4 Advantages 374 3.4.1 Scaling 376 As discussed above, SS7 was designed for signaling between large 377 telecom switching systems, concentrating signaling for many lines 378 onto a common signaling channel. The Gateway design allows a single 379 Gateway to support interconnection scaling up to large numbers of 380 remote access server devices, as needed to support Internet access 381 for that particular provider. 383 3.4.2 Redundancy 385 Due to the mission critical nature of the gateway, it must support 386 some form of redundancy in all configurations. 388 There are 2 options for initially for providing redundancy. In both cases, 389 established calls are unaffected by gateway failure. 391 Highly Available - This option will require one gateway with a hot 392 standby gateway, multiple interfaces, and the appropriate software 393 to control the switchover in time of failure. Calls in the process 394 of being setup may be lost during service interruptions but these 395 will be minimal. 397 Fault tolerant - This option will require a much higher level of 398 sophistication. This option can be a single or multiple gateway 399 configuration with the appropriate software however calls in the 400 process of setup will not be lost during gateway switchover and the 401 availability is much higher than option 1. 403 Future use of distributed gateways is for further study. 405 3.4.3 Flexible Deployment 407 Since the Gateway and RAS are connected via Internet protocols, 408 there is a great deal of flexibility for locating and matching 409 Gateway and RAS. For example, the Gateway and RAS could be co- 410 located close to the telecom switch, acting as a single logical peer 411 switch. 413 ............................ ...... 414 . . . 415 . +------+ . . 416 . SS7 | / | . . 417 . Network | STP | . . 418 . __| / |____________ 419 . / +------+ . . \ 420 .........../.../............ . \ 421 / / . +---------+ 422 __________ / / A-link . | Gateway | 423 / / . +---------+ 424 / / . | \ 425 +------+ +------+ . | +-----+ 426 | PSTN | | PSTN |-----TDM---------------- +-----+| RAS | 427 | SCP | |Switch|-------------------------| RAS |+-----+ 428 +------+ +------+ Circuits . +-----+ 430 Figure 4: Gateway/RAS as Peer Switch 432 Alternatively, the Gateway could provide a central interface point 433 for many RAS devices scattered in multiple locations, acting more 434 like a gateway Signal Transfer Point (STP) in SS7. 436 ............................ ...... 437 . . . 438 . +------+ . . 439 . SS7 | / | . . +---------+ 440 . Network | STP |--------------| Gateway | 441 . __| / | . . +---------+ 442 . / +------+ . . | 443 .........../.../............ . | Signaling 444 / / . ISP | Internet 445 / / A-link . _____|_______|___ 446 / / . | | 447 / / . |ASP |ASP 448 / +------+ . | | 449 / | PSTN | TDM . +-----+ | 450 / |Switch|---------------------| RAS | | 451 / +------+ Circuits . +-----+ | 452 +------+ . | 453 | PSTN | TDM . +-----+ 454 |Switch|--------------------------------------| RAS | 455 +------+ Circuits . +-----+ 457 Figure 5: Gateway Serving Multiple Switches/RAS 459 Acronyms 461 ANM - Answer Message REL - Release Message 462 ASP - Access Signaling Protocol RLC - Release Complete 463 CIC - Circuit Identification Code SCP - Service Control Point 464 IAM - Initial Address Message SS7 - Signaling System 7 465 ISP - Internet Service Provider STP - Signal Transfer Point 466 PSTN - Public Switched Telecom Network TDM - Time Division Mult. 467 RAS - Remote Access Server 469 Contact Addresses 471 Robert Dalias Jiri Matousek Lyndon Ong 472 Bay Networks, Inc. Bay Networks, Inc. Bay Networks, Inc. 473 5 Federal Street 5 Federal Street 4401 Gt America Pkwy 474 Billerica, MA 01821 Billerica, MA 01821 Santa Clara, CA 95052 476 rdalias@baynetworks jiri@baynetworks.com long@baynetworks.com 477 .com 479 Full Copyright Statement 481 Copyright (C) The Internet Society (1998). All Rights Reserved. 483 This document and translations of it may be copied and furnished to 484 others, and derivative works that comment on or otherwise explain it 485 or assist in its implementation may be prepared, copied, published 486 and distributed, in whole or in part, without restriction of any 487 kind, provided that the above copyright notice and this paragraph are 488 included on all such copies and derivative works. However, this 489 document itself may not be modified in any way, such as by removing 490 the copyright notice or references to the Internet Society or other 491 Internet organizations, except as needed for the purpose of 492 developing Internet standards in which case the procedures for 493 copyrights defined in the Internet Standards process must be 494 followed, or as required to translate it into languages other than 495 English. 497 The limited permissions granted above are perpetual and will not be 498 revoked by the Internet Society or its successors or assigns. 500 This document and the information contained herein is provided on an 501 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 502 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 503 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 504 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 505 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.