The IP⁷ Secure Gateway functionality in the EAGLE provides connectivity between SS7 and IP networks, enabling messages to pass between the SS7 network domain and the IP network domain, as follows:

• When an EAGLE receives an SS7 formatted message over an SS7 link, the IP⁷ Secure Gateway functionality dynamically converts this message into IP format and routes the re-formatted message over an associated IP link to a destination residing within an IP network.

  The IP⁷ Secure Gateway functionality use associations to access the IP domain. Associations identify IP sessions.

• Conversely, when the EAGLE receives an IP formatted message over an IP link, the IP⁷ Secure Gateway functionality dynamically converts this message into SS7 format and routes the re-formatted message over an associated SS7 link to a destination residing within the SS7 signaling network.

  Address resolution is not performed in the IP to SS7 direction. It is the responsibility of the sending application to ensure that the appropriate SS7 point code information resides in the IP message to allow a valid SS7 message to be constructed for routing to the SS7 network.

The IP7 Secure Gateway functionality is provided by applications that run on IP cards or E5-ENET cards. IP cards provide interfaces between the IMT bus and two 10/100 Base-T IEEE 802.3/DIX Ethernet interfaces. The IP cards, similar to any other Link Interface Module (LIM), use the Interprocessor Message Transport (IMT) bus to communicate with the other cards in the EAGLE. Like other LIMs, the primary job of an IP card is to send and receive SS7 data on a network (in this case, an IP network), and to route that data to other cards in the EAGLE as appropriate.

The IP card can run on the following applications:

• iplim or iplimi - Both applications support STP connectivity via MTP-over-IP functionality point-to-point connectivity (for more information, see Point-to-Point Connectivity (IPLIM or IPLIMI Application)).

  The iplim and iplimi applications support these types of connections:

  • M2PA/SCTP/IP (A, B, C, D, and E links)
  • SCP
  • SEP
  • SCP/SEP

    This type of connection is essentially the same as that of a traditional SS7 point-to-point link, except that the traditional MTP2 and 56Kb/s technology is replaced by IP and Ethernet technology.

    The iplim application supports point-to-point connectivity for ANSI networks. The iplimi application supports point-to-point connectivity for ITU networks. With the optional ANSI/ITU MTP Gateway feature and proper configuration, the EAGLE could convert between any of the ANSI, ITU-N, and ITU-I networks, switch traffic between these networks, and perform network management for each of these networks (for more information, see Mixed Networks Using the ANSI/ITUMTP Gateway Feature).

    The EAGLE can support up to 100 cards running the iplim and iplimi applications.

• ss7ipgw and ipgwi - These applications support the following types of point-to-multipoint connectivity for networks:
  • SCP connectivity via SCCP/TCAP-over-IP functionality (for more information, see Connecting to SCPs with SCCP/TCAP Messages Sent Over the IP Network)
  • SEP connectivity via ISUP, Q.BICC, and TUP-over-IP functionality (for more information, see Connecting SEPs Using ISUP, Q.BICC, and TUP Messages Over the IP Network)
  • SCP/SEP connectivity via non-ISUP, non-SCCP, non-Q.BICC, and non-TUP-over-IP functionality (for more information, see Connecting SCPs and SEPs Using Non-ISUP, Non-SCCP, Non-Q.BICC, and Non-TUP Messages Over the IP Network)

    The ss7ipgw application supports point-to-multipoint connectivity for ANSI networks. The ipgwi application supports point-to-multipoint connectivity for ITU networks.

    The EAGLE can support a maximum of 125 cards running the ss7ipgw and ipgwi applications.

In addition to running an iplim, iplimi, ss7ipgw, or ipgwi application, each IP card supports the following functions:

• A Simple Network Management Protocol (SNMP) agent. For more information, see SNMP Agent Implementation.
• Message Transfer Part (MTP) status. This function is available only on IP cards that support the ss7ipgw or ipgwi application. For more information, see Support for MTP Status Functions.

IP connections involve the following assignments:

• Transport protocol – The SCTP transport protocol is specified by the ent-assoc and chg-assoc commands.
• Adapter protocol – The M3UA, M2PA, or SUA adapter protocol is specified by the adapter parameter of the ent-assoc and chg-assoc commands.
• One or two near-end (local) hosts – The local host is specified by the lhost parameter of the ent-assoc and chg-assoc commands. A second local host can be specified for an association using the alhost parameter of the ent-assoc and chg-assoc commands, allowing the near-end host of the association to be multi-homed. Specifying only one local host for an association allows the association to be uni-homed.
• Far-end (remote) host – The remote host is specified by the rhost parameter of the ent-assoc and chg-assoc commands.
• Near-end (local) transport protocol port – The local transport protocol port is specified by the lport parameter of the ent-assoc and chg-assoc commands.
• Far-end (remote) transport protocol port – The remote transport protocol port is specified by the rport parameter of the ent-assoc and chg-assoc commands.
• SS7 signaling link – specified by the loc and link parameters of the ent-slk command.

