Sigtran Main Concepts

Technical Manual – Signaling and Protocols U-SYS SG7000 Signaling Gateway Table of Contents

Huawei Technologies Proprietary

i

Table of Contents

Chapter 2 SIGTRAN....................................................................................................................... 2-1 2.1 SIGTRAN Stack Structure ................................................................................................. 2-1

2.1.1 Overview ................................................................................................................. 2-1 2.1.2 SIGTRAN Protocol Model ....................................................................................... 2-1 2.1.3 Application Model of SIGTRAN Protocols............................................................... 2-1 2.1.4 Basic Architecture of SIGTRAN Stack .................................................................... 2-2

2.2 Internet Protocol................................................................................................................. 2-3 2.2.1 Overview ................................................................................................................. 2-3 2.2.2 IP Address and Conversion .................................................................................... 2-4 2.2.3 Format of IP Datagram............................................................................................ 2-9 2.2.4 IP Routing.............................................................................................................. 2-14 2.2.5 Internet Control Message Protocol (ICMP) ........................................................... 2-16

2.3 SCTP ............................................................................................................................... 2-19 2.3.1 Overview ............................................................................................................... 2-19 2.3.2 Terminology........................................................................................................... 2-20 2.3.3 Functions of SCTP ................................................................................................ 2-23 2.3.4 Structure of SCTP Message ................................................................................. 2-25 2.3.5 SCTP Process....................................................................................................... 2-26

2.4 MTP2-User Peer-to-Peer Adaptation Layer (M2PA) ....................................................... 2-35 2.4.1 Overview ............................................................................................................... 2-35 2.4.2 M2PA Application.................................................................................................. 2-35 2.4.3 Services Provided by M2PA.................................................................................. 2-37 2.4.4 M2PA Message Format ........................................................................................ 2-37 2.4.5 Functions Provided by M2PA................................................................................ 2-40 2.4.6 Implementation Procedure of Basic Functions ..................................................... 2-41

2.5 M3UA............................................................................................................................... 2-53 2.5.1 Overview ............................................................................................................... 2-53 2.5.2 Concept of M3UA.................................................................................................. 2-53 2.5.3 Architecture of M3UA protocol .............................................................................. 2-54 2.5.4 Applications of M3UA............................................................................................ 2-54 2.5.5 Services Provided by M3UA ................................................................................. 2-55 2.5.6 M3UA Protocol Unit............................................................................................... 2-57 2.5.7 Functions Supported by M3UA ............................................................................. 2-87 2.5.8 M3UA Message Procedures ................................................................................. 2-90

Technical Manual – Signaling and Protocols U-SYS SG7000 Signaling Gateway Chapter 2 SIGTRAN


2-1

Chapter 2 SIGTRAN

2.1 SIGTRAN Stack Structure

2.1.1 Overview

SIGTRAN stack is the protocol stack that supports transmission of switched circuit network (SCN) signaling protocol over IP network. This protocol stack supports the inter-layer standard primitive interface defined in SCN signaling protocol hierarchy model, so as to ensure utilization of the existing SCN signaling application without modification. Simultaneously, it also uses the standard IP transport protocol as the transmission bottom layer, and satisfies the special transmission requirements for SCN signaling by adding its own functions.

2.1.2 SIGTRAN Protocol Model

The SIGTRAN protocol stack is applicable to the communication between the SG and MGC. It has two functions: adaptation and transmission. Accordingly, two layers of protocols, the transmission protocols (such as SCTP/IP) and adaptation protocols (such as M3UA, M2UA, and so on), are included in the SIGTRAN protocol stack.. Figure 2-1 illustrates the model.

M3UA M2UA M2PA ...

SCTP

IP

Figure 2-1 SIGTRAN protocol model

IP, SCTP, M3UA and M2PA, which are used in the system, will be described in detail in this manual.

2.1.3 Application Model of SIGTRAN Protocols

The SIGTRAN protocols are used in the networking model in which the narrow band and broad band equipment are interconnected. In this model, there are three basic functional entities: SG, MG and MGC, as shown in Figure 2-2.

usman.zamir-tpc

Sticky Note

(LIFO)

usman.zamir-tpc

Sticky Note

signalling gate way

usman.zamir-tpc

Sticky Note

media gate way

usman.zamir-tpc

Highlight

usman.zamir-tpc

Highlight

usman.zamir-tpc

Highlight



2-2

MG

SG

MGC

SwitchedCircuitNetwork

Packet switched network

SIGTRAN

H.248/MGCP

Figure 2-2 Isolated gateway model

The signaling from the narrow band network is accessed by the SG, while the media stream (such as trunk circuit) is accessed by the MG. The SG packetizes the inter-layer primitives (or narrow band signaling) and transmits them to the MGC, and the MGC processes the signaling, and controls the bearer connection of the MG through the media gateway control protocol (MGCP), implementing the interconnection between narrow band and broad band equipment. In this model, the SIGTRAN stack is employed between the SG and the MGC.

2.1.4 Basic Architecture of SIGTRAN Stack

I. Application Architecture of M3UA Stack

The application architecture is illustrated in Figure 2-3:

SEP STP SG MGCSS7 SS7 IP

ISUP

MTP1-3 MTP1-3MTP1-3

M3UASCTP

IP

M3UASCTP

IP

ISUP

Figure 2-3 Application architecture of M3UA stack

In the SG, the primitives of MTP3 and upper level users are packetized to the M3UA messages by M3UA, and are addressed to the correct MGC, sent through the SCTP.

II. Application Architecture of M2UA Stack


usman.zamir-tpc

Sticky Note

Service end point



2-3

SEP STP MG/SG MGCSS7 SS7 IP

ISUP

MTP1-3 MTP1-2

M2UASCTP

IP

M2UASCTP

IP

ISUP

MTP1-3

MTP3


As shown in the model, when the SG is built in the MG, the M2UA is used to send the SS7 MTP2 user signaling to the MGC. However, M2UA is not supported at present by the system, so it will not be described in this manual.

III. Application Architecture of M2PA Stack


SEP STP SG MGCSS7 SS7 IP

ISUP

MTP1-3 MTP1-2

M2PASCTP

IP

M2PASCTP

IP

ISUP

MTP1-3

MTP3MTP3


In this model, M2PA is the peer-to-peer adaptation layer of MTP2. It provides one “IP SS7 link” and the MTP2 primitive interfaces upward by comparing the MTP2 functions along with the SCTP, thus supporting seamless operation of MTP3 protocol peers over an IP network connection.

2.2 Internet Protocol

2.2.1 Overview

The IP has been used worldwide in the internet, and is becoming more and more popular. The IP makes it possible to interconnect different types of networks, and most



2-4

of all, it has great compatibility with the lower communication technologies. The main features of the IP will be described below.

I. IP Features

The IP has become the actual industrial standard due to its simplicity, efficiency and openness.

As the highest layer in the communication subsystem, the IP provides the connectionless data package transmission mechanism.

It provides a message format unified all over the world, shields the differences on link layer and hardware, to make the network interconnection convenient and reasonable.

The addressing mode unified worldwide is provided by the IP, which shields the differences in physical addresses, and makes the routing becoming available.

II. IP and Relative Protocols

There are three protocols relevant to the IP:

Address Resolution Protocol (ARP);

Reverse Address Resolution Protocol (RARP);

Internet Control Message Protocol (ICMP).

The following diagram illustrates the place of the internet protocol in the protocol hierarchy. ARP and RARP are placed at the bottom, because they are used by the IP frequently; and ICMP is at the top of it, because it will use the IP. The three protocols will be described below.

TELNET, FTP...

TCP, UDP

IPICMP

RARP ARP

TELNET: Telecommunications Network

FTP: File transfer protocol

Figure 2-6 IP and relative protocols

2.2.2 IP Address and Conversion

I. IP Address

Every interface on an internet must have a unique Internet address (also called an IP address). These addresses are 32-bit numbers. The structure of IP address is able to

usman.zamir-tpc

Sticky Note

Transmission control protocol (TCP) is a connection oriented protocol

usman.zamir-tpc

Sticky Note

User Datagram Protocol @User Datagram Protocol (UDP) is Datagram oriented protocol



2-5

help us to address conveniently in the Internet, that is, to find the network according to the net-id, then find the host according to the host-id. Therefore, the IP address is not only the computer number, but the computer connecting to one network. The IP addresses are allocated by the internet network information center (NIC) of the defense data network of United States.

For the convenience of IP address management, and the fact that some networks have many computers, while others have fewer, the IP addresses are classified into five classes, from class A to class E. The IP address is consisted of three segments. See Figure 2-7):

Class field (also called class bits): It is used to differentiate between the classes of IP addresses.

Network ID field: It specifies the net-id.

Host ID field: It specifies the host-id.

Class D address that is a type of multicast address, is reserved for the internet architecture board (IAB), and class E is reserved for future use. At present, only classes A-C are widely used.

0 net-id host-id

1 0 net-id host-id

1 1 0 net-id host-id

1 1 1 0

Multicast address

Reserved for future use

0 1 2 3 4 8 16 24 31

Class A

Class B

Class C

Class D

Class E 1 1 1 1 0

Figure 2-7 Five classes of IP address

Currently, there is almost no IP address of class A for allocation, and only classes B and C can be applied. When an organization applies the IP addresses to the IAB, what it gets is actually one net-id. The host-ids of hosts are allocated by the organization itself.

For convenience, the 32-bit IP addresses are normally written as four decimal numbers, one for each byte of the address, and these numbers are separated by dots, which is called dotted-decimal notation. See the IP address below:

10000000 00001011 00000011 00011111

It is a class B IP address and can be expressed as 128.11.3.31 in decimal number.

usman.zamir-tpc

Sticky Note

1 octet

usman.zamir-tpc

Sticky Note

2 octet

usman.zamir-tpc

Sticky Note

3 octet



2-6

The following IP addresses are reserved for special purposes.

If all the bits of a net-id are 0, it indicates “local network” or “Network strange to me”.

If all the bits of a net-id are 1. If all the bits of a host-id are 0, it indicates the IP address is the network address. If all the bits of a host-id are 1, it indicates the broadcast address is to be

broadcasted toward all hosts in the networks. All the bits of an IP address are 0, for example, 0.0.0.0. 127.X.X.X., X.X.X can be any numbers. This type of network number is used for

the local loopback test. If all the bits of an IP address are 1, it indicates to broadcast all hosts in my

network, and it is “0.0.0.0” previously.

Now we shall describe the key features of IP address:

Some of IP addresses are not graded, that is to say, different from the telephone number architecture, IP address can not reflect any geographical information of related host.

If one host is connected to two networks (such as the router), it has two IP addresses, and their network-ids are different. The host is called Multi-homed host.

According to the internet principles, local area networks (LAN) connected with transponders or bridges form one network, so, these LANs have the same net-id.

In the IP address architecture, all networks allocated with net-ids are equivalent, no matter it is a small LAN or a wide area network (WAN).

II. Subnet Addressing

In order to organize the IP addresses more flexibly, the hosts in one network have the same net-id, while the host-ids are allocated by companies or campuses. If one organization has too many hosts and they are distributed within a quite wide area, the subnetting may be carried out to arrange them in different subnets which are interconnected through routers.

Figure 2-8 describes the meaning of subnet mask used in the subnet addressing. Figure 2-8 (a) takes a class B IP address as an example, and in Figure 2-8 (b), we can see one subnet field is added in the part controlled locally. The length of subnet field is determined by the local system administrator. In the IP, the mask is a 32-bit value containing one bits for the network ID and subnet ID, and zero bits for the host ID, as shown in Figure 2-8 (c).



2-7

net-id host-id

net-id

11111111 11111111 111111 00 00000000

Allocated locally

Subnet- id

Subnet-id Host-id(a)

(b)

C lass B

Add the subbet fie ld

Subnet m ask

Figure 2-8 Meaning of subnet mask

III. Address Resolution

The IP address mentioned above cannot be used for communication out of two reasons:

1) The host address expressed in the IP address is the one in the network layer. If the datagram in the network layer is to be sent to the destined host, the hardware address of the destined host should be known, so, the resolution from the IP address to the physical hardware address should be made.

2) We would rather memorize the host name than the IP address, which also requires the resolution.

There are two resolution protocols provided in the communication architecture with IP.

For smaller networks, the “hosts” file can be used to convert the host name to the IP address. The “hosts” file offers the mapping from host name to IP address for the calling host.

For larger networks, some name servers with the domain name system (DNS) are provided, and they have many mapping table providing the conversion between host name and IP address. The name conversion software in the calling host finds the name server of the DNS and performs the conversion automatically. The DNS is the application layer software.

We shall illustrate the procedure of converting from host name, physical host hardware address to IP address through an example.

Suppose host-a is going to communicate with host-b in Figure 2-9, and host-a gets the IP address (209.0.0.6) of host-b through the DNS.



2-8

host-b

209.0.06

08002B00EE0A

DNS

ARP

Networkadaptator

IP=209.0.0.6

Host name

host-b

08002B00EE0A

Host name

host-aIP=209 .0.0.5

Destination host name

IP address ofdestination

host

net-id=209.0.0

Physical address

of destination host

Figure 2-9 Conversion among host name, physical address and IP address

The conversion from IP address to physical address is performed by the address resolution protocol (ARP). In Figure 2-9, the 48-bit Ethernet address 08002B00EE0A of the destination host is converted from the IP address 209.0.0.6 through the ARP. Suppose the host is connected to one LAN. If it is one WAN, the physical address on the WAN will be resolved.

Because the IP address is 32-bit, while the Ethernet physical address (MAC address) is 48-bit, it is not a simple conversion relationship between them. In addition, some computers may come into one network, and others may remove from it. The physical address will even be changed due to the changing of network adaptor. Therefore, one dynamic mapping table from IP address to physical address should be stored in the computer.

The above problems are solved by the ARP.

Essential to the efficient operation of ARP is the maintenance of an ARP cache on each host. This cache maintains the recent mappings from Internet addresses to hardware addresses. If host-a is going to send an IP datagram to host-b on its network, it will query its cache for the IP address of host-b. If yes, it will find its corresponding physical address, and then send the datagram to the physical address.

However, it is possible that host-a cannot find the entry mapping from IP address of host-b to its physical address. Under this condition, host-a will run the ARP automatically, and find the physical address of host-b by the steps below:

1) ARP sends an Ethernet frame called an ARP request to every host on the network, and the ARP request contains the IP address of the destination host.

2) All hosts on the LAN run their ARP processes and receive the ARP request.



2-9

3) The host-b's ARP layer receives this broadcast, recognizes that the sender is asking for its hardware address, and replies with an ARP reply. This reply contains the IP address and the corresponding hardware address.

4) After host-a receives the reply, it will write the mapping between IP address and physical address of host-b into its ARP cache.

Under many conditions, host-b shall send IP datagram to host-a immediately after receiving the datagram from host-a, so, host-b will also force an ARP request-reply to host-a. To reduce the communication traffic on the network, host-a will write the mapping from its IP address to physical address to the ARP request before sending the request. After receiving the request, host-b will write the mapping to its ARP cache.

When performing the address conversion, the reverse ARP may be used (RARP). Through the protocol, the diskless system is enabled to read its IP address. The diskless system can download the installation methods by running the file transport codes in its ROM and get the necessary operating system and IP communication software from hosts on the LAN. However, no IP address is included in the software. The RARP in the ROM should be run for the diskless system to read its IP address.

The steps of RARP:

1) At least one host should work as the RARP server. The diskless system sends the RARP request (with the same packet format as the ARP request) to the LAN and the request contains its physical address.

2) The server provides the mapping from the hardware address of the diskless system to its IP address. It will find out the corresponding IP address upon receiving the RARP request, write it into the RARP reply, and return it to the diskless system. In this way, the diskless system gets its IP address.

2.2.3 Format of IP Datagram

Figure 2-10 shows the format of IP datagram.



2-10

Version IHL Type of service Total length

Identification Flag

Fragment offset

Time to live

Protocol

Header checksum

Source address

Destination address

Options

Padding

Data ...

Precedence D T R C Not used

Bits 0 4 8 16 19 24 31

Fixed lengthof 20 bits

Lengthvariable

0 1 2 3 4 5 6 7

