Signaling System No.7 Protocol Architecture And Sevices part 58 docx

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... SIP-PSTN Gateway App

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