The local host is mapped to a particular Ethernet interface on the IP card by linking the local host name of the IP connection to an IP address with the ent-ip-host command. The IP address is also assigned to an IP card and to an Ethernet interface on that IP card using the chg-ip-lnk command. A signaling link on that card is assigned to the IP connection using the link parameter of the ent-assoc and chg-assoc commands and referencing the signaling link on the IP card.

An SCTP association can establish a connection between one local host and one remote host (a uni-homed association) or between multiple local hosts and a remote host (a multi-homed association). It is possible that the remote host may be multi-homed, but the EAGLE allows only one remote host to be specified for a multi-homed association. If an IP node has multiple IP address associated with it, then an SCTP association originating from this node may take advantage of this added connectivity by establishing an SCTP multi-homed association.

For more information on multi-homed associations, see the Multi-Homed SCTP Associations section and the Routing section.

Figure 2-1 shows the components of an SCTP association and how these components interact with each other.

There is no direct correlation between signaling link ports and Ethernet interfaces. A card can be using Ethernet interface A and signaling link B to transmit data to the remote host. Another scenario could have the card using Ethernet interface B and signaling link A to transmit data to the remote host.

The numbers of signaling link ports and Ethernet interfaces on IP cards varies depending on the card type and application running on the card, as shown in Table 2-1. The sections that follow Table 2-1 describe the IP connections supported by each IP card type. The IP connections described in these sections are uni-homed SCTP associations.

IP Connection on an E5-ENET Card Running the IPGWx Application

The assignment of the transport protocol port number is made through the local host port (lport) and remote host port (rport) parameters of the ent-assoc or chg-assoc commands (for an SCTP association).

Figure 2-3 shows typical IP connection data for a uni-homed SCTP association and how these components interact with each other.

The IP connection defined by the SCTP association is from local host ipnode-1204 (190.50.1.139), SCTP port 2048, to remote host remote-node-2 (190.50.1.144), SCTP port 3529, using Ethernet interface B on IP card 1204, and signaling link A on IP card 1204.

IP Connection on an E5-ENET Card Running the IPLIMx Application

E5-ENET cards running the IPLIMx applications can have 16 signaling links (A, B, A1, B1, A2, B2, A3, B3, A4, B4, A5, B5, A6, B6, A7 or B7) and 2 Ethernet interfaces (A or B) resulting in a maximum of 16 IP connections, one for each signaling link. Each link can use either Ethernet interface A or B. The local host and alternate host assigned to a signaling link must use different Ethernet interfaces; they cannot be assigned to the same Ethernet interface. Figure 2-4 shows some ways the 16 signaling links and the 2 Ethernet interfaces can be used to establish IP connections.

Multi-Homed SCTP Associations

If the IP cards are EDCMs or E5-ENET cards, SCTP associations can have two local hosts, and are referred to as multi-homed associations. A multi-homed association uses both Ethernet interfaces on the IP card. Each Ethernet interface is assigned to a local host. Each local host is assigned to a different local network. One of the local hosts is configured with the lhost parameter of the ent-assoc or chg-assoc commands. The second local host, or alternate local host, is configured with the alhost parameter of the ent-assoc or chg-assoc commands. One of the local hosts references one of the Ethernet interfaces on the IP card and the other local host references the other Ethernet interface on the IP card. The multi-homed SCTP association allows the E5-ENET card to communicate with another node over two networks. Traffic is passed to and from the remote node on either local interface on the card.

An SCTP association can be uni-homed also. A uni-homed association uses only one Ethernet interface (A or B), which is assigned to only one local host. This local host is configured with the lhost parameter of the ent-assoc or chg-assoc commands. For a uni-homed association, the alhost parameter is not be specified with the ent-assoc or chg-assoc commands. A uni-homed association allows the IP card to communicate to another node on one network only. Traffic is passed to and from the remote node on the local interface on the card defined by the lhost parameter.

The remote node can be either uni-homed or multi-homed, and is not dependent on whether or not the local node (containing the local hosts) is uni-homed or multi-homed. For example, Node A can be uni-homed and can be connected to a multi-homed Node B, or a multi-homed Node A can be connected to a uni-homed Node B. Table 2-2 illustrates the possible combinations.