Figure 2-10 Format of IP datagram

One IP datagram consists of header and data. The former part of the header is of fixed length with 20 bits and the length of the latter part is variable. The meanings of all fields in the header will be described below.

I. Fixed Part of IP Datagram Header

1) Version: 4 bits

It indicates the IP version. Both ends in communication must use the same IP version. This document describes version 4.

2) IHL: 4 bits

The max. value indicated is 15 units (four bits per unit), so the max. value of IP header length is 60 bits. If the header length of IP packet is not the integral 4-bit, the last padding fields must be added so that the data part always starts at the integral 4-bit. Sometimes 60 bits may be not enough (such as the source address route selection), however, it will restrict the extra overhead.

3) Type of service: 8 bits

The type of service provides an indication of the abstract parameters of the quality of service desired. See Figure 2-10 for its meaning.

The first three bits indicate the priority of the type of service, and the datagram may have one of eight priorities.

Bits 0-2: Precedence.

Bit 3: 0 = Normal Delay, 1 = Low Delay.

Bit 4: 0 = Normal Throughput, 1 = High Throughput.



2-11

Bit 5: 0 = Normal Reliability, 1 = High Reliability.

Bit 6-7: Reserved for Future Use.

4) Total Length: 16 bits

Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets.

When the datagram is to be sent in segments, the “total length” refers to the total length of header and data after, instead of before, the segmentation.

5) Identification: 16 bits

An identifying value is assigned by the sender to aid in assembling the fragments of a datagram. Note that the “Identification” here is a not sequence number, because the IP provides no connection service.

6) Flags: 3 bits

Various Control Flags.

Bit 0: reserved, must be zero

Bit 1: (DF) 0 = May Fragment, 1 = No Fragment.

Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

7) Fragment Offset: 13 bits

This field indicates the part to which this fragment in the datagram belongs. The fragment offset is measured in units of eight octets (64 bits).

8) Time to Live: 8 bits

This field indicates the maximum time the datagram is allowed to remain in the internet system. The time is measured in units of seconds. The recommended value is 32 seconds, and can also be set to 3–4 seconds, even 255 seconds.

9) Protocol: 8 bits

This field indicates the next level protocol used in the data portion of the internet datagram. Some protocols widely used and the values of responded protocol fields are: UDP (17), TCP (6), ICMP (1), Gateway-to-Gateway Protocol-GGP (3), Exterior Gateway Protocol-EGP (8), Interior Gateway Protocol-IGP (9), Open Shortest Path First Protocol-OSPF (89) and TP4 (29) of ISO.

10) Header Checksum: 16 bits

It is only applicable to the header of a datagram. Since some header fields, for example, time to live, change, this is recomputed and verified at each point that the internet header is processed.

11) Address

Either source address or destination address occupies four bits.



2-12

II. Variable Options in IP Header

It is used for debugging, measurement and other security methods. Its length is variable, ranged from one to forty bits, which is determined by the selected option. Some options require one bit only (Figure 2-11 shows the option format), and others may require more, but the format of the first bit is still shown in Figure 2-11. These options are assembled one by one and no separator is required, and zeros are filled into the options so that the number is the integral 4-bit.

1 Copied to all fragments

0 Copied to the first fragment only

Copied flag

Option class Option number

0 Datagram or control

1 Reserved for future use

2 Debugging and measurement

1bit 2bit 5bit

3 Reserved for future use

Figure 2-11 Option format

There are three fields in the option.

1) Copied flag: 1 bit

The copied flag controls the operation of routers in the network during the datagram fragmentation.

0 = copied this option into the first datagram fragment only;

1 = copied this option into all fragments.

2) Option class: 2 bits

Only two classes are available, as shown below.

0 = control

1 = reserved for future use

2 = debugging and measurement

3 = reserved for future use

3) Option number: 5 bits

The option number indicates the utility of one option.



2-13

The following option numbers belong to the option class 0:

0: End of Option list.

1: No Operation. Its function is the same as the fill-in field.

The above two are the options occupying only one bit respectively, and the following options will occupy more than one bit.

2: Security. It is used to carry security, compartmentation, user group (TCC), and handle restriction codes compatible with the defense of department (DOD) requirements.

7: Record route, variable. Figure 2-12 shows the format of “Record route” option.

Option code Length Pointer

First IP address

Second IP address

...

0 8 16 24 31

Figure 2-12 Format of “Record route” option

The record route option provides a means for the source of an internet datagram to supply routing information in forwarding the datagram to the destination, and to record the route information.

The format of first three octets is as follows:

Option type code----0, 0 and 7 should be filled in the fore three fields. Length----Fill in the length of the option (including the length of fore three bits). Pointer----Indicating the offset of next blank position into which the IP address can

be filled in.

After that, the IP addresses of 4 octets will be filled in by routers. When a router receives the datagram containing the record route option, it will check its pointer position. If the pointer does not exceed the table length, the router adds its own IP address into the table, increases the pointer by four, and then transfers the datagram. If the table is full, its IP address will not be added, only the datagram is transferred.

However, common computers will not take notice of the recorded route in these datagrams. The source address, therefore, should negotiate with the destination source, ask the destination address to extract the route information from the datagram and send it back to the source address.

The following two options are of the source address routing:

3: loose source routing, variable.



2-14

9: strict source routing, variable.

The route of datagram transmission is defined by the source address. In the strict source routing, the defined route cannot be changed. However, the loose source routing allows some defined routers to be changed to other routers.

The format of source routing option is similar with that of record route. The fore three octets are fixed, but what should be filled in are 1, 0 and 3 (for the loose source routing) or 1, 0 and 9 (for the strict source routing). The IP address tables following the three octets are not empty, and are inserted by the source address before transmission. The datagram is transmitted on the route specified by the source address. After the router receives the datagram, it will forward it without inserting any data if the pointer is greater than the table length. If the pointer is normal, the IP address of the router will replace the original IP address and forward the datagram to the next address in the table. Note that one router may have two or more IP addresses. The one written in the recorded route table is the incoming IP address of the router, while the other written by the router is the outgoing IP address.

The record route option provides a means to record the route of an internet datagram.

The last option is the Internet timestamp.

4: timestamp, variable. It has the similar format in Figure 2-12. Besides the option type code (0, 2 and 4), length and pointer, it has the Overflow (4 bits) and the Flag (4 bits) fields. The Flag values are:

0 – It specifies time stamps only, which is stored in consecutive 32-bit words,

1 -- Each timestamp is preceded with internet address of the registering entity,

3 -- The internet address fields are predefined. An IP module only registers its timestamp if it matches its own address with the next specified internet address. The overflow count is incremented by one, and the value is the maximum number of routers the datagram is forwarded through when you consider that there may be not enough room to be inserted with the timestamps.

The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight universal timer (UT). It records the date and time that the router receives the datagram. When the time of the host is inconsistent with the clock, the recorded timestamp may be error. The timestamp is used to count the time delay and delay changing created during the period the datagram is forwarded by the router.

2.2.4 IP Routing

There are many paths for the communication between two hosts. The routing for the packet is determined by the network layer. Routing is the important function of the network layer, which is to forward the packet to the destination host based on the destination IP address in the datagram. This is the function of router.



2-15

As a router,

It must have two or more network layer interfaces to connect different networks. It must have the network layer protocols at least.

The router has two functions:

It generates the routing table; It forwards the packet to other networks, which is done based on the routing table.

Subnet 1129.6.0.0/16

2202.6.6.0/24

Router A B

B

129.6.69.107 202.6.6.1

129.6.0.1

Subnet 361.0.0.0/8

Interface address 61.1.1.1 Interface address

Router Subnet

Interface address Interface address

Figure 2-13 Routers connection

As shown in Figure 2-13, router A and router B connect to three networks. The following routing table will be stored in router A:

Destination network address

Destination network mask Next hop address Out interface

202.6.6.0 255.255.255.0 129.6.0.1 129.6.69.107

129.6.0.0 255.255.0.0 129.6.69.107 129.6.69.107

61.0.0.0 255.0.0.0 61.1.1.1 61.1.1.1

The following routing table will be stored in router B:

Destination network address

Destination network mask Next hop address Out interface

61.0.0.0 255.0.0.0 129.6.69.107 129.6.0.1

129.6.0.0 255.255.0.0 129.6.0.1 129.6.0.1

202.6.6.0 255.255.255.0 202.6.6.1 202.6.6.1

Two methods can help the router get the table.

The operation personnel types in the entries one by one, which is called the static routing.

The routing protocols of the router are started by the operation personnel and these entries are created by the protocols, which is called the dynamic routing. OSPF and RIP are often used.



2-16

LAN1 WAN

Router

Route selection resolutionprotocol

UnpacketizingEncapsulating

Sending Transmitting Receiving

IP

ETH PPP

IP

ETH PPP

LAN2

Router

Ethernet Serial interface portEthernet Serial

interface port

Figure 2-14 Work flow of the router

Figure 2-14 shows the process the router forwards the packet. The physical layer receives one datagram from one port of the router and sends it to the data link layer. The link layer removes the link layer encapsulation, and then sends it to the network layer according to the protocol fields. For the Ethernet frame encapsulated in the RFC894 mode, it is to remove the source MAC, destination MAC, protocol and CRC. The network layer will see whether it is destined to local host. If yes, it will remove the encapsulation and send it to upper layer; if not, it will find the routing table according to the datagram destination and forward the datagram to the data link layer of corresponding port if the route is found. If the route, however, cannot be found, the datagram will be discarded.

2.2.5 Internet Control Message Protocol (ICMP)

The transmission of IP datagram cannot ensure the security. However, the IP layer also ensures the transmission quality, which is the function of the ICMP. It allows the host or router to report error or abnormity. But the ICMP is not a high layer protocol, it still is one of the IP layer. As the data in the IP layer datagram, the ICMP message is added by the header of IP datagram and sent out). See Figure 2-15 for the relationship between ICMP message and IP datagram. The format of ICMP message is shown in Figure 2-16.

IP header Datagram data

ICMP message

IP datagram

Figure 2-15 Relationship between ICMP message and IP datagram



2-17

Type Code Checksum

Contents depends oncode and type

0 8 16 31

Figure 2-16 Format of the ICMP message

The first four bytes have the same format for all messages, but the remainder differs from one message to the next.

The type field occupies one byte, identifies the particular ICMP message, as shown below:

Value of Type field Type of ICMP message

0 Echo replay

3 Destination unreachable

4 Source Quench

5 Redirect

8 Echo request

11 Time exceeded

12 Parameter problem

13 Timestamp request

14 Timestamp reply

17 Address Mask request

18 Address Mask reply

The code field also occupies one byte. Some types of ICMP messages use different values of the code field to further specify the condition. The checksum occupies two bytes, and covers the entire ICMP message. The checksum of the datagram header does not check the contents of the datagram, so it cannot ensure the accuracy of the ICMP message.

The ICMP message may be a query message or an error message.

Among the ICMP error messages, the redirecting message is used most frequently. Figure 2-17 illustrates the usage of the redirecting message.



2-18

B

CAR2

R1Network 2

Network 3

Network 1

Figure 2-17 Example of the ICMP redirecting message usage

In Figure 2-17, the IP datagram sent from host A to host B should go through router R1, while that sent by host C should go through router 2. Suppose there is only one default router R1 in the routing table of host A. The datagram sent from host A to C will be sent to R1. However, in the routing table in R1, it defines the datagram sent to C should go through R2. Thus, the datagram is forwarded to R2 from R1, then to C. Obviously, the routing is not good, and should be improved.

Router R1 sends an ICMP redirecting message to host A, containing the IP address of R2 the datagram will be forwarded to. Host A updates its routing table upon receiving the information. After that, all datagrams sent from A to C will be forwarded to R2, not R1.

Figure 2-18 shows the format of the ICMP redirecting message. The IP address that the datagram is forwarded to is written in the fifth to eighth bytes, and others identify the particular datagram. All of the header part should be added, while only the fore eight bytes of data are added, which include the data (such as port number) of the header of the transmission layer data unit.

Type

Code

ChecksumIP address of router

Header of original IP datagram

Fore 8 bytes of original

IP datagram

0 8 16 31

Figure 2-18 Format of ICMP redirecting message

If one host with higher speed sends a string of datagrams to one destination host (or router) with lower speed, congestion may be caused on the destination host, and some datagrams may be discarded. Through the higher protocol, the source host will know that some datagrams are discarded, and it will re-send these datagram continuously, which causes the congestion more badly. Under this condition, the destination host



2-19

sends the ICMP source quench message to tell the source address to stop sending the datagram until the situation becomes normal.

The following are some ICMP query message used often:

The ICMP echo request is sent by the host or router to a specific destination host. The destination host receiving the message should send the ICMP echo reply. It is used to test whether the destination address is reachable or in its relative status. Packet InterNet Groper (PING) service in the application layer can test the connection between two hosts. The ICMP echo request/reply is adopted in the service.

When receiving the ICMP timestamp request, one host or router is requested to answer the current date and time. One 32-bit is included in the ICMP timestamp reply, and the integer in it indicates the total seconds since 1900-01-01. The timestamp request/reply is used for clock synchronization and time measurement.

The ICMP address mask request/reply enables the host to get the address mask of one interface from the subnet mask server.

2.3 SCTP

2.3.1 Overview

I. Concept of SCTP

The stream control transmission protocol (SCTP) is a reliable transport protocol that operates over a potentially unreliable connectionless packet service such as IP.

II. Features of SCTP

Transport protocol based on subscriber’s message packets. Supporting orderly/disorderly transmission of subscriber datagram in the flow. Multiple flows can be established in one association, and the data in the flows do

not interfere with each other. Multi-home can be supported at one end or both ends of the association to

improve the reliability of the link. The association must pass the COOKIE authentication before establishment to

guarantee the security. A COOKIE mechanism is employed during the initialization to provide protection against security attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup.)

Path fault detection at real time.

In the following part, the protocol is discussed in detail.



2-20

2.3.2 Terminology

I. Transport Address and IP Address

The transport address of SCTP is one IP address plus one SCTP port number. SCTP port number is used for the identification of the users at the same address, and it is identical to that of TCP port number. For example, the IP address 10.105.28.92 and SCTP port number 1024 indicate one transport address, while 10.105.28.93 and 1024 mean another transport address. 10.105.28.92 and 1023 indicate different transport addresses.

II. Host and Endpoint

Host: It is a computer, configured with one or multiple IP addresses, and is a typical physical entity.

Endpoint: The logical sender/receiver of SCTP packets. It is a typical logical entity.

As prescribed in the SCTP, only one association can be established between two endpoints.

On an SCTP multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint.

Therefore, there may be multiple endpoints on a host. Their relations are shown in Figure 2-19.



2-21

SCTP

IP address 1

Port1

Port 2

User1

User2

Endpoint 1

Endpoint2

Host

IP address 1

Figure 2-19 Relation between SCTP host and endpoint

Example:

A server provides HyperText Transfer Protocol (HTTP) and FTP functions. It has three network adaptors, corresponding to three IP addresses: 10.105.28.1, 10.105.29.1 and 10.105.27.1. These two services are run on SCTP. HTTP uses port 80, while FTP uses port 21. They use all the three IP addresses. In this way, the SCTP maintains two endpoints: One is HTTP service (endpoint A), which has three transport addresses: 10.105.27.1, 80, 10.105.28.1, 80, and 10.105.29.1, 80. The other is FTP service (endpoint B), which has three transport addresses: 10.105.27.1, 21, 10.105.28.1, 21, 10.105.29.1, 21. In this way, when a client wants to use the HTTP service on this server, it must establish an SCTP association with endpoint A. If it wants to use the FTP service on this server, it must establish an SCTP association with endpoint B. The destination of these two associations must be this server, in other words, one host can have multiple endpoints. Therefore, although only one association can be established between two endpoints, there may be multiple associations between two hosts.

III. Association and Stream

Association: It specifies the logic connection or channel established between two SCTP endpoints for data transmission, through the four-way handshake mechanism prescribed in SCTP.

Stream: It is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. For example, two groups of data A, B and C, X, Y and Z need to be transported in sequence, but the two groups do not have requirement for sequence



2-22

between them. Therefore, A, B and C can be transported in one stream, while X, Y and Z can be transported in another stream.

