Signaling System No.7 Protocol Architecture And Sevices part 58

Chia sẻ: Dasdsadqwe Dsadasdsadsa | Ngày: | Loại File: PDF | Số trang:11

Thêm vào BST

Báo xấu

58
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

ISDN User Adaptation (IUA) In addition to addressing SS7 over IP, the SigTran group also addressed the backhaul of ISDN over an IP network. RFC 3057 [142] defined the IUA, which is supplemented

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Signaling System No.7 Protocol Architecture And Sevices part 58

ISDN User Adaptation (IUA) In addition to addressing SS7 over IP, the SigTran group also addressed the backhaul of ISDN over an IP network. RFC 3057 [142] defined the IUA, which is supplemented by an Implementer's Guide [143] that seamlessly supports the Q.921 user (Q.931 and QSIG). It also supports both ISDN Primary Rate Access (PRA) and Basic Rate Access (BRA) as well as Facility Associated Signaling (FAS), Non-Facility Associated Signaling (NFAS), and NFAS with backup D channel. Further, extensions to IUA are defined for DPNSS/DASS2 [144], V5.2 [145], and GR 303 [146] that will most likely become RFCs in the future. Figure 14-25 < Day Day Up > < Day Day Up >
Early Cisco SS7/IP Solution Cisco was working on a SLT device before the SS7/IP IETF standardization efforts began. The Cisco SLT is a modular access router (Cisco 2611 or 2651) that terminates SS7 signaling links and backhauls MTP Level 3 and above to a PGW 2200 (formerly SC 2200 and VSC 3000) MGC. Figure 14-26 shows an example configuration of two Cisco SLTs providing SS7 termination and backhaul for the Cisco PGW 2200 Softswitch. Figure 14-26. Cisco SLT Example [View full size image] NOTE For additional information about Cisco Softswitch products, including the PGW2200 and BTS10200, visit the following Web site: http://www.cisco.com/en/US/products/sw/voicesw/index.html. The SLT supports either SS7 A-link or F-link configurations. As noted previously, some SS7 links are deployed with bearer channels that are provisioned on the time slots that are not used by signaling channels. The SLT supports a drop-and-insert feature, which allows the signaling channels to be groomed from the facility. The bearer channels are hair pinnned on the interface card that is to be sent to a MG. Figure 14-27 shows an example of the drop-and-insert feature. Figure 14-27. Example of SLT Drop-and-Insert Feature [View full size image] Each 2611 SLT can terminate up to two SS7 links, and the 2651 SLT can terminate
up to four links. Both have support for ANSI, ITU, TTC, and NTT variants. Several physical layer interfaces are supported on the SLT, including V.35, T1, and E1. The SLT function can also be integrated into the MG, as is done on some of the Cisco universal gateways. The following Web site contains more information about the Cisco SLT: http://www.cisco.com/en/US/products/hw/vcallcon/ps2152/products_data_sheet09 186a0080091b58.html To deliver the backhauled messages to the PGW2200 reliably, the SLT makes use of Reliable UDP (RUDP) and Session Manager (SM) protocols. A generic backhaul protocol layer is used to provide adaptation between MTP Level 2 and MTP Level 3. Figure 14-28 shows the protocol stacks used by the SLT and PGW2200. Figure 14-28. Cisco SLT Protocol Stack RUDP is a simple packet-based transport protocol that is based on Reliable Data Protocol (RFC 1151 [148] and RFC 908 [149]). RUDP has the following features: • Connection-oriented • Guarantees packet delivery with retransmission • Maintains session connectivity using keepalive messages • Provides notification of session failure The SLT maintains up to two RUDP sessions to each PGW2200 host. The use of two sessions provides for additional reliability because they provide for two different network paths between the SLT and the PGW2200. The SM layer manages the RUDP sessions under control of the PGW2200. A single RUDP session is used to pass messages between the SLT and PGW2200 based on RUDP session availability and the PGW2200 hosts' Active/Standby state. The Active PGW2200 selects one or two possible RUDP sessions and indicates its selection to the SLT via the SM protocol.
The generic backhaul protocol layer is very similar to M2UA; it provides the same basic functionality for backhauling MTP Level 3 and above over IP to the PGW2200. < Day Day Up > < Day Day Up >
SS7 and SIP/H.323 Interworking The ITU-T originally developed the H.323 [125] for multimedia over Local Area Networks (LANs). It is not a single protocol; rather, it is a vertically-integrated suite of protocols that define the components and signaling. Though it was originally used for video-conferencing, H.323 was enhanced to better support VoIP with the Version 2 release. It is currently the most widely-deployed VoIP solution today. One of the main complaints about H.323 is its complexity. With H.323, many messages must be passed to set up even a basic voice call. SIP [124], is considered a simpler, more flexible alternative to H.323. SIP is a signaling protocol that handles the setup, modification and teardown of multimedia sessions. It was developed in the IETF as a signaling protocol for establishing sessions in an IP network. A session can be a simple two-way telephone call or a multimedia conference. SIP is becoming a popular favorite as the future of VoIP. So, how does SigTran play a role in H.323 and SIP? SigTran can provide PSTN connectivity to H.323 and SIP networks. A PSTN Gateway application can be used to fulfill this need. The PSTN Gateway sits on the edge of the circuit-switched and packet-switched networks and provides SIP or H.323 interworking to SS7 in the PSTN. Figure 14-29 shows an example of an SIP PSTN Gateway application. In this example, the MGC connects to the SGs using SigTran. Figure 14-29. SIP-PSTN Gateway Application [View full size image] Figure 14-30 shows a similar example of an H.323 PSTN Gateway application. Figure 14-30. H.323-PSTN Gateway Application [View full size image]
Another interesting application is the PSTN transit application, in which calls originate and terminate on TDM interfaces and then transit a voice packet network (such as SIP or H.323). Service providers can use this application to offload their tandem and transit Class 4 and Class 3 switches. This application creates the need for an ISUP transparency. SIP-T [150] (SIP for Telephones) provides a framework for the integration of the PSTN with SIP. Figure 14-31 shows an example of using SIP-T for a PSTN transit application. Figure 14-31. SIP Transit Application [View full size image] SIP-T meets the SS7 to SIP interworking requirements by providing the following functions: • A standard way of mapping ISUP information into the SIP header for calls that originate in the PSTN. This function ensures that the SIP contains sufficient information to route calls (for example, in the case where routing depends on some ISUP information). • Use of the SIP INFO [151] Method to transfer mid-call ISUP signaling messages. • A means for MIME [152] encapsulation of the ISUP signaling information in the SIP body provides for ISUP transparency. When the MGC receives an ISUP message, the appropriate ISUP parameters are translated to the SIP header fields and the ISUP message is encapsulated in a MIME attachment, which intermediate SIP entities treat as an opaque object. If the SIP message terminates the call, it ignores the ISUP attachment because it has no need for it. However, if the call terminates on the PSTN, the encapsulated ISUP message is examined and used to generate the outgoing ISUP message. The version parameter included in the MIME media type information indicates the encapsulated ISUP message's ISUP variant. If there are different ISUP variants on the origination and termination side, it is up to the terminating MGC to perform ISUP translation between the variants.
ummary This chapter focused on the key SigTran protocols and their role in a next- generation architecture of voice products. The SigTran work grew from a desire to decompose a traditional circuit switch into specialized components. It focused on the following two areas: • A transport protocol that is suitable for meeting the requirements of carrying telecommunication protocols, especially SS7, over a packet network. • The creation of adaptation layers that support the primitives of SCN telephony signaling protocols. SCTP was developed as the new generic transport protocol. It provides performance and reliability benefits for telephony signaling transport over the UDP and TCP transport protocols. The common elements of the adaptation layers were introduced and described in some detail, as were the following key adaptation layers: • M3UA— Provides for the transport of MTP Level 3 user part signaling (for example, ISUP and SCCP). • SUA— Provides for the transport of SCCP user signaling (for example, TCAP). • M2UA— Provides for the transport of MTP Level 2 user signaling (for example, MTP Level 3). • M2PA— Provides a means of creating an IP SS7 link by replicating MTP Level 2 and supporting the MTP Level 2 primitive boundary to MTP Level 3. • IUA— Provides for the transport of Q.921 user signaling (for example, Q.931). In addition, two protocols related to SigTran were introduced: TALI and the early Cisco backhaul protocol stack. Finally, some examples of SS7 to SIP and H.323 interworking were provided to provide a context for how SigTran protocols can be used with other VoIP protocols. < Day Day Up > < Day Day Up >
Chapter 15. SS7 Security and Monitoring Signaling System No. 7 (SS7) is a castle in terms of security, although the castle walls are increasingly coming under attack. The main forces acting on the protocol to wear down its defenses are market liberalization and ever-increasing convergence. When SS7 was designed and initially deployed, comparatively few telephone companies with well-defined network boundaries existed. That environment no longer exists because of market liberalization; there are more telephony providers than could have been imagined when SS7 was first drawn up. The convergence of SS7 with next generation architectures such as IP networks has created the need for additional security enforcement. SS7 has relied on an isolated signaling network for much of its' security and the interconnection with IP networks and interworking with other packet protocols changes this paradigm. The lack of security inherent in the SS7 protocol is likely to be increasingly exposed in line with communications convergence and with the ever-increasing number of operator interconnects. At present, traditional SS7 has no security mechanisms to ensure that a sender is who he says he is, nor is there cryptographic protection against alteration of messages. Securing traditional SS7 currently focuses on screening incoming traffic and monitoring for unusual traffic. This chapter examines each of these security measures. < Day Day Up > < Day Day Up >
Traffic Screening This section provides a practical overview of SS7 traffic screening. Traffic screening is normally applied at Signal Transfer Points (STPs) because these are normally the gateways between operator networks. Network operators are responsible for ensuring the security of their own SS7 networks to defend against any unwarranted incoming traffic. At present, SS7 traffic can be altered, injected, or deleted after physical access to the signaling links is gained. STPs normally have extensive screening functionality. Typically, the screening rules are specified on a per-linkset basis. Usually the STP can support something in the range of a few thousand conditional statements that can be applied to each linkset. Screening usually adds only a couple milliseconds to cross STP transmission time. STP gateway screening is typically applied to provide access-control mechanisms to nonhome SS7 networks (interconnects). Figure 15-1 illustrates this concept. Figure 15-1. STPs May Be Used to Filter Incoming SS7 Messages Before an incoming Message Signal Unit (MSU) is accepted, it should pass a series of filtering rules that ensure conformance to the specified criteria. If an MSU does not pass the test, it should be discarded. This operation is known as message screening. Screening normally is applied only to the incoming internetwork SS7 MSUs. Screening procedures normally are not applied to outgoing or intranetwork MSUs. Internetwork MSUs are of high importance because they constitute the traffic coming in from other operators via interconnects. Screening is normally
applied at the Message Transfer Part (MTP) 3 and Signaling Connection Control Part (SCCP) protocols layers. MTP screening is applied before any Global Title Translation (GTT). Normally there are pre-GTT and post-GTT SCCP screening rules. The following typical MTP basic screening rules can be combined to build more complex screening functionality: • Allow specified Originating Point Code (OPC) • Block specified OPC • Allow specified Destination Point Code (DPC) • Block specified DPC • Permitted Service Information Octet (SIO) values include priority values as per the Service Indicator (SI) subfield, network values as per the Network Indicator (NI) subfield, and the User Part values as per the Subservice field (SSF) • Allow certain MTP3 H0/H1 values (signaling network management messages) The following typical pre-GTT SCCP screening rules can be combined to build more complex screening functionality: • Calling Party Address (CgPA) parameters such as point code allowed, subsystem number allowed, SCCP message type allowed, routing indicator allowed, and translation type allowed The following typical post-GTT SCCP screening rules can be combined to build more complex screening functionality: • Called Party Address (CdPA) parameters such as point code allowed, subsystem number allowed, and SCCP management messages allowed The next sections look at the protocol issues you should keep in mind when planning to implement screening rules. Screening Considerations The following sections discuss areas of concern surrounding the various protocols in a core SS7 stack. In general, signaling related to the control and management of the whole network is somewhat more of a target for fraud than, say, signaling
relating to one call only. MTP The lower levels of MTP (MTP1 and MTP2) are involved in the reliable transfer of SUs on only a link-by-link basis, rather than on an end-to-end basis. Therefore, screening is not provided at these layers, and monitoring systems may take many measurements relating to MTP2 performance instead. MTP screening is provided for MTP3, because it provides the routing of MSUs through the SS7 network and as such, contains information related to the network topology, such as routing tables. The information relating to network topology can change dynamically by the network management functions of MTP3. Therefore, MTP3 network management messages need to be both screened and monitored, because they can access and modify the network's routing information. SCCP As with MTP3, SCCP carries messages arriving from both Level 4 and self- generated SCCP network management messages. SCCP management informs other nodes of application status, such as whether a particular application is working.