Multi-Homed Associations on EDCMs or E5-ENET Cards Running the IPLIMx Application

A multi-homed association on an IPLIMx card uses both Ethernet interfaces to reach the remote host, but only one signaling link. An association, either uni-homed or multi-homed, can be assigned to only one signaling link. That signaling link can be either signaling link A or B. The local and alternate local hosts are assigned to each Ethernet interface on the IP card. The IPLIMx cards are limited to one IP connection per signaling link. Since the IPLIMx cards can have eight signaling links on the card, eight multi-homed associations can be assigned to an IPLIMx card.

Figure 2-5 shows the ways a multi-homed IP connection can be established on an IPLIMx card. The remote hosts can be multi-homed, but only one remote host can be specified for each multi-homed association in the EAGLE, so only one remote host is shown in Figure 2-5.

Multi-Homed Associations on E5-ENET Cards Running the IPGWx Applications

A multi-homed association on an IPGWx card uses both Ethernet interfaces to reach the remote host, but only one signaling link, signaling link A on the IPGWx card. The local and alternate local hosts are assigned to each Ethernet interface on the IP card. The IPGWx cards can have up to 50 connections for each IPGWx card. The IPGWx card can contain both uni-homed and multi-homed IP connections, as long as the total number of connections does not exceed 50.

Figure 2-6 shows the way a multi-homed IP connection can be established on an IPGWx card. The remote hosts can be multi-homed, but only one remote host can be specified for each multi-homed association in the EAGLE, so only one remote host is shown in Figure 2-6.

Figure 2-7 shows the components of the multi-homed SCTP association and how these components interact with each other.

Using the data shown in Figure 2-7, the IP connection is defined as a multi-homed association, connecting to a remote host using local hosts 190.1.5.56 and 189.20.30.137 over SCTP port 3425, using signaling link B on card 1201.

Routing

The IP7 Secure Gateway functionality in the EAGLE support two transport protocols –TCP and SCTP. Although both transport protocols are connection oriented, they differ greatly with respect to operation in a multi-homed host environment. The TCP protocol provides for a point-to-point transport connection. The SCTP protocol implements connections with either point to point, point to multi-point, or multi-point to multi-point connectivity capabilities.

An SCTP IETF connection ( association) is defined as a four-tuple as follows:

• local host list – one or more of the local host’s IP interface addresses
• local SCTP port
• remote host list – one or more of the remote host’s IP interface addresses
• remote SCTP port

Based on this definition for an SCTP IETF connection, and the fact that the IPGWx and IPLIMx applications may utilize both Ethernet interfaces (a multi-homed host), an SCTP IETF association can take advantage of multi-homing and be a multi-homed SCTP endpoint. As a multi-homed endpoint, an SCTP IETF connection remains active and usable as long as at least one of the Ethernet interfaces can be reached by the remote host. Multiple paths through multiple interfaces to the remote host provides a more reliable connection. The SCTP IETF protocol is designed to make such a network outage transparent to the application.

In previous releases, an SCTP IETF endpoint could only operate as a uni-homed host using only the Ethernet A interface. In this mode, any SCTP transmission received on or transmitted out of the Ethernet B interface are silently discarded. By using the Ethernet B interface, the SCTP protocol running on the IP card can provide SCTP multi-homing endpoint support – that is, when an SCTP IETF association is formed, it may list both the Ethernet A and B IP addresses for the respective interfaces. As a multi-homed association endpoint, SCTP data would be allowed to flow on either of the Ethernet interfaces and thus provide more robust network connectivity.

In order to provide more flexible network connectivity, an association can be configured as follows with respect to the Ethernet interfaces:

• Ethernet A interface only (uni-homed)
• Ethernet B interface only (uni-homed)
• Ethernet A and B interface (multi-homed)

The interface mode is specified by the lhost and alhost parameters of the ent-assoc or chg-assoc commands.

In previous releases, the lhost parameter of the ent-assoc or chg-assoc commands is used to define the local IP address of the SCTP IETF association endpoint. The IP address would have to be an IP address associated with an Ethernet A interface. With this release, the IP address may be associated with either the Ethernet A or B interfaces. If it is an Ethernet A interface IP address, and the alhost parameter is not specified, then the association operates as a uni-homed SCTP endpoint on Ethernet interface A. If it is an Ethernet B interface IP address, and the alhost parameter is not specified, then the association operates as a uni-homed SCTP endpoint on Ethernet interface B. An association is configured as an SCTP multi-homed endpoint by specifying both the lhost and alhost parameter values with values corresponding to the Ethernet interface IP address for the IP card. The lhost and alhost parameter values represent the IP addresses specified by the chg-ip-lnk command for the specific IP card. Traffic cannot be passed between the Ethernet interfaces on the IP card containing a multi-homed SCTP association. The IP card cannot act as an IP router between the networks defined by the local host and alternate local hosts of a multi-homed association.