Noted that:

Stream is in the association. Association 1 and association 2 may all have stream 1, but they are irrelative.

Stream is unidirectional, including outbound stream and inbound stream. Stream is a logical concept, and is not related to address and path.

Figure 2-20 demonstrates the relation between association and stream.

SCTP endpoint BSCTP endpoint A

It can have multiplepairs of IP/SCTP-port SCTP association

SCTP stream(unidirectional)

It can have multiplepairs of IP/SCTP-port

Figure 2-20 Relation between association and stream

IV. TSN and SSN

TSN: Transmission Sequence Number. It is a 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries. TSN is maintained on the basis of association.

SSN: Stream Sequence Number. In each stream of an SCTP association, a 16-bit sequence number is assigned to each data chunk sent in the stream by the local end, in order to ensure the sequenced transmission in the stream. SSN is maintained on the basis of association.

The assignments of TSN and SSN are independent on each other.

Endpoint A connects endpoint B through two outbound streams. Data chunks A, B, C and D need to be sent in the following sequence: A in stream 1, B in stream 2, C in stream 1, and D in stream 2. Since D is too long, it is separated into D1 and D2. The TSNs and SSNs of the five data chunks are shown in Table 2-1:

Table 2-1 Relation between TSN and SSN

Data TSN SSN

A 1 1

B 2 1

C 3 2



2-23

Data TSN SSN

D1 4 2

D2 5 2

As D1 and D2 have identical SSNs but different TSNs, the peer end can identify that D1 and D2 are the segments of the same data chunk and know the sequence. Because SCTP can support multiple streams, sequenced transmission is carried out in a certain stream. When the data sequence in a flow goes wrong, for instance, data 1, 2 and 3 are transmitted in a flow, 2 and 3 have been received, but 1 has not been received, and needs to wait, the data of other stream will not be affected because they can be transmitted to the upper layer as long as the sequence is correct. In this way, the blocking of TCP head is avoided.

V. Others

Path: In IP network, the transmission path is related not only to destination IP address, but also to the source IP address. The path is defined as the route for data transmission. Actually, it is co-defined by destination IP address and source IP address. SCTP supports multi-home. That means multiple IP addresses can be used for transmission. A relatively conservative policy is adopted: When an association is established, a main path with main source IP address and main destination IP address will be adopted for transmission. Only when the main path is unreachable or needs retransmitting, other paths will be used.

CWND: Congestion Window. An SCTP is also a protocol for slide window. The congestion window is for every destination address. It can be adjusted according to network conditions. When the length of the non-acknowledgement from the destination address exceeds its CWND, the end point will stop sending data to the address.

RWND: Receiver Window. An SCTP variable that a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver's inbound buffer.

2.3.3 Functions of SCTP

The basic functions of SCTP are shown in Figure 2-21:



2-24

Path management

Packet validation

Chunk bundling

Acknowledgement and congestion avoidance

User data fragmentation

Sequenced delivery within streams

Association startup and takedown

Figure 2-21 Functional view of the SCTP transport service

Association startup and takedown

SCTP is an association oriented transport protocol. Usually, the data can be transmitted between two endpoints that have been established an association (SCTP allows the data be transmitted in certain steps during the startup of association). Therefore, the startup and takedown of associations are the preconditions for other services.

Sequence delivery within streams

SCTP can transport the datagrams in sequence. The datagrams sent in sequence must be put in one stream, and the stream is the basis for sequenced transmission.

User data fragmentation

When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path maximum transmission unit (MTU). On receipt, fragments are reassembled into complete messages before being passed to the SCTP user.

Acknowledgement and congestion avoidance

SCTP assigns a TSN to each user data fragment or un-fragmented message. The TSN is independent on any stream sequence number assigned at the stream level. The receiver acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separating from sequenced stream delivery.

Chunk bundling



2-25

The SCTP user has the option to request bundling of more than one user message into a single SCTP packet. The chunk bundling function of SCTP is applicable to assembly of the complete SCTP packet and its disassembly at the receiver.

Packet validation

A mandatory Verification Tag field and a 32-bit checksum field are included in the SCTP common header.

Path management

The path management function monitors reachability through heartbeats when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes.

From the above description, we can conclude the differences between SCTP and TCP.

1) TCP is transmitted on the basis of character stream. Its upper layer must have its own demarkation mechanism. SCTP is transmitted on the basis of datagram and has no upper-layer demarcation.

2) SCTP supports the configuration of multiple IP addresses. 3) SCTP defines stream, in which the data is transmitted in sequence.

2.3.4 Structure of SCTP Message

The structure of SCTP message is shown in Figure 2-22:

Figure 2-22 Structure of SCTP

SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. In this way the bundling of SCTP chunks are realized. There are many types of chunks, such as initialization (INIT), initialization acknowledgement (INIT



2-26

ACK), SHUTDOWN, ABORT, DATA and SACK. Chunks have their own header and parameters. The parameters are in the type, length, value (TLV) format. When SCTP transmits DATA, TSN is allocated according to data chunks instead of datagrams. Therefore, TSN is located in the parameter of DATA chunk rather than in common header.

There is a verification tag in SCTP, which is randomly generated by the local end for the association during startup. In the startup process of the association, the two sides will exchange their tags, and when the data is transmitted, the sender must carry peer’s tag in the common header for check.

2.3.5 SCTP Process

The SCTP process includes: startup of association, takedown of association, transmission and validation of data, congestion control mechanism, and path management mechanism. The following part introduces the main processes of SCTP.

I. Startup of Association

The startup of SCTP association is a four-way handshake process, which has four message interactions: INIT, INIT ACK, COOKIE ECHO and COOKIE ACK, as shown in Figure 2-23.

INIT(Tag_A)T1-init INIT ACK(Tag_Z, connection information Z)

Endpoint A Endpoint Z

T1-cookieCOOKIE ECHO(connection information Z) + DATA

COOKIE ACK +DATA + SACKEstablished

Established SACK

Italic items: optional information chunks

T3-rtx

Figure 2-23 Interaction during the startup of SCTP association

The startup process of SCTP association:

The initiating end of the association must create a data structure TCB (Transmission Control Block) to describe the association (including the fundamental information) to be initiated, and then send the INIT message to the peer end. In this message, the parameter usually carries one or multiple IP addresses used by the local end. If no IP address is carried, the peer end will take the source IP address of the INIT message as the IP address of the end. In common header, the verification tag field is set to “0”, because the tag of the peer end is unknown. In the message parameter, the tag of the



2-27

local end and the expected inbound/outbound stream numbers should be included. After the sending, the timer “INIT” is started, for waiting the INIT ACK message from the peer end. If the timer times out, the INIT message will be resent till the maximum retransmission time is reached. After such actions, the sender enters COOKIE-WAIT status.

Upon receiving the INIT message, the receiver of the association will generate a tag, which will act as the initial tag of the local end and will be put into the parameter of the INIT ACK message. Then a TCB will be generated according to the basic information of association. However, this TCB is a temporary TCB. After the TCB is generated, the mandatory information in it, including the time stamp and life period of COOKIE, and the secret key in local end are calculated into a 32-bit Message Authentication Code (MAC) through the algorithm described in RFC2401 (this calculation is irreversible). After that, the mandatory information and the MAC are combined into a parameter called STATE COOKIE, which is included in the INIT ACK message. The verification tag in the INIT ACK message is set to the initial tag value in the INIT message. The INIT ACK message usually carries the information such as the IP address used by the local end and inbound/outbound streams. When the INIT ACK message is sent to the peer end, the temporary TCB is deleted and the receiver does not reserve any resources for this association.

When the initiating end of the association receives the INIT ACK message, the INIT timer will be stopped. Its own TCB will be updated, and the information obtained from INIT ACK will be filled in. Then the COOKIE ECHO message will be generated to carry back the STATE COOKIE in the INIT ACK message. The timer COOKIE is started, and the status is changed into COOKIE-ECHOED.

After receiving the COOKIE ECHO message, the receiver of the association will perform COOKIE check. The TCB in the STATE COOKIE and the local secret key will be calculated into an MAC, according to the MAC algorithm described in RFC2401. This MAC will be compared with that in the STATE COOKIE message. If they are different, this message will be discarded. If they are identical, the time stamp in the TCB will be taken out to compare with the current time. If the time has exceeded the life time of COOKIE, the message will be discarded; otherwise, an association to the peer end will be set up according to the information in TCB. The status will be changed into ESTABLISHED, and the COOKIE ACK message will be sent back.

Upon receiving the COOKIE ACK message, the initiating end of the association will stop the timer COOKIE, and the status will be changed into ESTABLISHED. Therefore the startup of association is finished.

From the above description, we can see two differences between SCTP and TCP:

Protecting against “service denial” attack



2-28

A

r the

The receiver (or server) of the association undergoes no status change during the startup process from CLOSED to ESTABLISHED. It differs greatly from that of TCP in which the server receives SYN and enters SYN-RCVD. For a TCP, a malicious attacker can make advantage of the TCP gaps of some operating systems, and keep the servers stay in an intermediate status in the startup of association for a long time. The repetition of such process will fill the limited detecting queues of the server, and the association requests from other hosts cannot be accepted. Then the “service denial” attack is implemented. However, there is no such case in SCTP. Acting as the server, SCTP will not assign any resources for an association that has not finished the four-way handshake. In this way, the attack by exhausting resources is avoided. Therefore, SCTP is safer than TCP.

Protecting against “masquerade” attack of IP address

COOKIE mechanism is also the guarantee in SCTP, which ensures the security and protects against “masquerade” attack of IP address. Assume an attacker is trying to establish an association to the server by simulating the IP address of a legal host. When he/she sends the INIT message to the server, the server will send back the INIT ACK message. Usually, the attacker and the IP address simulated are not located in the same LAN. Then the attacker cannot get this INIT ACK message, and he/she cannot obtain the local secret key of the server. Then, the attacker cannot generate a legal MAC. When he/she sends the COOKIE-ECHO message to the server, the COOKIE parameter cannot pass the check, and the association cannot be set up. To be safe, the local secret key of the receiver varies after a period.

II. Termination of Association

The SCTP association can be terminated in two ways: One is GRACEFUL shutdown, and the other is UNGRACEFUL shutdown. Just as their names imply, the former means that all data in queue at either endpoint is delivered to the respective peers before the association is terminated. The latter means directly terminating the association, and the data is directly discarded. These two modes are described as follows:

1) GRACEFUL shutdown

GR CEFUL shutdown of association is implemented through three-way handshake:

Firstly, the user at the initiating end of the termination sends a GRACEFUL request to the SCTP for terminating the association. Then the SCTP association is changed from the ESTABLISHED status to the SHUTDOWN-PENDING status, in which the SCTP will no longer accept any requests from upper layer for data transmission on this association. At the same time, the association will wait fovalidation of all the data sent from the local end but has not been validated. When all the data has been validated, the SHUTDOWN message will be sent to the peer end, and the association will be changed into the SHUTDOWN-SENT status, and the SHUTDOWN timer will be started to wait for the SHUTDOWN-ACK



2-29

ation mechanism of SCTP

TDOWN

MPLETE

DOWN COMPLETE message, the peer end will delete

, he cannot interfere an established association by sending a legal ABORT message.

III. Data Transmission

f an association. During the ed in some steps.

ion:

r maintains every destination IP address, while the latter maintains

sion path, it specifies the size of which the data can be

escribe two different objects, they are d

message from the peer end. In this status, the data received from the peer end will be validated immediately. The slowdown validapplication will be introduced in the following part. When the peer end receives the SHUT DOWN message, it will enter the SHOUTDOWN-REVD status, in which the SCTP will no longer accept any requests from upper layer for data transmission on this association. When all the un-transmitted data and un-validated data sent from the local end has been sent and validated, the SHUTDOWN ACK message will be sent. The SHUtimer will be started to wait for the SHUTDWON COMPLETE message. Upon receiving the SHUTDOWN ACK message, the initiating end of the termination will stop the SHUTDOWN timer, send the SHUTDOWN COmessage to the peer end, and then delete the TCB of the association. Upon receiving the SHUTthe TCB of association.

2) UNGRACEFUL shutdown

Since this shutdown mode cannot guarantee the security of the data, it is relatively simple. When the initiating end sends an ABORT message to the peer end, the TCB of association will be deleted immediately. When the peer end receives the ABORT message, it will delete the TCB of the association immediately. Since there is verification tag, the attacker cannot obtain the tag values of the SCTP associations of other hosts except that he has intercepted the message. Therefore

Data transmission takes place after the establishment oestablishing process, data can be carri

Features of SCTP data transmiss

1) Stream control with window

SCTP adopts two kinds of windows for data transmission: One is CWND, and the other is RWND. The formeevery association.

CWND describes: For a transmistransported without congestion.

RWND describes: For the peer end of association, it specifies the size of which the data can be received without data loss. Since they dnee ed for restriction of the data transmission.

2) The restrictions of these two windows on the data transmission: If the RWND shows that the receiving buffer of the peer end cannot receive data (for example, RWND=0), the data cannot be sent to the peer end. However, if no



2-30

t to “0”. Even if there is space in the peer receiving buffer, the data cannot

as reached

nsmit” should be sent in smit” data is preferred.

selected validation can be divided into slowdown validation and selected

0 ms. In this way, the overload of the ACK messages on the

ENT status, immediate validation

owledgement message (SACK) of SCTP selected validation is shown in Figure 2-24:

un-validated data is sent currently, the data can be sent (provided that CWND allows). In this way, the lock can be prevented, because if no un-validated data is sent, no validation from the peer end will be received. As the size of the peer receiving buffer is carried in the validation packet, RWND cannot be updated, and will be sebe sent. When data is to be transmitted to an address, if the un-validated data hor exceeded the limit of CWND, no data can be sent to this address. Before new data is translated, the data labeled as “retraadvance. That means the “retran

3) Slowdown/selected validation

Slowdown validation.

Slowdown validation contrasts to the immediate validation. It means that upon receiving a datagram, one end of SCTP association will not send the ACK message to the peer end immediately. It will send the ACK message to the peer end after receiving two datagrams (one datagram may contain several chunks), or when a datagram has not been validated for 20path can be prevented.

In many cases, SCTP should perform immediate validation rather than slowdown validation. The usually case is that when gaps occur to the data chunk sequence, SCTP will use immediate validation. That is whenever data is received, validation will be performed until the gap is mended. Besides, after the SHUTDOWN message is sent, and the association enters the SHUTDOWN-Smechanism will be adopted for the peer end data.

Selected validation contrasts to sequenced validation or cumulative validation. The typical protocol that adopts cumulative validation is TCP. For instance, when one end of TCP receives data 1, 2, 3, 4, 5, 6, 7, 8 and 9, since there are gaps between 2 and 4, 5 and 7, the ACK field of the message can only be filled with 2 and the data in the rear part cannot be validated. On the contrary, SCTP can do that. The ackn



2-31

Figure 2-24 Structure of SACK message

Three fields should be noted:

Cumulative TSN Ack: It is the maximum TSN without gaps. In the former example, it is 2.

Number of Gap Ack Blocks: It is the number of gaps in the received data sequence. In the former example, there are two gaps, one is between 2 and 4, and the other is between 5 and 7.

Gap Ack Block #N Start, Gap Ack Block #N End: The start and end of gap acknowledgement block. Since there are two gaps, there exist these two acknowledgement blocks. For the first one, the start is 4, and the end is 5. For the second one, the start is 7, and the end is 9.

In this way, SCTP can validate all the data received, in spite of gaps.

The data that has not been covered by Gap Ack Block (the data falls in the gaps) means that the acknowledgement message is not received. When the data sender receives such SACKs, it will retransmit the data after receiving another three continuous SACKs that indicates the data has not been received. It means that the data will be re-sent after four SACKs are received, to avoid unnecessary retransmissions.

4) Retransmit due to timeout:

SCTP maintains a T3 timer for each destination IP address. It can also maintain a T3 timer for each data sent (it is based on the realization). Although it is complex to



2-32

maintain a timer for each IP address, lots of system resources are saved. The ruleof SCTP can be described as follows

When transmitting (retransmitting) data to a destination IP address, if no T3 timer is running, a T3 timer will be started. Vice versa.