A host that is not on the local network, the network identified by the local host’s IP address, can be reached only through a gateway router. A gateway router is a device with more than one physical network connection, and can be connected to multiple networks. Unlike a multi-homed host, a gateway router is permitted to route IP messages between the physical Ethernet interfaces on the IP card. The network portion of the gateway router’s IP address must be the same as the network portion of the IP address of one of the IP addresses of the Ethernet interfaces on the IP card. The gateway router is configured using the defrouter of the chg-ip-card command, or using the ent-ip-rte command.

Static entries are added to the IP Routing table using the ent-ip-rte command. Static routes are usually assigned to give control over which routers are used, allowing different routers to be selected based upon the destination IP address. There are two types of static routes:

• host static IP routes
• network or subnetwork static IP routes

The default route entry is a special static route. If there is not a specific host or network address in the IP Routing table that matches the destination IP address of an outbound datagram, then the datagram is sent to the default router (gateway) specified by the default route.

An IP route is configured using the ent-ip-rte command with the location of the IP card, the IP address of the gateway router (the gtwy parameter), and the IP address and subnet mask of the destination (that is, host or network). The IP address of the gateway router must be a locally attached IP address (that is, the gateway IP address must share the network portion of one of the two Ethernet interfaces).

When an IP packet is to be transmitted the IP routing table must be interrogated to determine where to send the IP datagram. If the destination IP address is local to the node (that is, directly reachable by an Ethernet interface), then the IP datagram is transmitted directly to the node with that associated IP address. If the destination IP address is determined to not be local to the node, then it must be routed (that is, sent to a gateway to reach its destination).

IP routing requires accessing the IP routing table to select a route. The destination IP address of the outbound datagram is used to search the IP routing table for the most specific route match. The order for selection is:

1. Host route
2. Subnetwork route
3. Network route
4. Aggregated route
5. Default route

Based on this selection order if an IP route is found then the outbound IP datagram will be transmitted to the gateway specified by the route. If no IP route is found (where no default route is specified), then the transmission of the datagram fails due to destination unreachable.

The capability to enter static IP routes provides for flexibility and control with respect to controlling network traffic. An IP card can contain up to 64 IP routes. The EAGLE can contain up to 1024 IP routes.

The following sections describe the types of point-to-point connectivity provided, and how routing is accomplished, by the iplim or iplimi application:

Connecting STPs Over the IP Network

This functionality allows the use of an IP network in place of point-to-point SS7 links to carry SS7MSUs. Figure 2-8 shows a diagram of this type of network. For example, the C links between the mated pair of STPs or A/B/D links between STPs can be replaced by an IP network. The IP⁷ Secure Gateway functionality is deployed on both ends of the link (point-to-point connection). The EAGLE converts the SS7MSUs to IP packets on one end of the link, and IP packets to SS7MSUs on the other end of the link. The IPLIMx applications support M2PA/SCTP/IP associations over A, B, C, D, and E links.

The following sections describe the types of point-to-multipoint connectivity, how routing is accomplished, and the MTP status functions provided by the ss7ipgw and ipgwi applications:

• Connecting to SCPs with SCCP/TCAP Messages Sent Over the IP Network
• Connecting SEPs Using ISUP, Q.BICC, and TUP Messages Over the IP Network
• Connecting SCPs and SEPs Using Non-ISUP, Non-SCCP, Non-Q.BICC, and Non-TUP Messages Over the IP Network
• Understanding Routing for SS7IPGW and IPGWI Applications
• Support for MTP Status Functions

Connecting to SCPs with SCCP/TCAP Messages Sent Over the IP Network

This functionality allows SS7 nodes to exchange SCCP/TCAP queries and responses with an SCP residing on an IP network. Figure 2-9 shows a diagram of this type of network.

The EAGLE manages the virtual point codes and subsystem numbers for the IP-SCP. From the SS7 network perspective, the TCAP queries are routed using these virtual point codes/SSNs. The EAGLE maps the virtual point code/SSN to one or more TCP sessions (point-to-multipoint connection), converts the SS7MSUs to IP packets by embedding the SCCP/TCAP data inside IP packets, and routes them over an IP network. The EAGLE also manages application subsystem status from an IP network's perspective and an SS7 network's perspective.

The following sequence of events illustrates this functionality:

1. Traditional SS7 devices route MSUs (such as TCAP Queries) to the EAGLE.
2. The EAGLE performs a global title translation and forwards the translated MSU to the correct IP device based on Point Code and SCCP Subsystem information in the MSU.
3. The TCAP query is processed at the IP-SCP, and the IP-SCP sends a TCAP reply back to the EAGLE.
4. The EAGLE forwards the TCAP reply back to the sender of the original query.

Connecting SEPs Using ISUP, Q.BICC, and TUP Messages Over the IP Network

This point-to-multipoint functionality allows SS7 nodes to exchange ISUP, Q.BICC, and TUP protocol messages with one or more signaling end points (class 4 switches, class 5 switches, VoIP gateways, Media Gateway Controllers, or Remote Access Servers) residing on an IP network. Figure 2-10 shows an example of this type of network.

The EAGLE maps the originating point code, destination point code, and circuit identification code to an IP connection. The SEP is provided the originating and destination point codes in the MTP level 3 routing label as part of the passed protocol.

Connecting SCPs and SEPs Using Non-ISUP, Non-SCCP, Non-Q.BICC, and Non-TUP Messages Over the IP Network

This point-to-multipoint functionality allows SS7 nodes to exchange non-ISUP, non-SCCP, non-Q.BICC, and non-TUP protocol messages with one or more IP-based devices residing on an IP network. The network example is similar to the SCP connectivity via SCCP/TCAP-over-IP functionality example shown in Figure 2-9. The EAGLE maps the destination point code, and service indicator (non-ISUP, non-SCCP, non-Q.BICC, non-TUP) to an IP connection.

Understanding Routing for SS7IPGW and IPGWI Applications

The ss7ipgw and ipgwi applications can use a single point code, called a virtual point code. This code is assigned to a set of IP devices that it connects to. The EAGLE distinguishes between the devices within the set by using application routing keys and application servers.

Application routing associates SS7 routing keys with application servers. SS7 routing keys define a filter based on SS7 message data. Application servers define the connection between the IP local host/local transport protocol port and IP remote host/remote transport protocol port.

An application server is a logical entity serving a specific routing key. The application server contains a set of one or more unique application server processes, of which one or more is normally actively processing traffic. An application server process is a process instance of an application server and contains an SCTP association. For more information on application servers, application server processes, and SCTP associations, see the IETF Adapter Layer Support section.

If the routing key filter matches the SS7 message presented for routing to the IP network, the SS7 message is sent to the associated application server.

Only one application server can be associated with each SS7 routing key. One application server can have up to 16 associations. SS7 messages delivered to the IP network using a routing key are distributed over the available application server based on the SLS (signaling link selector) value in the SS7 message.

Routing keys can be fully or partially specified, or specified by default.

Full Routing Keys

For this routing application, all applicable fields in the Message Signaling Unit (MSU) must match the contents of the full routing key. Table 2-3 defines which SS7 message parameters are used to search for a match for full routing keys for each of the functions supported by the ss7ipgw and ipgwi applications (IPGWx functionality).

Partial Routing Keys

Partially specified routing keys are explicitly, but not completely defined. These routing keys ignore some of the contents of the MSU. The parts of the MSU that are ignored are specific. For example, for the ‘ignore cic’ partial-key type, the destination point code (dpc), service indicator (si), and originating point code (opc) must be configured, but the circuit identification code (cic) field does not have to be configured. The other types of SS7 partial routing keys are as follows:

• dpc, si, and opc specified (ignore cic for CIC-based messages)
• dpc and si specified (ignore ssn for sccp messages)
• dpc and si specified (ignore opc and cic for CIC-based messages)
• dpc specified (ignore all but the dpc field)
• si specified (ignore all but the si field)

Default Routing Keys

Default routing keys do not need any part of the MSU specified. This routing key can be used to carry any SS7MSU, regardless of the type of MSU or the fields that make up the MSU.

Routing Key Tables

Each IP card has a Routing Key table that maps SS7 routing keys to IP connections, as illustrated by the example in Table 2-4. MSUs that match the parameters in a given row are sent over one of the IP connections shown for that row (up to 16 IP connections can be defined for a single routing key). Multiple IP connections for a given row allow load sharing. In addition, multiple routing keys can be used to send traffic to a single IP connection.

Each IP card’s Routing Key table can contain up to 2500 entries. Entries in the Routing Key table are defined by the ent-appl-rtkey command entered through the OAM, saved on disk, and reloaded to each IP card upon reset. The routing key entries can be full, partial, or default routing keys. The entries in one IP card’s Routing Key table are identical to the entries in the other IP card’s table. The entries can be changed by the chg-appl-rtkey command or removed by the dlt-appl-rtkey command.