When receiving a SACK, if all the data has been validated, the T3 timer will be stopped. If the earliest data is proved to be un-validated, the T3 timer will be re-started.

If the T3 timer times out, the MTU (say 1500 bytes) of the path to this destination will be checked. Then all the sent but un-validated chunks will be bundled into one data block and re-sent to the peer end, and the T3 timer is started.

From the above rules, we can see that when a timer is maintained for a path, it is unfair for the data sent later than the earliest ones. For example, after data 1 is sent, T3 timer is started, with the value of 2 seconds. After 1.9 seconds, when no validation is received, data 2 is sent. After 0.1 second, data 2 is timed out and will be labeled as “retransmit” If validation is received before retransmission, it will not be retransmitted. Therefore, it is unfair for data 2.

From rule 3 we can see that when the data is in huge amount, the data re-sent are the chunks sent early but un-validated. For the latterly sent data chunks, although T3 timer times out, they will not be re-sent immediately. Only after T3 timer times out for several times, they will be re-sent. During this waiting period, SACK may be received. Of course, it cannot be absolutely fair when maintaining one timer for a path, unless one timer is maintained for each data chunk.

The value of T3 timer is also changed according to the loopback time of the path. SCTP can obtain the loopback time of the path according to the time difference between the transmission of new data and the receiving of validation. The algorithm is similar to that of TCP.

It is obvious that, there are two cases for the sender of SCTP to retransmit a data chunk:

It is proved by the peer end with four continuous SACKs that the data chunk has not been received.

The T3 timer on local path is timed out. 5) Multi-homed:

Multi-homed means multiple IP addresses are supported. The following demonstrates how multi-homed is used by SCTP in data transmission.

For the CWND of SCTP described in the former part, the T3 timer is maintained for each transport address of the peer end, and it supports multi-home.

SCTP supports multi-home conservatively. Multi-home is mainly used to guarantee the reliability of the endpoint, which can have redundant addresses. Therefore, when SCTP transmits data, a main address will be selected from the addresses of the peer end. The data is usually sent to the main address.



2-33

SCTP will try to send acknowledgement messages to the source address of the data validated. If one acknowledgement message validates multiple data chunks, the corresponding relation cannot be guaranteed.

When a data chunk is retransmitted, if possible, a destination address different from that of transmitting will be chosen.

IV. Congestion Control

SCTP has a congestion control mechanism similar to that of TCP. Generally speaking, it can be divided into the following parts

1) Slow-start

Slow-start means when SCTP begins to (or after long-duration idle time) transmit data to the network, a slow mode is adopted due to the unknown ability of the network. Actually, the original CWND of the destination address is set to a very small value (no bigger than the MTUs of two paths), in order to guarantee the data flow sent by SCTP is in small amount. Meanwhile, a relatively bigger threshold is set for the slow-start. Before CWND reaches the slow-start threshold, slow-start algorithm is adopted for its increment. Normally, the CWND will be gradually increased to make full use of the bandwidth of the network. Hereby, it can guarantee that the SCTP transmits data to the network at relatively low amount in a long time.

For an idle address, after a certain period, the CWND will be reduced by half to 2 times of the path’s MTU. Then it can guarantee that the CWND of the address idled for a certain time is very small, therefore, the slow-start is achieved.

In fact, slow-start describes the changing rule when the CWND is started to reach the slow-start threshold.

2) Congestion avoidance

Since CWND is increasing gradually, it will reach the slow-start threshold at last. The actions after the slow-start threshold is reached are described by the congestion avoidance mechanism. Simply speaking, after each loopback period, CWND will increase by one MTU.

3) Congestion control

CWND cannot increase unlimitedly. In case of huge amount traffic, congestion will occur. Congestion control is used to solve this problem. When there are gaps in the SACKs sent by the peer end, or T3 timer times out, the CWND of this address will be decreased greatly. For the gap in SACK, CWND will be reduced by half. For timeout, CWND will be reduced to the MTU of one path, to guarantee that only a data chunk with the size of one MTU is sent and un-validated on this address until the validation from the peer end is received. Slow-start mechanism is adopted to increase the CWND.

4) Fast retransmit



2-34

Fast retransmit means that when the SACK received by the sender shows that there is a gap in the received sequence, the sender will label the data chunks in the gap as “retransmit”, after three continuous SACKS are received to confirm that the gap exists. Meanwhile, the congestion control rule will be used to adjust CWND.

Except fast-retransmit, the other three congestion control mechanisms are used to describe the change of CWND. Congestion control is traffic control, which is implemented through windows in SCTP. Therefore, to control congestion is to control CWND.

V. Path Management

In the following part, the management of the path status and the status of the peer endpoint in an association is described.

1) Management of endpoint status

The management of SCTP endpoint status is to maintain a counter for the peer end, which will count the times of continuous retransmissions to this endpoint. If the peer is multi-homed, it will include the continuous retransmissions of all the addresses. Once the counter reaches the prescribed number, the peer end will be regarded as unreachable. Then, SCTP will change the association into the CLOSED status, and send a report. When a data chunk sent to the peer end is validated, the counter will be reset.

2) Management of path status

Path management of SCTP is performed for each peer address. It means maintaining a counter for each peer address, which records the timeout times of T3 timer and the times the sent heartbeats receive no response. If the counter exceeds the prescribed number, the address will be labeled as “unreachable”. If validations are received from the peer end for the data chunks sent, or validations are received for heartbeats, the counter will be reset.

3) Heartbeat

The heartbeat of SCTP is similar to the MTP2 filler unit of SS7: SCTP sends the heartbeat chunk to a destination address that is idle (a timer determines whether it is idle). Different from MTP2, when the peer end of SCTP receives this heartbeat data chunk, it must send corresponding heartbeat validation message immediately. If the sender has not received this validation, the path error counter will be incremented by 1.



2-35

2.4 MTP2-User Peer-to-Peer Adaptation Layer (M2PA)

2.4.1 Overview

The M2PA protocol is used in the networking in which the SG is used as the signaling transfer point (STP). It is the peer-to-peer adaptation layer of SS7 MTP2, analogs the MTP2 function along with the SCTP layer and supports seamless operation of MTP3 protocol peers over an IP network connection besides providing the “IP SS7 link” to upper layer.

The MT2PA protocol allows for full MTP3 message handling and network management capabilities between an SG and MGC, or between an SG and IP signaling point (IPSP), or between any two IPSPs communicating over an IP network. An SS7 node equipped with an IP network connection is called an IPSP. The IPSPs function as traditional SS7 nodes by using the IP network instead of SS7 links.

The delivery mechanism should

Support seamless operation of MTP3 protocol peers over an IP network connection.

Support the MTP level 2 / MTP level 3 interface boundary. Support management of SCTP transport associations and traffic instead of MTP2

links. Support asynchronous reporting of status changes to management.

2.4.2 M2PA Application

I. M2PA Application in SGP-ASP

Figure 2-25 shows the M2PA application model in the signaling gateway process-application server process (SGP-ASP) mode. An IPSP may have the signaling connection control part (SCCP) and other SS7 layers above MTP3, and the SG is an IPSP equipped with both the traditional SS7 link and the IP association.



2-36

SG IPSPIP

MTP3

M2PASCTP

IP

SEP

MTP3-User

MTP3

MTP2

MTP1

MTP3

MTP2

MTP1 IP

MTP3-User

M2PASCTP

No.7

SEP: SS7 Signaling end point

Figure 2-25 M2PA in the IP SG

II. M2PA Application in IPSP-IPSP

In the IP network, the SCN signaling transmission architecture consists of many parts, including IP transfer protocol, SCTP and one adaptation model. Figure 2-26 shows the M2PA application in the IPSP-IPSP model, implementing the interconnection between MTP3 in two IPSPs. MTP3 is adapted to the SCTP layer by using the M2PA. All the primitives between MTP3 and MTP2 are supported. The SCTP association acts as one SS7 link between IPSPs.

IPSP IPSP

IP

MTP3

M2PA

SCTP

IP

MTP3

M2PA

SCTP

IP

Figure 2-26 M2PA symmetrical peer-to-peer architecture



2-37

2.4.3 Services Provided by M2PA

I. Support for MTP Level 2 / MTP Level 3 Interface Boundary

The SS7 MTP3 / MTP2 (MTP2-User) interface is reserved in the IPSP, so, the P2PA should be able to provide the same services as those provided by MTP2 to MTP3.

II. Support for Peer-to-peer Communication

In SS7, MTP level 2 sends three types of messages, known as signal units: Message signal units (MSUs), link status signal units (LSSUs), and fill-in signal units (FISUs). MSUs originate at a higher level than MTP2, and are destined for a peer at another node. Likewise, M2PA passes these messages from MTP3 to SCTP as data for transport across a link. LSSUs allow peer MTP2 layers to exchange status information. The link status of M2PA is similar to LSSU, which is sent when no signaling unit is waiting for sending. The heartbeat servers the purpose in the M2PA. The message reply may be contained in FISU, which is the function of M2PA user data and link status. Therefore, no signal unit as FISU is to be provided by the M2PA. In addition, because the resources in IP network are shared, signal unit as FISU is not needed.

2.4.4 M2PA Message Format

I. M2PA Message

The M2PA message consists of common message header, specific-M2PA header and message data. The format of M2PA message is as shown in Figure 2-27.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Common message header

M2PA-specific header

Message data

：

Figure 2-27 M2PA message

The three parts will be described in detail below.

Common message header

The common message header structure contains a version, message class, message type, and message length. The header structure is shown in Figure 2-28.



2-38

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Version Spare Message classMessage type

Message length

0 1 2 3

Figure 2-28 Common message header

Version

The version field contains the version of M2PA.The supported versions are:

Value Version

1 Release 1.0 of M2PA protocol

Spare

The spare field should be set to all zeroes (0s) by the sender and ignored by the receiver. The spare field should not be used for proprietary information.

Message Class

The following list contains the valid message classes:

Value (decimal) Message Class

11 M2PA Messages

Other values are invalid for M2PA.

Message Type

The following list contains the message types for the defined messages.

Value Message Type

----- ------------

1 User Data

2 Link Status

Other values are invalid.

Message Length

The message length defines the length of the message in octets, including the common header.

M2PA Header

All protocol messages for M2PA require an M2PA-specific header. The header structure is shown in Figure 2-29.



2-39

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Not used

0 1 2 3

Not used

FSN

BSN

Figure 2-29 M2PA-specific Message Header

Backward Sequence Number (BSN): This is the FSN of the message last received from the peer.

Forward Sequence Number (FSN): This is the M2PA sequence number of the user data message being sent.

Message data

M2PA message: It has two types: user data message and link status information. Now we shall describe them.

User data

The user data is sent from MTP3, and it consists of LI, SIO and SIF in MSU. Note that the data field shall not contain other components of the MTP MSU format, such as Flag, BSN, BIB, FSN, FIB and CK. Two undefined bits between SIO and LI fields are set to zeroes. LI field (6 bits) is all set to zeroes (spare). M2PA does not add padding to the MTP3 message. The user data message structure is shown in Figure 2-30.

SIF SIO 00 LI

6288n(n 2)

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

User data

Figure 2-30 User data message

Link Status

The MTP2 link status message can be sent between M2PA peers to indicate link status. This message performs a function similar to the link status signal unit in MTP2.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Status

Figure 2-31 Link status

The valid values for State are shown in the following table.



2-40

Value (decimal) Description

1 Alignment

2 Proving Normal

3 Proving Emergency

4 Ready

5 Processor Outage

6 Processor Outage Ended

7 Busy

8 Busy Ended

9 Out of Service

10 In Service

II. Extended Changeover Order (XCO) and Extended Changeover Acknowledgement (XCA)

The M2PA sequence numbers (FSN/BSN) are 24 bits long, which are implemented through the XCO and XCA. These messages have 24 bits sequence number fields. Its format is shown in Figure 2-32.

M2PA sequence number

D C B A

H1

0001

H0 Label

24 4 4 56 First bit transmitted

When H1 is 0011, the message is XCO, when it is 0100, XCA.

Figure 2-32 XCO and XCA

2.4.5 Functions Provided by M2PA

I. Support of MTP3/MTP2 Primitives

M2PA receives the primitives sent from MTP3 to its lower layer. M2PA processes these primitives or maps them to appropriate primitives at the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like those used in the MTP3/MTP2 interface.



2-41

II. MTP2 Functionality

M2PA provides MTP2 functionality that is not provided by SCTP. This includes

Data retrieval to support the MTP3 changeover procedure Reporting of link status changes to MTP3 Processor outage procedure Link alignment procedure

III. Mapping of SS7 and IP Entities

The M2PA layer must maintain a map of each of its SS7 links to the corresponding SCTP association.

IV. SCTP Stream Management

SCTP allows a customized number of streams to be opened during the initialization. It is the responsibility of the M2PA layer to ensure proper management of the streams allowed within each association.

M2PA uses two streams in each direction for each association. Stream 0 in each direction is designated for link status messages. Stream 1 is designated for user data messages. Separating the link status and user data messages onto separate streams allows M2PA to prioritize the messages in a manner similar to MTP2.

V. Retention of MTP3 in the SS7 Network

M2PA allows MTP3 to perform all of its message handling and network management functions with IPSPs as with other SS7 nodes.

2.4.6 Implementation Procedure of Basic Functions

I. M2PA Link State Control

The M2PA link moves from one state to another in response to various events. The events that may result in a change of state include:

MTP3 primitive requests SCTP notifications Receipt of Status messages from the peer M2PA Expiration of certain timers

Following is a list of the M2Pa link states and a description of each.

IDLE: State of the link during power-up initialization. OOS: Out Of Service. Power-up initialization is complete. AIP: Alignment In Progress. M2PA is attempting to exchange alignment messages

with its peer.



2-42

PROVING: M2PA is sending link status proving messages to its peer. ALIGNED READY: Proving is complete. M2PA is waiting until peer completes

proving. INS: In Service. Link is ready for traffic. RETRIEVAL: Link no longer carries traffic. M2PA is waiting for request for

message retrieval from MTP3.

Figure 2-33 illustrates state changes in the SCTP association together with the causing events. Note that some of the error conditions are not shown in the state diagram. When START is received in the RETRIEVAL status, the association will enter AIP if it has been established; otherwise, it will enter OOS.

IDLE

Power on

OOS

AIP

PROVING

ALIGNEDREADY

INS

RETRIVAL

Link Configured

(Associate)

MTP3 start

MTP3 stop or T1 expiry

SCTP Comm Error

or SCTP Comm Lost

Receive LS Alignment OR LS Proving

(Associate)

MTP3 Stop OR Receive LS OOS

MTP3 Stop OR T3 ExpiryOR Receive LS OOS

Receive LS Ready

OR Receive User Data

MTP3 Stop

OR Receive LS OOS

OR SCTP Comm Error

OR SCTP Comm Lost

OR T6 Expiry

M2PA link faulty

Retrieval completeOR MTP3 Start

SCTP Comm Error

or SCTP Comm Lost

SCTP Comm Error

or SCTP Comm Lost

Figure 2-33 M2PA Link State Transition Diagram



2-43

Following is a list of the M2PA association states and a description of each.

IDLE - State of the association during power-up initialization. ASSOCIATE - M2PA is attempting to establish an SCTP association ESTABLISHED - SCTP association is established.

Figure 2-34 illustrates state changes in the M2PA management of the SCTP association together with the causing events. Note that some of the error conditions are not shown in the state diagram.

IDLE

ASSOCIATE

ESTABLISHED

Associate (Issue SCTP associate) (Issue SCTP

associate)

SCTP Comm Error

SCTP Comm Up

SCTP Comm ErrorOR SCTP Comm Lost

Figure 2-34 M2PA association transition diagram

II. Procedures to Support MTP2 Features

1) Signal Unit Format, Delimitation, Acceptance

SCTP provides reliable, in-sequence delivery. Therefore the related functionality of MTP2 is not needed. SCTP does not provide functions related to link state control in MTP2. These functions must be provided by M2PA.

2) Adaptation between SCTP and MTP3

Each MTP link corresponds to an SCTP association. To prevent duplicate associations from being established, it is recommended that each endpoint know the IP address and port number of both endpoints. SCTP prevents two associations with the same IP address and port number from being established.