Table 2-4 shows a sample Routing Key table that has one entry for an SSCP/TCAP-over-IP connection; one entry each for an ISUP, Q.BICC, and TUP-over-IP connection; and a non-SCCP/non-ISUP/ non-Q.BICC/non-TUP connection.

Routing Key Lookup Hierarchy

To facilitate the delivery of Message Signaling Units (MSUs) that do not match full routing key entries in the Routing Key table, each MSU is processed and delivered according to a specific routing key lookup hierarchy. The hierarchy guarantees that the MSU is delivered to the best possible location based on the MSU’s closest match in the Routing Key table, and also prevents MSUs without full routing key matches from being discarded. Table 2-5 defines the routing key lookup hierarchy.

When an MSU has an si value of 5, 13, or 4 (ITU only), it is a CIC message. Messages with an si value of 3 are SCCP messages. All other MSUs are considered OtherSI messages. The EAGLE first tries to match each MSU with a full routing key and second with one of the partial keys as numbered in ascending order in the table. Third, if no segment of the routing key matches either full or partial routing keys, the EAGLE assigns the MSU a default routing key.

Support for MTP Status Functions

This feature, available only on IP cards that support the ss7ipgw and ipgwi applications, allows the Message Transfer Part (MTP) status of point codes in the SS7 networks to be made available to IP-connected media gateway controllers (MGCs) and IP-SCPs. This feature is similar to the MTP3 network management procedures used in an SS7 network.

This feature enables an IP device to:

• Divert traffic from a secure gateway that is not able to access a point code that the mated secure gateway can access
• Audit point code status
• Build up routing tables before sending traffic
• Be warned about network congestion
• Abate congestion (ss7ipgw application only)
• Obtain SS7 User Part Unavailability status

This feature implements a Simple Network Management Protocol (SNMP) agent on each IP card that runs the ss7ipgw, ipgwi, iplim, or iplimi applications. SNMP is an industry-wide standard protocol used for network management. SNMP agents interact with network management applications called Network Management Systems (NMSs).

Supported Managed Object Groups

The SNMP agent maintains data variables that represent aspects of the IP card. These variables are called managed objects and are stored in a management information base (MIB). The SNMP protocol arranges managed objects into groups. Table 2-6 shows the groups that are supported.

Supported SNMP Messages

The SNMP agent interacts with up to two NMSs by:

• Responding to Get and GetNext commands sent from an NMS for monitoring the IP card.
• Responding to Set commands sent from an NMS for maintaining the IP card and changing managed objects as specified.
• Sending Trap messages to asynchronously notify an NMS of conditions such as a link going up or down. Traps provide a way to alert the NMS in a more timely fashion than waiting for a Get or GetNext from the NMS. Two hostnames, DCMSNMPTRAPHOST1 and DCMSNMPTRAPHOST2, are utilized to specify the SNMPNMS to which traps are sent. In this release, only the following traps are supported:
  • coldStart, sent one time only when the IP stack initialization occurs on the IP card as part of boot processing
  • linkUp, sent when one of the ports on the IP card initially comes up or recovers from a previous failure
  • linkDown, sent when one of the ports on the IP card fails

When a trap occurs at the IP card agent, the agent sends the trap to each of the SNMP specific host names that can be resolved to an IP address. Resolution is based on configuration data in the chg-ip-card command (or default data) which specifies DNS search order and DNS information.

Deviations from SNMP Protocol

Table 2-7 shows how the EAGLE deviates from the standard SNMP protocol definition.

The optional ANSI/ITUMTP Gateway feature, now also available for IP networks, and the addition of the iplimi and ipgwi applications enables the EAGLE to act as an interface between nodes that support ANSI, ITU-I, and ITU-N protocols. For more information on the ANSI/ITUMTP Gateway feature, contact your Oracle Sales Representative.

Figure 2-11 shows an example of a complex network that includes all these types of nodes. Table 2-8 provides more detail about the nodes, network types, and point codes used in this example.

The following SS7 protocol constraints determine how the network must be configured:

• A linkset is a group of links that terminate into the same adjacent point code. All links in the linkset can transport compatible MSU formats. The network type of the linkset is the same as the network type of the adjacent point code assigned to the linkset.
• When nodes in different networks need to communicate, each node must have either a true point code or an alias point code for each of the network types. For example, if Node 1 (in an ANSI network) needs to communicate to Node 7 (in an ITU-N network), Node 1 must have an ANSI true point code and an ITU-N alias point code, while Node 7 must have an ITU-N true point code and an ANSI alias point code.
• The systems are usually deployed as mated pairs. The links connecting the EAGLE to its mate are C links. Each EAGLE must have a C linkset for each network type that the EAGLE connects to. Therefore, in Figure 2-11, Nodes 5 and 6 are connected with three linksets, one each for ANSI traffic, ITU-I traffic, and ITU-N traffic.
• To perform routing, the EAGLE must convert the routing labels in MSUs. To perform this conversion, every destination point code (DPC), originating point code (OPC), and concerned point code must be defined in the Routing table. Even if the EAGLE does not route MSUs to these nodes, they must be provisioned in the Routing table to provision the alias point codes required in the conversion process.

  Figure 2-11 Complex Network with ANSI, ITU-I, and ITU-N Nodes

  

  Table 2-8 Nodes and Point Codes in Complex Network Example

  Node	Node Type	Network Types Supported	True Point Codes1	Alias Point Codes2
  1	SSP	ANSI	A1	N1, I1
  2	SSP	ANSI	A2	I2
  3	SSP	ANSI	A3	N3, I3
  4	SSP	ANSI	A4	N4
  5	STP (with IP7 Secure Gateway functionality)	ANSI, ITU-N, ITU-I	A5, N5, I5
  6	STP (with IP7 Secure Gateway functionality)	ANSI, ITU-N, ITU-I	A6, N6, I6
  7	STP (with IP7 Secure Gateway functionality)	ITU-N, ITU-I	N7, I7	A7
  8	STP (with IP7 Secure Gateway functionality)	ITU-N, ITU-I	N8, I8	A8
  9	STP (with IP7 Secure Gateway functionality)	ITU-N, ITU-I	N9, I9	A9
  10	STP (with IP7 Secure Gateway functionality)	ITU-N, ITU-I	N10, I10	A10
  11	SSP	ITU-N	N11	I11, A11
  12	SSP	ITU-I	I12	N12, A12
  13	SSP	ITU-I	I13	N13, A13
  14	SSP	ITU-N	N14	I14, A14
  15	SSP	ITU-I	I15	N15, A15
  16	SSP	ITU-I	I16	N16, A16
  Notes: 1. A true point code (TPC) defines a destination in the EAGLE’s destination point code table.A TPC is a unique identifier of a node in a network. An STP (with IP7 Secure Gateway functionality) must have a TPC for each network type that the EAGLE connects to. An SSP connects to only one type of network, so it has only one TPC. 2. An alias point code is used to allow nodes in other networks to send traffic to and from a EAGLE when that EAGLE does not have a TPC for the same network type.

The configured links and point codes in the complex network shown in Figure 2-11 allows most nodes to communicate with other nodes. However, note that Node 2 cannot communicate with Node 13 or Node 16, or with any node in the ITU-N network because Node 2 does not have an ITU-N alias point code.

Routing and Conversion Within a Single Network Type

The following steps demonstrate how an EAGLE routes and converts when an ITU-N node sends an MSU to another ITU-N node. For example, assume that Node 11 in Figure 2-11 sends an MSU to Node 14. The MSU is routed from Node 11 to Node 7 to Node 5 to Node 9 to Node 14. The following steps describe the actions performed at Node 5 (an STP with IP⁷ Secure Gateway functionality):

1. An ITU-N formatted MSU (which has a network identifier=01b and a 14-bit destination point code/originating point code) is received on an iplimi card (for this example at location 1103).
2. MSU discrimination is performed with the following substeps:
   1. Compare the received network identifier (NI) to the list of valid NIs. (Each configured linkset for a receiving link has a defined list of valid NIs.) If the comparison fails, the MSU is discarded and an STP measurement is logged. In this example, the received NI (01b) is valid for an iplimi card.
   2. Extract the NI and destination point code (DPC) from the received MSU.
   3. Determine whether the destination of the received MSU is this STP. If not (as is the case in this example), the MSU is passed to the STP’s routing function.
3. The routing function selects which outgoing link to use by searching a routing table for an entry for the DPC (N14 in this example). The routing table identifies another iplimi card (for this example at location 1107) to be used for the outgoing link.
4. Determine whether MSU conversion is required (required when the source network type is not the same as the destination network type). In this example, both Node 11 and Node 14 are ITU-N nodes, so conversion is not required.
5. Forward the MSU across the Interprocessor Message Transport (IMT) bus from location 1103 to location 1107, where the MSU is transmitted out the link towards Node 14.

Routing and Conversion Between Different Network Types

The routing and conversion steps performed by a EAGLE when an ITU-N node sends an MSU to an ITU-I node are the same as the steps shown in the Routing and Conversion Within a Single Network Type section, except for the conversion step.