It is necessary for at least one of the endpoints to be listening on the port on which the other endpoint is trying to establish the association. Therefore, at least one of the port numbers should be the M2PA registered port. However, M2PA does not do any processing based on SLC.



2-44

Following are examples of the relationships between associations and links. Note that a link is an SCTP association identified by two endpoints. Each endpoint is identified by an IP address and port number. Each association is mapped to an SLC.

Association and link – two IPSPs, each with two IP addresses

Figure 2-35 shows a case with two IPSPs, each with two IP addresses. Two associations are the links that connect two IPSPs. Since these links are in the same link set, they must have different SLCs.

IPSP X IPSP Y

IPAport= PW SLC= a

IPCport= PW SLC= b

IPBport= PWSLC= a

IPDport= PWSLC= b

SCTP Association 1

SCTP Association 2

IPx = IP address

PW = M2PA registered port number

Figure 2-35 Associations and links - two IPSPs with two IP addresses each

Table 2-2 shows the relationships in tabular form. Table 2-1 is only conceptual. The actual method for mapping the SCTP associations to the SLCs is implementation dependent.

Table 2-2 Associations and links - two IPSPs with two IP addresses each

IPSPX IPSPY Association

IP address Port IP address Port SLC

1 IPA PW IPB PW a

2 IPC PW IPD PW b

Associations and links – one IPSP connected to two IPSPs

Figure 2-36 and Table 2-3 show an example with three IPSPs.



2-45

IPSP X

IPAport= PW SLC= a

IPCport= PW SLC= b

IPSP Y

IPBport= PWSLC= a

SCTP Association 1

SCTP Association 2

IPSP Z

IPDport= PWSLC= b

IPx = IP address

PW = M2PA registered port number

Figure 2-36 Associations and links - one IPSP connected to two IPSPs

Note that in this example, the two links are in different link sets. Therefore, it is possible that the values a and b may be equal.

Table 2-3 Associations and SLCs - two IPSPs with two IP addresses each


IP address Port IP address Port

SLC

1 IPA PW IPB PW a

IPSPX IPSPZ Association

IP address Port IP address Port

SLC

2 IPC PW IPD PW b



2-46

Associations and SLCs -multiple Associations between two IP addresses

Figure 2-37 and Table 2-4 show two associations between the same IP addresses. This is accomplished by using different port numbers for each association at one endpoint.

IPSP X IPSP Y

IPAport= P1 SLC= a

IPAport= PW SLC= b

IPBport= PWSLC= a

IPBport= PWSLC= b

SCTP Association 1

SCTP Association 2

IPx = IP address

P1 = Pre-selected port number

PW = Registered port number for M2PA

Figure 2-37 Associations and SLCs -multiple associations between two IP addresses

Table 2-4 Associations and SLCs -multiple associations between two IP addresses


IP address Port IP address Port SLC

1 IPA P1 IPB PW a

2 IPA PW IPB PW b

The association shall contain two streams in each direction. Stream 0 is designated for link status messages. Stream 1 is designated for user data messages.

3) Link alignment

The purposes of the alignment procedure are:

To provide a handshaking procedure so that both endpoints are prepared to send SS7 traffic, and to prevent traffic from being sent before the other end is ready.

Verify that the SCTP association is suitable for use as an SS7 link. Optionally, to overcome the SCTP slow start period.

Link alignment procedure:



2-47

Link alignment takes place after the association is established. If SCTP fails to establish the association, and M2PA has received a Start request from its MTP3, then M2PA shall report to MTP3 that the link is out of service.

After the association is established, M2PA shall send a link status out of service message to its peer.

Once the association is established and M2PA has received a Start request from MTP3, M2PA sends the link status alignment message to its peer. If M2PA has not already received the link status alignment message from its peer, then M2PA starts timer T1.

Note that if the remote M2PA has not received a Start request from its MTP3, it will not send the link status alignment message to the local M2PA. Eventually timer T1 in the local M2PA will expire.

M2PA stops timer T1 when it has received the link status alignment message from its peer.

If timer T1 expires, then M2PA reports to MTP3 that the link is out of service. M2PA sends a link status out of service message to its peer. M2PA should leave the association established. M2PA waits for MTP3 to initiate the alignment procedure again.

Note: Between the time M2PA sends the link status alignment message to its peer and receives the link status alignment message from its peer, M2PA may receive the link status out of service message from its peer. This message is ignored. After the receiving of the link status alignment message from the peer, the receiving of the link status out of service message causes M2PA to send the out of service message to MTP3 and return to the out of service state.

When M2PA has both sent and received the link status alignment message, it has completed alignment and moves to the proving state.

M2PA starts the proving period timer T2. During the proving period, M2PA sends link status proving messages to its peer at an interval defined by the protocol parameter Proving_Rate. M2PA sends either the proving normal or proving emergency message, according to the emergency and emergency ceases commands from MTP3. M2PA uses the value of T2 corresponding to the normal or emergency state. However, if M2PA receives a link status proving emergency message from its peer, then m2pa shall initiate the emergency proving period value for T2, but it shall continue to send the proving message (normal or emergency) determined by its own upper layer MTP3.

When the proving period timer T2 expires, M2PA shall start timer T3 and send link status ready messages to its peer at interval Status_Interval. These messages are used to verify that both ends have completed proving.



2-48

M2PA shall stop timer T3 when it receives a link status ready or user data message from its peer. If timer T3 expires, then M2PA reports to MTP3 that the link is out of service. M2PA sends a link status out of service message to its peer. M2PA should leave the association established. M2PA waits for MTP3 to initiate the alignment procedure again. Note that if M2PA has already received a link status ready message from its peer when its timer T2 expires, there is no need to start timer T3. M2PA can just send the link status ready messages to the peer and continue along.

When all of the following are true:

M2PA has received a Start request from MTP3. M2PA's proving period T2 has expired. M2PA has sent a link status ready message to its peer. M2PA has received a link status ready or user data message from its peer. M2PA has not received a link status out of service message from its peer since it

received a link status alignment message.

Then M2PA shall send a link in service message to its MTP3.

If there is a local processor outage condition during the alignment procedure, M2PA sends a link status processor outage message to its peer. When the local processor outage condition ends, then M2PA shall send a link status processor outage ended message to its peer. M2PA shall attempt to complete the alignment procedure during the local processor outage condition.

If M2PA receives a link status processor outage message during alignment, and M2PA had received a Start request from its MTP3, M2PA shall report a remote processor outage message to MTP3. M2PA shall attempt to complete the alignment procedure during the remote processor outage condition.

If M2PA receives a stop command from its MTP3 during alignment, M2PA shall send a link status out of service message to its peer and terminate the alignment procedure.

Recommended values:

T1 Alignment - Range: 1-60 seconds Default: 10 seconds

T2 Proving -

Normal - Range: 1-60 seconds Default: 10 seconds

Emergency - Range: 400-600 milliseconds Default: 500 milliseconds

T3 Ready - Range: 1-60 seconds Default: 10 seconds

Status_Interval - implementation dependent.

Proving_Rate - implementation dependent.

4) Processor outage



2-49

A processor outage occurs when M2PA cannot transfer messages because of the higher layer of M2PA. When M2PA detects a local processor outage, it sends a link status message to its peer with status processor outage. M2PA shall also cease sending user data messages to SCTP for transmission. M2PA shall stop receiving incoming messages from SCTP. M2PA should periodically send a link status processor outage message as long as there is a local processor outage and the link is in service. If the link is out of service, M2PA should locally mark that it is in local processor outage. The peer M2PA, upon receiving the link status processor outage message, shall report the remote processor outage message to its MTP3. The peer M2PA ceases sending user data messages. M2PA stops the remote congestion timer T6 if it is running. See Level 2 Flow Control.

MTP3 may send a Flush Buffers or Continue command to M2PA as part of its processor outage procedure. Alternatively, MTP3 may perform data retrieval as part of a changeover procedure.

When the processor outage ceases, MTP3 sends a local processor recovered indication to M2PA. The local M2PA notifies its peer by sending a link status message with the status of processor outage ended. The peer uses the remote processor recovered indication to notify its MTP3 that the remote processor outage condition has ceased.

5) Level 2 flow control

If M2PA determines that it is in receiving congestion for an association, M2PA shall send a link status busy message to its peer on that association. M2PA shall continue to acknowledge incoming messages. M2PA should periodically send a link status busy message as long as it is in receiving congestion.

M2PA shall continue transmitting messages while it is in receive congestion.

When the peer M2PA receives the link status busy message, it shall start the remote congestion timer T6. If timer T6 expires, M2PA shall take the link out of service. M2PA sends the link status OOS message and moves to the retrieval state.

The peer M2PA shall cease transmitting messages to SCTP while its T6 timer is running, for example, the other end is busy.

If M2PA is no longer in receiving congestion for the association, M2PA shall send a link status busy ended message to its peer on that association.

When the peer M2PA receives the link status busy ended message, it shall stop timer T6.

Recommended value of T6 is 1–6 seconds.

6) Error monitoring



2-50

If M2PA loses the SCTP association for a link, M2PA shall report to MTP3 that the link is out of service.

7) Transmission and reception priorities

In MTP, link status messages have priority over user data messages. To achieve this in M2PA, M2PA shall send link status and user data messages on separate streams in its SCTP association. All messages are sent using the ordered delivery option.

M2PA should give higher priority to link status messages than to user data messages when sending messages to SCTP.

M2PA should give higher priority to reading the link status stream over the user data stream.

M2PA should give higher priority to receiving notifications from SCTP over reading either the link status stream or the user data stream.

III. Procedures to Support the MTP3/MTP2 Interface

1) Sending/receiving messages

When MTP3 sends a message for transmission to M2PA, M2PA passes the corresponding M2PA message to SCTP using the SEND primitive.

M2PA link status messages are passed to SCTP using the SEND primitive.

Link status and user data messages shall be sent through SCTP on separate streams.

When M2PA receives a user data message from SCTP, M2PA passes the message to MTP3.

If M2PA receives a message from SCTP with an invalid message class or unsupported message type in the common message header, M2PA shall discard the message.

The first user data message sent after the link is placed in services given a forward sequence number (FSN) of 1.

The FSN of the header is incremented by 1 for each user data message sent. When the FSN reaches the maximum value, the next FSN is 0.

For message types other than user data, the forward sequence number is set to the FSN of the last user data message sent.

The backward sequence number is set to the FSN of the last user data message M2PA received from its peer. This serves as an M2PA-level acknowledgement of the message. After the link is placed in service and before a user data message has been received, the BSN is set to 0.



2-51

When M2PA receives a message with BSN equal to 'n', it may remove all messages with FSN <= n from its queue. If M2PA receives a user data message with an FSN that is out of order, the message should be discarded.

M2PA may send acknowledgement of a received message in an outgoing user data or link status message.

When there are messages to be acknowledged, but no user data or link status message to be sent, M2PA may send the link status in service message. The sending interval should be greater than the value of lower layer SCTP retransmission timer. It is suggested to set the value greater than 1.

Note that since SCTP provides reliable delivery and ordered delivery within the stream, M2PA does not need to perform retransmissions.

2) Link activation and restoration

When MTP3 requests that M2PA activate or restore a link by a Start request, M2PA shall follow the alignment procedure described above.

3) Link deactivation

When MTP3 requests that M2PA deactivate a link by a Stop command, M2PA shall send a link status out of service message to its peer. The peer M2PA, upon receiving the link status out of service message, shall notify its upper layer MTP3 that the link is out of service.

4) flush buffers, continue

The Flush Buffers and Continue commands allow M2PA to resume normal operations such as transmission of messages to SCTP and receiving messages from SCTP after a processor outage (local and/or remote) ceases.

If M2PA receives a Flush Buffers command from MTP3, M2PA:

Shall not transmit any messages to SCTP that are currently waiting to be transmitted to SCTP. These messages shall be discarded.

Shall discard all messages currently waiting to be passed to MTP3.

If M2PA receives either a Flush Buffers or a Continue command from MTP3, and the processor outage condition ceases, M2PA shall resume receiving and transmitting messages.

5) MTP3 signaling link congestion

M2PA should receive the notification of SCTP transmission buffer congestion, but how the notification is carried out is implementation dependent.

M2PA shall use the congestion indication primitive to notify its upper layer MTP3 of changes in the signaling link congestion status when it receives the SCTP congestion notification.

6) Changeover



2-52

The objective of the changeover is to ensure that signaling traffic carried by the unavailable signaling link is diverted to the alternative signaling link(s) as quickly as possible to avoid message loss, duplication, or wrong sequencing.

For this purpose, the changeover procedure includes data retrieval, which is performed before opening the alternative signaling links to the diverted traffic. Data retrieval consists of these steps:

Buffer updating, that is, identifying all those user data messages in the retransmission buffer of the unavailable signaling link which have not been received by the far end M2PA, as well as not transmitted messages, and

Transferring those messages to the transmission buffers of the alternate links.

Note that only user data messages are retrieved and transmitted over the alternate links. Link status messages shall not be retrieved and transmitted over the alternate links.

For data retrieval, MTP3 requests the backward sequence number to be transmitted (BSNT) from M2PA through the retrieve BSNT request. M2PA determines the FSN of the last user data message received from the peer. This value is the BSNT. M2PA sends the BSNT value to MTP3 in the BSNT confirmation. In the same way, the remote end also detects its BSNT. The MTP3 layers exchange BSNT values through XCO and XCA messages. The BSNT received from the other end is called the FSNC. When MTP3 receives the FSNC from the other end, MTP3 retrieves all the unsent and unacknowledged messages starting with sequence number (FSNC + 1). This is accomplished through a retrieval request and FSNC request. After all the messages are sent from M2PA to MTP3, M2PA sends a retrieval complete indication to MTP3.

If there are any messages on the M2PA or SCTP receive queues that have not been acknowledged by M2PA, M2PA SHOULD, discard these messages. The peer will retransmit them on an alternate link. Any messages acknowledged by M2PA must not be discarded. These messages must be delivered to MTP3.

If M2PA receives a retrieve BSNT request from MTP3, M2PA shall respond with the BSNT confirmation. The BSNT value is the FSN of the last user data message received from the peer.

If M2PA receives a retrieval request and FSNC request from MTP3, M2PA shall retrieve from its buffers in order and deliver to MTP3:

Any transmitted user data messages beginning with the first unacknowledged message with FSN is greater than FSNC.

Any non-transmitted user data messages exist.

Then M2PA shall send the retrieval complete indication to MTP3.

For emergency changeover, MTP3 retrieves only the unsent messages for transmission on the alternate link(s).



2-53

The changeover procedure makes it problematic for M2PA to have multiple user data streams in one direction for a link. Buffer updating would have to be done for each user data stream separately to avoid duplication or loss of messages. But MTP3 provides for only one XCO/XCA message for sending the last-received sequence number.

2.5 M3UA

2.5.1 Overview

As SS7 MTP3-User adaptation layer, M3UA provides primitive communication service for MTP3 users over IP network and MTP3 (in a signaling gateway) at the edge of a network, so as to implement interworking between TDM SS7 and IP.

2.5.2 Concept of M3UA

I. Application Server (AS)

A logical entity represents certain resources and serves a specific “routing key”. An example of an application server is a virtual switch element handling all call processing for a unique range of PSTN trunks, identified by a routing key “DPC/OPC/CICm~n”. Another example is a virtual database element, handling all HLR transactions for a particular “DPC/OPC/SCCP_SSN” combination. Each AS contains a set of application server processes (ASP), of which one or more is normally actively processing traffic.

II. Application Server Process (ASP)

It specifies a process instance of an application server, such as softswitch equipment over which a certain AS service is borne. One ASP corresponds to one SCTP endpoint. Messages of ASs convey signaling by means of the association between the ASP and the SG.

III. IP Server Process (IPSP)

It specifies a process instance of an IP-based application. An IPSP is essentially the same as an ASP, except that it uses M3UA in a point-to-point fashion instead of using the services of a signaling gateway.

IV. Signaling Gateway Process (SGP)

It specifies a processing instance of a signaling gateway. It serves as an active, backup or load-sharing process of a signaling gateway.



2-54

V. Routing Key

A routing key describes a set of SS7 parameters and parameter values (such as DPC, SIO+DPC, SIO+DPC+OPC and SIO+DPC+OPC+CIC) that uniquely define the range of signaling traffic to be handled by a particular application server. Parameters within the routing key cannot extend across more than a single destination point code.

VI. Routing Context

A 32-bit value uniquely identifies a routing key.

VII. Signaling Point Management Cluster (SPMC)

The complete set of application servers that belong to the same signaling point (SP), used to describe the status of an SP.

2.5.3 Architecture of M3UA protocol

Figure 2-38 shows the architecture of the M3UA protocol.

MTP3-user

M3UA

SCTP

IP

LM

Figure 2-38 Architecture of M3UA protocol

From Figure 2-38 we can see M3UA is the lower-layer protocol of MTP3-User. It provides a standard MTP3 interface for MTP3-User. SCTP is the lower-layer protocol of M3UA and provides an association to serve M3UA. M3UA has also unique layer management (LM) to provide management services.

2.5.4 Applications of M3UA

I. M3UA Application in SGP-ASP Mode

At SGP, a standard SS7 signaling network interface is expected for the transmitting and receiving of SS7 MTP3 user signaling, and MTP3 and STP or SEP are used to provide reliable transport of MTP3 user signaling messages. The SGP provides a nodal interworking function (NIF) between SS7 and IP, which allows the IP-based node to exchange SS7 signaling messages with the SS7-based SEP. The NIF within the SGP serves as the interface within the SGP between the MTP3 and M3UA. This nodal interworking function not only provides network status information to both sides of the



2-55

network, but also provides necessary protocol information and management information about SS7.

Figure 2-39 shows the application model of M3UA in SGP-ASP mode.

SS7 IPSEP MGCSG

NIF

M3UA

SCTP

IP

SCTP

M3UA

IPMTP1

MTP2

MTP3

NIFMTP User

MTP3

MTP2

MTP1

Figure 2-39 M3UA in IP signaling gateway

II. M3UA Application in IPSP-IPSP Mode

Figure 2-40 shows the application model of M3UA in IPSP-IPSP mode.

IPMGC MGC

User

M3UA

SCTP

IP

User

M3UA

SCTP

IP

Figure 2-40 M3UA in IPSP-IPSP mode

2.5.5 Services Provided by M3UA

I. Support for the Transport of MTP3-user Messages

The M3UA layer provides the transport of MTP-TRANSFER primitives across an established SCTP association between an SGP and an ASP or between IPSPs.

At an ASP, in case where a destination is reachable through multiple SGPs, the M3UA layer must choose through which SGP the message is to be routed or support load balancing across the SGPs, ensuring that no mis-sequencing occurs.

The M3UA layer does not impose a 272-octet signaling information field (SIF) length limit. Larger information blocks can be accommodated directly by M3UA/SCTP, without



2-56

the need for an upper layer segmentation/re-assembly procedure. However, the maximum 272-octet block size must be followed when SG interworks to an SS7 network. If the SS7 network is provisioned to support the broadband MTP, the information block size limit may be increased past 272 octets.

II. Native Management Functions

The M3UA layer provides the capability to indicate errors associated with received M3UA messages and to notify, as appropriate, local management and/or the peer M3UA.

III. Interworking with MTP3 Network Management Functions

At the SGP, the M3UA layer must also provide interworking with MTP3 management functions to support seamless operation of signaling applications in the SS7 and IP domains. This includes:

Providing an indication to MTP3-Users at an ASP that a remote destination in the SS7 network is not reachable.

Providing an indication to MTP3-Users at an ASP that a remote destination in the SS7 network is now reachable.

Providing an indication to MTP3-Users at an ASP that messages to a remote MTP3-User peer in the SS7 network are experiencing congestion.

Providing an indication to MTP3-Users at an ASP that a remote MTP3-User peer is unavailable.

The M3UA layer at an ASP saves the route state at remote SS7 destinations. The route state may initiate an audit of the availability or the congested state of remote SS7 destinations. This information is requested form the M3UA layer at the SGP.

The M3UA layer at an ASP may also indicate to the SG that the M3UA layer itself or the ASP or the ASP’s host is congested.

IV. Support for the Management of SCTP Associations Between the SGP and ASPs

The M3UA layer at the SGP maintains the availability state of all configured remote ASPs, in order to manage the SCTP associations and the traffic between the M3UA peers. As well, the active/inactive and congestion state of remote ASPs is maintained.

The M3UA layer may be instructed by local management to establish an SCTP association to a peer M3UA node. In order to avoid redundant SCTP associations between two M3UA peers, one side (client) should be designated to establish the SCTP association, or the M3UA configuration knowledge maintained to detect redundant associations, such as through the knowledge of the expected local and remote SCTP endpoint addresses).



2-57

Local management may request from the M3UA layer the status of the underlying SCTP associations. Also, the M3UA may inform local management of the reason for the release of an SCTP association, determined either within the M3UA layer or by a primitive from the SCTP.

Also the M3UA layer may inform the local management of the change in status of an ASP or AS.

V. Support for the Management of Connections to Multiple SGPs

As we know, an ASP may be connected to multiple SGPs. In such a case a particular SS7 destination may be reachable through more than one SGP and/or SG, that is, through more than one route. As MTP3 users only maintain status on a destination and not on a route basis, the M3UA layer must maintain the status (availability and congestion of route to destination) of the individual routes, derive the overall availability or congestion status of the destination from the status of the individual routes, and inform the MTP3 users of this derived status whenever it changes.

2.5.6 M3UA Protocol Unit

I. M3UA Message Format

The general M3UA message format includes a common message header followed by zero or more parameters as defined by the message type. For forward compatibility, all message types may have attached parameters.

1) Common message header

The protocol messages for MTP3-User adaptation require containing the version, message type, message length and message content, as shown in Figure 2-41. The message header is common for all signaling protocol adaptation layer messages.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Version Spare Message classMessage type

Message length

0 1 2

3

Figure 2-41 Common message header

M3UA protocol version

The version field contains the version of the M3UA adaptation layer. The supported version is:

Value: 00000001;

Version: Release 1.0 protocol.



2-58

Message classes and types

Table 2-5 lists the message classes defined by M3UA. Table 2-6, Table 2-7, 0, Table 2-9, Table 2-10 and Table 2-11 list the message types defined by M3UA.

Table 2-5 M3UA message type

Message class Message class code (hexadecimal)

Management (MGMT) message 00

Transfer messages 01

SS7 signaling network management (SSNM) messages 02

ASP state maintenance (ASPSM) messages 03

ASP traffic maintenance (ASPTM) messages 04

Reserved for other Sigtran adaptation layers 05




Routing key management (RKM) messages 09

Reserved by the Internet Engineering Task Force (IETF) 0A-7F

Reserved for IETF-defined message class extensions 80-FF

Table 2-6 M3UA management (MGMT) message types

Message type Message type code (hexadecimal)

Error (ERR) 00

Notify (NTFY) 01

Reserved by the IETF 02-7F

Reserved for IETF-defined MGMT extensions 80-FF

Table 2-7 M3UA transfer message types


Reserved 00



2-59


Data (DATA) 01


Reserved for IETF-defined transfer extensions 80-FF

Table 2-8 M3UA signaling network management (SSNM) message types


Reserved 00

Destination unavailable (DUNA) 01

Destination available (DAVA) 02

Destination state audit (DAUD) 03

SS7 network congestion (SCON) 04

Destination user part unavailable (DUPU) 05

Destination restricted (DRST) (not in use temporarily) 06


Reserved for IETF-defined SSNM extensions 80-FF

Table 2-9 M3UA state maintenance (ASPSM) message types


Reserved 00

ASP up (ASPUP) 01

ASP down (ASPDN) 02

Heartbeat (BEAT) 03

ASP up acknowledgement (ASPUP ACK) 04

ASP down acknowledgement (ASPDN ACK) 05

Heartbeat acknowledgement (BEAT ACK) 06


Reserved for IETF-defined ASPSM extensions 80-FF



2-60

Table 2-10 M3UA traffic maintenance (ASPTM) message types


Reserved 00

ASP active (ASPAC) 01

ASP inactive (ASPIA) 02

ASP active acknowledgement (ASPAC ACK) 03

ASP inactive acknowledgement (ASPIA ACK) 04


Reserved for IETF-defined ASPTM extensions 80-FF

Table 2-11 M3UA routing key management (RKM) message types


Reserved 00

Registration request (REG REQ) 01

Registration response (REG RSP) 02

Deregistration request (DEREG REQ) 03

Deregistration response (DEREG RSP) 04


Reserved for IETF-defined RKM extensions 80-FF

Message length

The message length defines the length of the message in octets, including the common header. For messages with a final parameter containing padding, the parameter padding must be included in the message length.

2) Variable-length parameter format

M3UA messages consist of a common header followed by zero or more variable length parameters. Figure 2-42 shows the format of all the parameters contained in a message.



2-61

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Parameter tag Parameter length

Parameter value

Figure 2-42 Variable-length parameter format

When more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver should accept the parameters in any order.

Parameter tag

The tag field is a 16-bit identifier of the type of parameter. It’s value ranges from 0 to 65534. Common parameters used by adaptation layers are in the range from 0x00 to 0x3F. M3UA-specific parameters have tags in the range from 0x0200 to 0x02FF. Table 2-12 lists the common parameter tags defined.

Table 2-12 Common parameter tags

Parameter Parameter tag code (hexadecimal)

Reserved 0x0000

Not used in M3UA 0x0001



INFO string 0x0004


Routing context 0x0006

Diagnostic information 0x0007


Heartbeat data 0x0009

Not used in M3UA 0x000a

Traffic mode type 0x000b

Error code 0x000c

Status 0x000d

Not used in M3UA 0x000e

Not used in M3UA 0x000f



2-62



ASP identifier 0x0011

Affected signaling point code 0x0012

Correlation ID 0x0013

Table 2-13 lists the M3UA specific parameters.

Table 2-13 M3UA specific parameters


Network appearance 0x0200

Reserved 0x0201

Reserved 0x0202

Reserved 0x0203

User/cause 0x0204

Congestion indications 0x0205

Concerned destination 0x0206

Routing key 0x0207

Registration result 0x0208

Deregistration result 0x0209

local_routing key identifier 0x020a

Destination point code 0x020b

Service indicators 0x020c

Reserved 0x020d

Originating point code list 0x020e

Circuit range 0x020f

Protocol data 0x0210

Reserved 0x0211

Registration status 0x0212

Deregistration status 0x0213

Reserved by the IETF 0x0214-0xffff



2-63

Parameter length

The parameter length is 16-bit. The parameter length field contains the size of the parameter in bytes, including the parameter tag, parameter length and parameter value fields. The parameter length does not include any padding bytes.

The length of the parameter value is variable-. The parameter value field contains the actual information to be transferred in the parameter.

The total length of a parameter including tag, parameter length and value fields must be a multiple of four bytes. If the length of the parameter is not a multiple of four bytes, the sender pads the parameter at the end with all zero bytes. The length of the padding is not included in the parameter length field. A sender should not pad with more than three bytes. The receiver must ignore the padding bytes.

II. Data Message (DATA)

A DATA message contains a common message header and zero or more parameters defined by the message type.

The DATA message contains the SS7 MTP3-User protocol data, including the complete MTP3 routing label. The DATA message contains the following parameters:

Network appearance Optional (not in use temporarily)

Routing context Optional

Protocol data Mandatory

Correlation ID Optional

Figure 2-43 shows the parameter format for the data message.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag(0x0200) Length=8

Network appearance


Routing context

Tag (0x00210) Length=8

Protocol data


Correlation Id

Figure 2-43 Data message parameter format

1) Network appearance



2-64

It is a parameter in the message to supplement the network indicator (NI).

In a DATA message, the network appearance implicitly defines the SS7 point code format used, the SS7 network indicator value, and the MTP3/MTP3-User protocol type/variant/version.

For example, two areas belong to the same NI (national master network) while the signaling point formats are different. One area employs the 24-bit signaling point encoding scheme, and the other employs the 14-bit signaling point encoding scheme. In such a case, the network appearance parameter in the message is required.

When the network appearance parameter is present, it must be the first parameter in the message as it defines the format of the protocol data field.

The network appearance parameter is not used in the M3UA protocol specification temporarily.

2) Routing context

The routing context is a 32-bit value. In a message, it represents the routing key.

3) Protocol data

The protocol data parameter contains the original SS7 MTP3 message, including the service information octet and routing label.

The protocol data parameter contains the following fields:

Service indicator (SI) Network indicator (NI) Destination point code (DPC) Originating point code (OPC) Signaling link selection code (SLS)

User protocol data includes MTP-User protocol elements such as ISUP, SCCP or TUP parameters.

Figure 2-44 shows the format of the protocol data parameter.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2

Idle OPC

3

SI

DPC

Protocol data

NI SLS

Idle

Idle

Idle

Idle

Idle Idle

Figure 2-44 Format of protocol data

OPC: 24 bits; DPC: 24 bits;



2-65

NI: 2 bits; SI: 4 bits; SLS: 4 bits; Correlation Id: MSU in an AS to uniquely identify the load in the protocol data.

III. SS7 Signaling Network Management (SSNM) Messages

All M3UA protocol messages (including SSNM messages) contain a common message header and zero or more parameters defined by the message type.

1) Destination unavailable (DUNA:)

The DUNA message is sent from all SGPs in an SG to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are unreachable. It is also sent by an SGP in response to a message from the ASP to an unreachable SS7 destination. The MTP3-User at the ASP is expected to stop traffic to the affected destination in the DUNA message.

The DUNA message contains the following parameters:

Network appearance Optional (not in use temporarily) Routing context Optional Affected destinations Mandatory INFO string Optional

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3


Network appearance

Tag(0x0006) Length

Routing context

Tag(0x0012) Length

Reserved

Reserved

Affected destinations DPC1

Affected destinations DPCn

:

Tag (0x0004) Length

INFO string

Figure 2-45 DUNA message format

The routing context parameter contains the routing context values related to the DUNA message. If multiple routing keys and routing contexts are used for a common association, the routing contexts for the receiver can identify the traffic flow affected by the DUNA and assist in outgoing service management and internal distribution of MTP-PAUSE indication to the MTP3-User.



2-66

The affected destinations parameter contains up to sixteen affected destination point code fields, each 3-octet parameter allowing for 24-bit signaling point code format.

It is optional to send an affected destinations parameter with more than one affected DPCs, but all the affected DPCs included must be within the same network appearance. For example, multiple affected DPCs may be useful when an SG cluster route or a link event simultaneously affects multiple destinations.

The optional INFO string parameter can carry any 8-bit ASCII character string along with the message. Length of the INFO string parameter is from 0 to 255 characters. No procedures are presently identified for its use but the INFO string may be used by operators to identify in text form the location reflected by the affected DPC for debugging purposes.

2) Destination available (DAVA) :

The DAVA message is sent from the SGP to all concerned ASPs to indicate that the SG has determined that one or more SS7 destinations are now reachable, or in response to a DAUD message (refer to the following part). The ASP MTP3-User protocol should resume traffic to the affected destination in the DAVA message.

The DAVA message contains the following parameters:


The format and description of the DAVA message parameters is the same as that of the DUNA message.

3) Destination state audit (DAUD) :

The DAUD message may be sent from the ASP to the SGP to audit the availability/congestion state of SS7 routes to one or more affected destinations.

The DAUD message contains the following parameters:


The format and description of the DAUD message parameters is the same as that of the DUNA message.

The DAUD message may contain multiple affected DPCs parameter, but all affected DPCs must be within the same network appearance.

4) SS7 network congestion (SCON) :SCON



2-67

The SCON message can be sent from the SGP to all concerned ASPs to indicate congestion in the SS7 network to one or more destinations, or to an ASP in response to a DATA or DAUD message as appropriate. The SCON message may also be sent from the M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer or the ASP is congested. The SCON message contains the following parameters:

Network appearance Optional (not in use temporarily) Routing context Optional Affected destinations Mandatory Concerned destination Optional Congestion indications Optional INFO string Optional

Figure 2-46 shows the format for the SCON message parameters.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0200) Length=8