For example, assume that Node 11 in Figure 2-11 sends an MSU to Node 16. The MSU is routed from Node 11 to Node 7 to Node 5 to Node 9 to Node 16. The following steps describe the actions performed at Node 5 (an EAGLE with IP⁷ Secure Gateway functionality):

1. Perform step 1 through step 3 as shown in the Routing and Conversion Within a Single Network Type section. In this example, assume that the routing function determines that the outgoing link is configured on the IP card at location 1203.
2. Determine whether MSU conversion is required (required when the source network type is not the same as the destination network type). In this example, Node 11 is an ITU-N node and Node 16 is an ITU-I node, so conversion is required. Conversion consists of two phases: Message Transfer Part (MTP) conversion and user part conversion.
3. Perform MTP conversion (also known as routing label conversion). The following parts of the MSU can be affected by MTP conversion:
   • Length indicator — for ITU-N to ITU-I conversion, the length of the MSU does not change
   • Service Information Octet (SIO), Priority — for conversion to ITU, the priority is set to 0. For conversion to ANSI, the priority is set to a default of 0, which can later be changed based on user part conversion.
   • Service Information Octet (SIO), Network Indicator — the NI bits are set to the NI value for the destination node. In this example, NI is set to 00b.
   • Routing Label, Destination Point Code (DPC) — the DPC is replaced with the destination’s true point code. In this example, N16 is replaced by I16.
   • Routing Label, Originating Point Code (OPC) — the OPC is replaced with the appropriate network type’s alias point code for the originating node. In this example, N11 is replaced with I11.
   • Routing Label, Signaling Link Selector (SLS) — no SLS conversion is required between ITU-I and ITU-N nodes. However, if one of the nodes were an ANSI node, conversion would be required between a 5-bit or 8-bit SLS for ANSI nodes and a 4-bit SLS for ITU nodes.
4. Perform user part conversion, if necessary. Currently, only SCCP traffic and only network management messages have the Message Transfer Part (MTP) converted. All other user parts have their data passed through unchanged.
5. Forward the MSU across the Interprocessor Message Transport (IMT) bus from location 1103 to location 1203, where the MSU is transmitted out the link towards Node 16.

The IP Signaling Gateway (IPSG) feature provides a signaling gateway (SG) application as an alternative to the IPLIM and IPGW applications. However, the IPLIM and IPGW applications continue to be supported.

The IPSG feature can run the M2PA and M3UA protocols simultaneously on the same card. They can also have GTT-enabled capabilities support with SLIC running the 64-bit IPSG GPL. The feature also supports ANSI, ITU-N or ITUN-24, and ITU-I simultaneously on one card and one association.

The IPSG feature runs on the E5-ENET-B and SLIC cards with the IPSG application. An E5-ENET-B or SLIC card running the IPSG application is referred to as an IPSG card.

The connection to the remote host is provided by IPSG M3UA and IPSG M2PA signaling links. An IPSG M3UA signaling link is a signaling link that is assigned to an IPSG linkset whose ADAPTER value is m3ua. An IPSG M2PA signaling link is a signaling link that is assigned to an IPSG linkset whose ADAPTER value is m2pa. A maximum of 128 IPSG M2PA or IPSG M3UA signaling links are supported per IPSG card running on SLIC hardware.

The IPSG M2PA signaling link can run the ANSI or ITU protocol, but not both simultaneously. ANSI and ITU can run on the same IPSG card on separate IPSG M2PA signaling links. ANSI and ITU can run on the same IPSG M3UA signaling link.

A series of three IS-NR link count thresholds are used to control the transition of the IPSG-M3UA links between Allowed, Restricted, and Prohibited states.

M2PA links on IPLIMx and IPSG cards can exist in the same linkset. M3UA links on IPSG and IPGWx cards cannot exist in the same linkset. M2PA and M3UA links cannot exist within the same linkset.

Each IPSG card running on SLIC hardware can host up to 128 SCTP associations. A maximum of 16 M3UA links or 1 M2PA link can be assigned to an association. M3UA and M2PA cannot be mixed on the same association.

The SCTP ADLER-32 or CRC-32 checksum algorithm can be selected for an individual IPLIM, IPGW, or IPSG card.

The adjacent point code (APC) of the IPSG-M3UA linkset is the point code assigned to an AS.

Provisioning for the IP Signaling Gateway feature uses the card, linkset, signaling link, IP card, IP link, IP host, and association database entities. The relationship between these entities is shown in Figure 2-18. The provisioning for the IP Signaling Gateway feature is shown in IPSG M2PA and M3UA Configuration Procedures.