Network appearance

Tag(0x0006) Length

Routing context

Tag (0x0012) Length

Reserved

Reserved

Affected destination DPC1

Affected destination DPCn

:

Tag (0x0206) Length

Reserved Concerned DPC

Tag (0x205) Length

ReservedCongestion indications

Tag(0x0004) Length

INFO string

Figure 2-46 Format of SCON message

The format and description of the network appearance, routing context, affected DPCs and INFO string parameters is the same as that of the DUNA message.

The concerned destination parameter is only used if the SCON message is sent from an ASP to the SGP. It contains the point code of the originator of the message that triggered the SCON message. The concerned destination parameter contains one concerned destination point code field. Any resulting transfer controlled (TFC)



2-68

message from the SG is sent to the concerned point code using the single affected DPC contained in the SCON message.

The congestion indications parameter is used to check if congestion occurs.

5) Destination user part unavailable (DUPU):

The DUPU message is used by an SGP to inform an ASP that a remote peer MTP3-User part at an SS7 node is unavailable. The DUPU message contains the following parameters:

Network appearance Optional (not in use temporarily)

Routing context Optional

Affected destinations Mandatory

User/cause Mandatory

INFO string Optional

The format for DUPU message parameters is as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3


Network appearance

Tag(0x0006) Length

Routing context


Reserved Affected destination DPC


Cause User

Tag(0x0004) Length

INFO string

Figure 2-47 Format of DUPU message

The format and description of the network appearance, routing context, affected DPCs and INFO string parameters is the same as that of the DUNA message except that only a single affected DPC is included in the affected destination parameter in the DUPU message.

User/cause and MTP3-User are associated with the affected DPC.



2-69

The user/cause parameter provides the reason for the unavailability of the MTP3-User. The valid values for the unavailability cause parameter are shown in the following table. The values agree with those provided in the SS7 MTP3 user part unavailable message.

Table 2-14 Valid values for the unavailability cause parameter

Description Value

Unknown 0x0000

Unequipped remote user 0x0001

Inaccessible remote user 0x0002

The MTP3-User identity describes the specific MTP3-User that is unavailable, such as ISUP, SCCP, and so on. The valid values for the MTP3-User identity are shown in Table 2-15. The values align with those provided in the SS7 MTP3 user part unavailable message and service indicator.

Table 2-15 Valid values for the MTP3 user identity

Description Value

Reserved 0x0000 –0x0002

SCCP 0x0003

TUP 0x0004

ISUP 0x0005

Reserved 0x0006 – 0x0008

Broadband ISUP 0x0009

Satellite ISUP 0x000a

Reserved 0x000b

AAL type 2 signaling 0x000c

BICC 0x000d

Gateway control protocol 0x000e

Reserved 0x000f

IV. ASP Management (ASPM) Messages

1) ASP Up message:

The ASP Up message is used to indicate to a remote M3UA peer that the adaptation layer is ready to receive any SSNM or ASPM messages for all routing keys that the ASP is configured to serve.



2-70

The ASP Up message contains the following parameters:

ASP identifier Optional


Figure 2-48 shows the format for the ASP Up message parameters.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0011) Length

ASP identifier

Tag (0x0004) Length

INFO string

Figure 2-48 ASP Up message parameter format

The optional ASP identifier parameter contains a uniquely meaningful value locally between ASPs supporting an AS. The SGP should save the ASP identifier used in the NTFY message.

The format and description of the optional INFO string parameter is the same as that of the DUNA message.

2) ASP Up Ack message:

The ASP Up Ack message is used to acknowledge an ASP Up message received from a remote M3UA peer.

The ASP Up Ack message contains the following parameters:


Figure 2-49 shows the format for the ASP Up Ack message parameters.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag(0x0004) Length

INFO string

Figure 2-49 ASP Up Ack message parameter format


3) ASP Down (ASPDN) message:

The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer that the adaptation layer is not ready to receive DATA, SSNM, RKM or ASPTM messages.

The ASPDN message contains the following parameters:



2-71


Figure 2-50 shows the format for the ASPDN message parameters.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0004) Length

INFO string

Figure 2-50 ASPDN message parameter format


4) ASP Down Ack (ASPDN Ack) message:

The ASP Down Ack message is used to acknowledge an ASP Down message received from a remote M3UA peer, or in response to an ASPM message received by the ASP and locked due to management reasons.

The ASPDN Ack message contains the following parameters:


The format for the ASPDN Ack message parameters is the same as that of the ASPDN message parameters.

5) Heartbeat (BEAT) message:BEAT

The BEAT message is optionally used to ensure that the M3UA peers are still available to each other. It is recommended for use when the M3UA runs over a transport layer other than the SCTP. The BEAT message does not contain any parameter.

Figure 2-51 shows the format for the BEAT message.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0004) Length

Heartbeat data......

Figure 2-51 BEAT message format

The heartbeat data parameter contents are defined by the sending node. The heartbeat data could include, for example, a heartbeat sequence number and/or timestamp. The receiver of a BEAT message does not process this field. The receiver must respond with a BEAT Ack message.

6) Heartbeat acknowledgement (BEAT Ack) message:BEAT Ack



2-72

The BEAT Ack message is sent in response to a received BEAT message. It includes all the parameters of the received BEAT message.

V. M3UA Routing Key Management (RKM) Messages

1) Registration request (REG REQ)

The REG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to register one or more given routing keys with the remote peer. Typically, an ASP would send this message to an SGP, and expect to receive an REG RSP message in return with an associated routing context value.

The REG REQ message contains the following parameters:

Routing key Mandatory

The format for REG REQ message is as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0207) Length

Routing key 1

......

Routing key n

Tag (0x0207) Length

Figure 2-52 REG REQ message format

The sender of this message expects that the receiver of this message will create a routing key entry and assign a unique routing context value to it, if the routing key entry does not already exist.

The routing key parameter may be present multiple times in the same message. This is used to allow the registration of multiple routing keys in a single message.

The format for the routing key parameter is shown in Figure 2-53.



2-73

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Traffic mode type (optional)

Local-RK-identifier

Destination point code

Network appearance (optional)

SI (optional)

Origination point code list (optional)

Circuit range list (optional)

Destination point code (DPC)

SI(optional)

Originating point code (OPC) list (optional)

Circuit range list (optional)

.

.

.

Figure 2-53 Routing key parameter format

The mandatory local-RK-identifier field is used to uniquely identify the registration request. The identifier value is assigned by the ASP, and is used to correlate the response in an REG RSP message with the original registration request. The identifier value must remain unique until the REG RSP message is received.

Local-RK-identifier

Figure 2-54 shows the format of the local-RK-identifier field.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x020a) Length=8

Local RK identifier

Figure 2-54 Local-RK-identifier parameter format

Traffic mode type

Traffic mode type: 32-bit

The traffic mode type parameter is mandatory and identifies the traffic mode of operation of the ASP(s) within an application server. The traffic mode type is shown in Figure 2-55:



2-74

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x020b) Length=8

Traffic mode identifier

Figure 2-55 Traffic mode type parameter format

The valid values for traffic mode type are as follows:

over-ride load-share broadcast

If the receiver of the REG REQ creates a new routing key entry, then the traffic mode type sets the traffic mode for the new application server. If the receiver of the REG REQ determines that a matching routing key already exists, the traffic mode type must match the existing traffic mode for the AS.

Destination point code

The destination point code parameter is mandatory, and identifies the destination point code of incoming SS7 traffic. Its format is shown in Figure 2-56.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x020b) Length=8

Destination Point CodeReserved

Figure 2-56 Destination point code parameter format

Network appearance

The network appearance parameter is not in use temporarily.

Service indicators (SI)

The optional SI field contains one or more service indicators. The absence of the SI parameter in the routing key indicates the use of any SI value, excluding MTP management. Where an SI parameter does not contain a multiple of four Sis, the parameter is padded. The format of SI is shown in Figure 2-57.



2-75

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x020c) Length=variable

SI#1 SI#2 SI#3 SI#4

.....

SI#n 0 padding if necessary

Figure 2-57 SI parameter format

Originating point code

The optional originating point code (OPC) list parameter contains one or more OPC entries, and its format is the same as the destination point code parameter. Its format is as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x020e) Length=variable

Reserved

.....

OPC#1

Reserved OPC#n

Figure 2-58 OPC parameter format

Circuit range list

The circuit range list parameter is optional. A circuit is uniquely identified by the SS7 OPC, DPC and CIC value. For the purposes of identifying circuit ranges in an M3UA routing key, the optional circuit range parameter includes one or more circuit ranges, each identified by an OPC and upper/lower CIC value. The DPC is implicit as it is mandatory and already included in the DPC parameter of the routing key. The OPC is encoded the same as the DPC, while the CIC values are 12-bit integers. Its format is as follows:



2-76

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x020f) Length=8

Reserved OPC#1

Reserved OPC#2

Lower CIC value #1 Upper CIC value #1

Lower CIC value #2 Upper CIC value #2

Reserved OPC#n

Lower CIC vlaue #n Upper CIC value #n

......

Figure 2-59 Circuit range list parameter format

2) Registration response (REG RSP)

The REG RSP message is used as a response to the REG REQ message from a remote M3UA peer. It contains indications of success/failure for registration requests and returns a unique routing context value for successful registration requests for the subsequent M3UA traffic management protocol.

The REG RSP message contains the following parameters:

Registration results

The format for the REG RSP message is shown in Figure 2-60:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0208) Length=variable

......

Registration result 1

Registration result n

Figure 2-60 REG RSP message format

The registration results parameter contains one or more results, each containing the registration status for a single routing key in an REG REQ message. The number of results in a single REG RSP message may match the number of routing key parameters found in the corresponding REG REQ message. The format of each result is shown in Figure 2-61:



2-77

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag=0x020a Length=8

Local-RK-identifier value

Tag=0x0212 Length=8

Registration status

Tag=0x0006 Length=8

Routing context

Figure 2-61 Registration result parameter format

Local-RK-identifier identifies 32-bit integers and contains the same value as that is found in the REG REQ message.

The registration result status field indicates the success or the reason for the failure of a registration request.

Its values may be:

0 Successfully registered

1 Error – unknown

2 Error – invalid DPC

3 Error – invalid network appearance

4 Error – invalid routing key

5 Error – permission denied

6 Error – cannot support unique routing

7 Error – routing key not currently provisioned

8 Error – insufficient resources

9 Error – unsupported RK parameter field

10 Error – unsupported/invalid traffic handling mode

The routing context field contains the routing context value for the associated routing key if the registration was successful. It is set to “0” if the registration was not successful.

3) De-registration request (DEREG REQ)

The DEREG REQ message is sent by an ASP to indicate to a remote M3UA peer that it wishes to de-register a given routing key. Typically, an ASP would send this message to



2-78

an SGP, and expects to receive a DEREG RSP message in return with the associated routing context value.

The DEREG REQ message contains the following parameters:

Routing context

The format for the DEREG REQ message is shown in Figure 2-62:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0006) Length

Routing context......

Figure 2-62 DEREG REQ message format

Routing context is an n X 32-bit parameter. The routing context parameter contains a list of integers indexing the application server traffic.

4) De-registration response (DEREG RSP)

The DEREG RSP message is used as a response to the DEREG REQ message from a remote M3UA peer.

The DEREG RSP message contains the following parameters:

De-registration results

The format for the DEREG RSP message is as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0209) Length

De-registration result 1

Tag (0x0209) Length

De-registration result n

......

Figure 2-63 DEREG RSP message format

The de-registration results parameter contains one or more results, each containing the de-registration status for a single routing context in a DEREG REQ message. The number of results in a single DEREG RSP message may match the number of routing contexts found in the corresponding DEREG REQ message. If multiple DEREG RSP messages are used to respond the DEREG REQ message, only one specific result can be contained in the DEREG RSP message. The format of each result is as follows:



2-79

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag=0x0006 Length=8

Routing context

Tag=0x0213 Length=8

De-registration status

Figure 2-64 De-registration result parameter format

Routing context is a 32-bit integer. The routing context field contains the routing context value of the matching routing key to deregister, as found in the DEREG REQ message.

The de-registration result status field indicates the success or the reason for the failure of the de-registration.

Its values may be:

0 Successfully de-registered

1 Error – unknown

2 Error – invalid routing context

3 Error – permission denied

4 Error – not registered

5 Error – ASP currently active for routing context

VI. ASP Traffic Maintenance (ASPTM) Messages

1) ASP active (ASPAC)

The ASPAC message is sent by an ASP to indicate to a remote M3UA peer that it is ready to process signaling traffic for a particular application server. The ASPAC message affects only the ASP state for the routing keys identified by the routing contexts. The ASPAC message contains the following parameters:

Traffic mode type Optional Routing context Optional INFO string Optional

The format for the ASPAC message is shown in Figure 2-65:



2-80

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x000b) Length

Traffic mode type

Tag (0x0006) Length

Routing context .....

Tag (0x0004) Length

INFO string

Figure 2-65 ASPAC message format

Traffic mode type

The traffic mode type parameter identifies the traffic mode of operation of the ASP within an AS. The valid values for traffic mode type are shown in Table 2-16:

Table 2-16 Valid values for traffic mode type

Value Description

1 Over-ride

2 Load-share

3 Broadcast

For a particular routing context, over-ride and load share, either active or standby, must not be mixed. The over-ride value indicates that the ASP is operating in over-ride mode, and the ASP takes over all traffic in an application server, such as primary/backup operation. In load-share mode, the ASP will share in the traffic distribution with any other currently active ASPs. In broadcast mode, the ASP will receive messages the same as other active ASPs.

Routing context

Routing context is an optional n X 32-bit integer parameter. The routing context parameter contains a list of integers indexing the application server traffic. There is a one-to-one relationship between an index entry and an SGP routing key or AS name.

An application server process may be configured to process traffic for more than one logical application server. From the perspective of an ASP, a routing context defines a range of signaling traffic that the ASP is currently configured to receive from the SGP. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signaling traffic, identified by separate SS7 DPC/OPC/CIC ranges.



2-81

INFO string

The format and description of the optional INFO string parameter is the same as that for the DUNA message.

2) ASP active acknowledgement (ASPAC Ack) A

The ASPAC Ack message is used to acknowledge an ASPAC message received from a remote M3UA peer.

The ASPAC Ack message contains the following parameters:

Traffic mode type Optional Routing context Optional INFO string Optional

The format for the ASPAC Ack message is similar to that for the ASPAC message.

The format for traffic mode type and routing context is the same as the parameter format for the ASPAC message.

The format and description of the optional INFO string parameter is the same as that for the DUNA message.

3) ASP inactive (ASPIA)

The ASPIA message is sent by an ASP to indicate to a remote M3UA peer that it is no longer an active ASP to be used from within a list of ASPs. The ASPIA message affects only the ASP state for the routing keys identified by the routing contexts.

The ASPIA message contains the following parameters:

Routing context Optional INFO string Optional

The format for the ASPIA message parameters is as follows:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x0006) Length

Routing context .....

Tag (0x0004) Length

INFO string

Figure 2-66 ASPIA message format

The format and description of the optional routing context and INFO string parameters is the same as that for the ASPAC message.

4) ASP inactive acknowledgement (ASPIA Ack) A



2-82

The ASPIA Ack message is used to acknowledge an ASPIA message received from a remote M3UA peer.

The ASPIA Ack message contains the following parameters:

Routing context Optional INFO string Optional

The format for the ASPIA Ack message parameters is similar to that for the ASPIA message parameters.

The format and description of the optional routing context and INFO string parameters is the same as that for the ASPAC message.

VII. Management (MGMT) Messages

1) Error (ERR)

The ERR message is used to notify a peer of an error event associated with an incoming message. For example, the unexpected message type might be given the current state, or a parameter value might be invalid. The ERR message contains the following parameters:

Error code Mandatory Routing key Mandatory Network appearance Optional Affected signaling point code Mandatory Diagnostic information Optional

The format for the ERR message is shown in Figure 2-67.



2-83

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x000c) Length=8

Error code

Tag (0x0006) Length

Routing context......

Tag (0x0012) Length

Affected signaling point code 1

......

Affected signaling point code n

Tag (0x0200) Length

Network appearance

Tag (0x0007) Length

Diagnostic information

Figure 2-67 ERR message format

Error code

The error code parameter indicates the reason for the ERR message. The error parameter value can be one of the values in Table 2-17.

Table 2-17 Valid values for error parameter

Value Description

0x01 Invalid version

0x02 Not used in M3UA

0x03 Unsupported message class

0x04 Unsupported message type

0x05 Unsupported/invalid traffic handling mode

0x06 Unexpected message

0x07 Protocol error


0x09 Invalid stream identifier

0x0a Not used in M3UA

0x0b Not used in M3UA

0x0c Not used in M3UA



2-84

Value Description

0x0d Refused – management blocking

0x0e Requiring ASP identifier

0x0f Invalid ASP identifier


0x11 Invalid parameter value

0x12 Parameter field error

0x13 Unexpected parameter

0x14 Unknown destination status

0x15 Invalid network appearance

0x16 Loss of parameter



0x19 Invalid routing context

0x1a Not configuring AS for ASP

The “invalid version” error is sent if a message was received with an invalid or unsupported version. The ERR message contains the supported version in the common header. The ERR message could optionally provide the supported version in the diagnostic information area.

The “unsupported message class” error is sent if a message with an unexpected or unsupported message class is received.

The “unsupported message type” error is sent if a message with an unexpected or unsupported message type is received.

The “unsupported/invalid traffic handling mode” error is sent by an SGP if an ASP sends an ASP active message with an unsupported traffic mode type or a traffic mode type that is inconsistent with the presently configured mode for the application server. An example would be a case in which the SGP did not support load-sharing.

The “unexpected message” error may be sent if a defined and recognized message is received that is not expected in the current state (in some cases the ASP may optionally silently discard the message and not send an ERR message).

The “protocol error” error is sent for any protocol anomaly, for example, reception of a parameter that is syntactically correct but unexpected in the current situation.



2-85

The “invalid stream identifier” error is sent if a message is received on an unexpected SCTP stream. For example, a management message was received on a stream other than “0”.

The “refused – management blocking” error is sent when an ASP-Up or ASP-Active message is received and the request is refused for management reasons like management lock-out).If this error is in response to an ASP-Active message, the ERR message should contain the routing context found in the ASP-Active message.

The “requiring ASP identifier” error is sent in response to an ASP Up message when the ASP Up message is received by an SGP without the ASP identifier parameter and the SGP requires this parameter.

The “invalid ASP identifier” error is sent in response to an ASP Up message when the ASP Up message is received by an SGP with invalid, or not unique, ASP identifier.

The “invalid parameter value” error is sent if a message is received with an invalid parameter value. For example, a DUPU message was received with a mask value other than “0”).

The “parameter field error” error is sent if a message is received with an error length field in the parameter.

The “unexpected parameter” error is sent if a message is received with an invalid parameter.

The “unknown destination status” error is sent if a DUAD message is received by an SG to audit the availability/congestion state of the destination but the SG does not expect to provide the state. For example, the sender has no right to know the state).

The “loss of parameter” error is sent if a message is received without mandatory parameters.

The “invalid routing context” error is sent if a message is received from a peer with invalid (not configured) routing context value. For such error, the ERR message must contain the invalid routing context.

The “not configuring AS for ASP” error is sent if a message is received from a peer without a routing context parameter and it is not known by configuration data which application servers are referenced.

Diagnostic information

Diagnostic information: variable length

When included, the optional diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. In the case of an invalid traffic handling mode, routing context or parameter value, the diagnostic



2-86

information parameter must be added and include the offending parameter. In the other cases, the diagnostic information may be the first 40 bytes of the offending message.

ERR messages must not be generated in response to other ERR messages.

2) Notify (NTFY)

The NTFY message is used to provide an autonomous indication of M3UA events to an M3UA peer. The NTFY message contains the following parameters:

Status Mandatory ASP identifier Optional Routing context Optional INFO string Optional

The format for the NTFY message is shown in Figure 2-68..

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 10 1 2 3

Tag (0x000d) Length=8

Status type

Tag (0x0011) Length

ASP identifier

Tag (0x0006) Length

Routing context

Tag (0x0004) Length

INFO string

Status information

Figure 2-68 NTFY message format

Status type parameter

The status type parameter identifies the type of the NTFY message. Table 2-18 lists the valid status type values.

Table 2-18 Status type parameter of the NTFY message

Value Description

1 Application server state change AS_State_Change

2 Other

Status information parameter

The status information parameter contains more detailed information for the notification, based on the value of the status type. If the status type is AS_State_Change, the following status information values in Table 2-19 are used.



2-87

Table 2-19 Status information values if the status type is AS_State_Change

Value Description

1 Reserved

2 Application server inactive (AS_Inactive)

3 Application server active (AS_Active)

4 Application server pending (AS_Pending)

These notifications are sent from an SGP to an ASP upon a change in status of a particular application server. The value reflects the new state of the application server.

If the status type is “other”, then the following status information values in Table 2-20 are defined.

Table 2-20 Status information values in the case of other

Value Description

0x01 Insufficient ASP resources active in AS

0x02 Alternate ASP active

0x03 ASP failure

These notifications are not based on the SGP reporting the state change of an ASP or AS. In the insufficient ASP resources case, the SGP is indicating to an ASP-INACTIVE ASP in the AS that another ASP is required in order to handle the load of the AS (load-sharing mode or broadcast mode). For the alternate ASP active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in over-ride mode.

The format and description of the optional ASP identifier, routing context and INFO string parameters are the same as that for the ASPAC message.

2.5.7 Functions Supported by M3UA

I. Signaling Point Code Representation

In an SS7 network, a signaling gateway represents a set of nodes in the IP domain through which the SS7 network is routed.. The SG itself, as a physical node in the SS7 network, might also be represented by an SS7 point code for MTP3 management purposes. The SG point code might also used for addressing any local MTP3-Users at the SG such as an SG-resident SCCP function.



2-88

II. Routing

The distribution of SS7 messages between the SGP and the application servers is determined by routing keys and associated routing contexts.

Possible SS7 address/routing information that comprise a routing key entry includes, for example, the OPC, DPC, SIO found in the MTP3 routing label, or MTP3-User specific fields such as the ISUP CIC, SCCP subsystem number, and TCAP transaction ID.

III. SS7 and M3UA Interworking

In case of SS7 and M3UA inter-working, the M3UA adaptation layer is designed to provide an extension of the MTP3 defined user primitives.

1) Signaling gateway SS7 layers

The SG terminates MTP level 3 of the SS7 protocol, and offers an IP-based extension to its users.

From an SS7 perspective, it is expected that the signaling gateway transmits and receives SS7 message signaling units (MSUs) to and from the PSTN over a standard SS7 network interface, using the SS7 message transfer part (MTP) [14,15,16] to provide reliable transport of the messages.

The SS7 interface of SG may be 64kb/s signaling link, or 2Mb/s high-speed signaling link.

2) SS7 and M3UA inter-working at the SG

The SGP provides a functional inter-working of transport functions between the SS7 network and the IP network by also supporting the M3UA adaptation layer. It allows the transfer of MTP3-user signaling messages to and from an IP-based application server process where the peer MTP3-user protocol layer exists.

3) Application server

A cluster of application servers provides the overall support for one or more SS7 upper layers. From an SS7 standpoint, a signaling point management cluster (SPMC) provides complete support for the upper layer service for a given point code. As an example, an SPMC providing MGC capabilities must provide complete support for ISUP and any other MTP3 user located at the point code of the SPMC for a given point code, according to the local SS7 network specifications.

In case that an ASP is connected to more than one SGP, the M3UA layer must maintain the status of configured SS7 destinations and route messages according to availability/congestion/restricted status of the routes to these SS7 destinations.

4) IPSP considerations



2-89

Since IPSPs use M3UA in a point-to-point fashion, there is no concept of routing of messages beyond the remote end. Therefore, SS7 and M3UA inter-working is not necessary for this model.

IV. Congestion Management

At an ASP or IPSP, the M3UA layer indicates congestion to local MTP3-users by means of an MTP-STATUS primitive, as per current MTP3 procedures, to invoke appropriate upper layer responses.

When an SG determines that the transport of SS7 messages to a signaling point management cluster (SPMC) is encountering congestion, the SG may trigger SS7 MTP3 transfer controlled management messages to originating SS7 nodes, per the congestion procedures of the relevant MTP3 standard.

V. SCTP Stream Mapping

The M3UA layer at both the SGP and ASP also supports the assignment of signaling traffic into streams within an SCTP association. Traffic that requires sequencing must be assigned to the same stream. To accomplish this, MTP3-User traffic may be assigned to individual streams based on, for example, the SLS value in the MTP3 routing label or the ISUP CIC assignment, subject of course to the maximum number of streams supported by the underlying SCTP association.

The use of SCTP streams within M3UA is recommended in order to minimize transmission and buffering delays, therefore improving the overall performance and reliability of the signaling elements. The distribution of the MTP3 user messages over the various streams should be done in such a way to minimize message mis-sequencing, as required by the SS7 user parts.

VI. Client/Server Model

It is recommended that the SGP and ASP be able to support both client and server operation. The peer endpoints using M3UA should be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations. The default orientation would be for the SGP to take on the role of server while the ASP is the client. In this case, ASPs should initiate the SCTP association to the SGP. In case of IPSP to IPSP communication, the peer endpoints using M3UA should be configured so that one always takes on the role of client and the other the role of server for initiating SCTP associations.

The SCTP registered user port number assignment for M3UA is 2905.



2-90

2.5.8 M3UA Message Procedures

The following examples show M3UA message flows for the establishment of traffic between an SGP and an ASP. It is assumed that the SCTP association is already set up.

I. Establishment of Association and Traffic Between SGPs and ASPs

1) Single ASP in an application server

This scenario shows the example M3UA message flows for the establishment of traffic between an SGP and an ASP, where only one ASP is configured within an AS (no backup).

Single ASP in an application server (“1+0” sparing), no registration

In such conditions, the sending of M3UA messages is shown in Figure 2-69.

SGP/IPSP ASP1/IPSP1ASP Up

ASP Up Ack

ASP active (RCn)

ASP active Ack (RCn)RC: Routing Context (optional)

Figure 2-69 Procedure to set up an M3UA messageof (example 1)

Single ASP in an application server (“1+0” sparing), dynamic registration

This scenario is the same as the former one but with the optional exchange of registration information. In this case the registration is accepted by the SGP. In such conditions, the sending of M3UA messages is shown in Figure 2-70.

SGP ASP1ASP Up

ASP Up Ack

REG REQ (LRCn,RKn)

REG RSP (LRCn,RKn)

ASP active (RCn)

ASP active Ack (RCn)

LRC: Local Routing ContextRK: Routing KeyRC: Routing Context

Figure 2-70 Procedure to set up an M3UA message (example 2)



2-91

Single ASP in multiple application servers (each with “1+0” sparing), dynamic registration


SGP ASP1ASP Up

ASP Up Ack

REG REQ(LRC1,RK1)

REG RSP(LRC1,RC1)

ASP active(RC1)

ASP active Ack (RC1)

LRC: Local Routing ContextRK: Routing KeyRC: Routing Context

REG REQ (LRCn,RKn)

REG RSP (LRCn,RCn)

ASP active (RCn)

ASP active Ack (RCn)


2) Multiple ASPs in application server Two ASPs in application server (“1+1” sparing, active/backup)

This scenario shows the example M3UA message flows for the establishment of traffic between an SGP and two ASPs in the same application server, where ASP1 is configured to be in the ASP-ACTIVE state and ASP2 is to be a “backup” in the event of communication failure or the withdrawal from service of ASP1. ASP2 may act as a hot, warm, or cold back-up depending on the extent to which ASP1 and ASP2 share call/transaction state or can communicate call state under failure/withdrawal events. The example message flow is the same whether the ASP active messages indicate “over-ride”, “load-share” or “broadcast” mode, although typically this example would use an over-ride mode. The SGP may start sending any relevant DUNA and SCON messages to ASPs as soon as they enter the ASP-INACTIVE state.




2-92

SGP ASP1ASP Up

ASP Up Ack

ASP Active

ASP Active Ack

ASP Up

ASP2

ASP Up Ack


Two ASPs in an application server (“1+1” sparing, load-sharing case)

This scenario shows a similar case to the former one but where the two ASPs are brought to the state ASP-ACTIVE and subsequently share the load. In this case, one ASP is sufficient to handle the total traffic load.


ASP1ASP Up

ASP-Up Ack

ASP Active (load-share)

ASP Active Ack

ASP Up

ASP-Up Ack


ASP Active Ack

ASP2

NFTY (AS_Active)

SGP


3) Three ASPs in an application server (“n + k” sparing, load-sharing case)

This scenario shows the example M3UA message flows for the establishment of traffic between an SGP and three ASPs in the same application server, where two of the ASPs are brought to the state ASP-ACTIVE and subsequently share the load. In this case, a minimum of two ASPs are required to handle the total traffic load (2 + 1 sparing).




2-93

SGP ASP1ASP Up

ASP Up Ack


ASP Active Ack

ASP Up

ASP Up Ack

ASP Act (load-share)

ASP Active Ack

ASP2 ASP3

ASP Up

ASP Up Ack

NTFY (AS_Active)

NTFY (AS_Active)


II. ASP Traffic Fail-over Examples

1) 1+1 sparing, withdrawal of ASP, back-up over-ride

Refer to Figure 2-72 for the process that ASP1 withdraws from service as shown in Figure 2-75.

SGP ASP inactive

ASP inactive Ack

ASP active

ASP active Ack

NTFY (AS-Pending)

ASP2

Figure 2-75 ASP traffic fail-over exampleof 1

Note: If the SGP M3UA layer detects the loss of the M3UA peer (M3UA heartbeat loss or detection of SCTP failure), the initial ASP inactive message exchange (for example, between the SGP and the ASP1) would not occur.

2) 1+1 sparing, back-up over-ride



2-94

The following is based on the example in Figure 2-72, and ASP2 wishes to over-ride ASP1 and take over the traffic. See Figure 2-76.

SG ASP1

NTFY (alternate ASP-active)

ASP active

ASP2

ASP active Ack

Figure 2-76 ASP traffic fail-over example 2

3) n+k sparing, load-sharing case, withdrawal of ASP

The following is based on the example in Figure 2-72 and ASP1 withdraws from service. See Figure 2-77.

SG ASP1ASP inactive

ASP inactive Ack

NTFY (insufficient ASPs)（

ASP active (load-sharing)

ASP active Ack

ASP2 ASP3

Figure 2-77 ASP traffic fail-over example 3

For the NTFY message to be sent, the SG maintains knowledge of the minimum ASP resources required. For example, if the SG knows that “n + k” = “ 2 + 1” for a load-share AS, then “n” currently equals “1”).

Note: If the SGP detects loss of the ASP1 M3UA peer (M3UA heartbeat loss or detection of SCTP failure), the initial ASP inactive message exchange (for example, between the SGP and the ASP1) would not occur.

III. Normal Withdrawal of an ASP from an Application Server and Teardown of an Association

An ASP which is now confirmed in the state ASP-INACTIVE (for example, the ASP has received an ASP inactive Ack message) may now proceed to the ASP-DOWN state, if it is to be removed from service.



2-95

See Figure 2-78.

SGP ASP1ASP inactive (RCn)

DEREG REQ(RCn)

DEREG RSP(LRCn,RCn)

ASP Down

ASP Down Ack

RC: Routing Context

ASP inactive Ack (RCn)

Figure 2-78 Example of normal withdrawal of an ASP from an application server anteardown of an association

d

IV. M3UA Message Communication Example in IPSP-IPSP Mode

Supposing an SCTP association has been set up, this example indicates the three stages (setup, data exchange and disconnection) for IPSP communication, as shown in Figure 2-79.

ASP Up

ASP Up Ack

ASP active Ack (RCb)

DATA

ASP inactive (RCb)

ASP inactive Ack (RCb)

ASP Down

ASPDown Ack

RC: Routing Context (optional)( )

RC: Routing Context (optional))

ASP active (RCb)

Figure 2-79 M3UA message communication example in IPSP-IPSP mode

Documents

Sigtran Main Concepts