Sigtran Main Concepts

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway
Table of Contents
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
Huawei Technologies Proprietary i
Chapter 2 SIGTRAN
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.
Huawei Technologies Proprietary 2-1

Packet switched network
SG SIGTRAN
Chapter 2 SIGTRAN
Switched Circuit Network
MGC
MG
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
SS7
STP
SS7
SG
IP
MGC
ISUP M3UA MTP SCTP 1-3 IP
ISUP M3UA SCTP IP
MTP1-3
MTP1-3
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

Chapter 2 SIGTRAN
SEP
ISUP
SS7
STP
SS7
MG/SG
IP
MGC
ISUP MTP3
MTP1-3
MTP1-3
M2UA MTP SCTP 1-2 IP
M2UA SCTP IP
Figure 2-4 Application architecture of M2UA stack 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
ISUP
SS7
STP
SS7
SG
IP
MGC
ISUP
MTP3 MTP1-3 MTP1-3 M2PA MTP 1-2 SCTP IP
MTP3 M2PA SCTP IP
Figure 2-5 Application architecture of M2UA stack 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
Chapter 2 SIGTRAN
of all, it has great compatibility with the lower communication technologies. The main features of the IP will be described below.
I. IP Features
z
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 ICMP
IP
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
Chapter 2 SIGTRAN
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.
0123 4 Class A Class B Class C 0 1 0 net-id net-id 8 16 host-id host-id 24 31
1 1 0
net-id
host-id
Class D
1 1 10
Multicast address
Class E
1 1 1 10
Reserved for future use
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.
Chapter 2 SIGTRAN
The following IP addresses are reserved for special purposes.

z
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.
z z z
z z
Now we shall describe the key features of IP address:

z
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).

A llocated locally C lass B
Chapter 2 SIGTRAN
n et-id
(a )
h o s t-id
S ub net-id H ost-id
A dd the sub bet field
n e t-id
(b)
Subnet - id
S u bne t m ask
11111111
11111111
111111 0 0
0 0000 000
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.
Chapter 2 SIGTRAN
Host name host-a IP=209 .0.0.5 Destination host name IP address of destination host
net-id=209.0.0
host-b DNS 209.0.06 ARP

IP=209 .0.0.6
Host name host-b Network adaptator
08002B00EE0A
Physical address of destination host
08002B00EE0A
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) 2) 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. All hosts on the LAN run their ARP processes and receive the ARP request.
Chapter 2 SIGTRAN
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.

0 1 2 3 4 D 5 6 T 7 R C Not used
Chapter 2 SIGTRAN
Precedence
Bits 0 4 Version Fixed length of 20 bits
8 IHL
16 19 24 Type of service
31 Total length Flag Fragment offset Header checksum
Identification Time to live Protocol
Source address Destination address
Length variable
Options Data ...
Padding
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.
Chapter 2 SIGTRAN
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 34 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.
Chapter 2 SIGTRAN
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
1bit Copied flag
2bit Option class
5bit Option number
0 Datagram or control 1 Reserved for future use 2 Debugging and measurement 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.

Chapter 2 SIGTRAN
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.
0 8 Option code 16 24 Length First IP address Second IP address ... 31 Pointer
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:
z z z
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, and send it back to the source address. The following two options are of the source address routing:
z
should negotiate with the destination
source, ask the destination address to extract the route information from the datagram
3: loose source routing, variable.

z
Chapter 2 SIGTRAN
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.
z
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.
Chapter 2 SIGTRAN
As a router,
z z
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:

z z
It generates the routing table; It forwards the packet to other networks, which is done based on the routing table.
Interface address 61.1.1.1 Interface address 129.6.0.1
Subnet 3
Router
61.0.0.0/8
Subnet 1 129.6.0.0/16
Router
B B
Subnet 2 202.6.6.0/24
Interface address 129.6.69.107
Interface address 202.6.6.1
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

202.6.6.0 129.6.0.0 61.0.0.0
Destination network mask

255.255.255.0 255.255.0.0 255.0.0.0
Next hop address

129.6.0.1 129.6.69.107 61.1.1.1
Out interface
129.6.69.107 129.6.69.107 61.1.1.1
The following routing table will be stored in router B:
Destination network address

61.0.0.0 129.6.0.0 202.6.6.0
Destination network mask

255.0.0.0 255.255.0.0 255.255.255.0
Next hop address

129.6.69.107 129.6.0.1 202.6.6.1
Out interface
129.6.0.1 129.6.0.1 202.6.6.1
Two methods can help the router get the table.

z
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.
Chapter 2 SIGTRAN
Router
Route selection resolution protocol
Router
IP ETH
Unpacketizing
IP PPP
Encapsulating
ETH
PPP
Ethernet Serial interface port
Ethernet Serial interface port
LAN1
Sending
WAN
Transmitting
LAN2
Receiving
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.
ICMP message
IP header
Datagram data IP datagram
Figure 2-15 Relationship between ICMP message and IP datagram

0 Type 8 16 31
Chapter 2 SIGTRAN
Code Checksum
Contents depends on code and type
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 0 3 4 5 8 11 12 13 14 17 18 Type of ICMP message Echo replay Destination unreachable Source Quench Redirect Echo request Time exceeded Parameter problem Timestamp request Timestamp reply Address Mask request 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.

B Network 2 R1 C Network 3 Network 1
Chapter 2 SIGTRAN
R2
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.
0 Type 8 Code 16 31
Checksum IP address of router
Header of original IP datagram Fore 8 bytes of original IP datagram
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
Chapter 2 SIGTRAN
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:
z
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

z z z
Transport protocol based on subscribers 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.
Chapter 2 SIGTRAN
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.
Chapter 2 SIGTRAN
Host
Endpoint 1
User1
Port1
IP address 1 IP address 1
SCTP
Port 2
User2
Endpoint2
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
Chapter 2 SIGTRAN
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:
z
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.
z z
Figure 2-20 demonstrates the relation between association and stream.

SCTP endpoint A SCTP endpoint B
SCTP stream (unidirectional)
It can have multiple pairs of IP/SCTP-port
SCTP association
It can have multiple pairs 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

A B C 1 2 3
TSN
1 1 2
SSN
Chapter 2 SIGTRAN
Data
D1 D2 4 5
TSN
2 2
SSN
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:
Chapter 2 SIGTRAN
Sequenced delivery within streams
User data fragmentation
Acknowledgement and congestion avoidance Association startup and takedown Chunk bundling
Packet validation
Path management
Figure 2-21 Functional view of the SCTP transport service

z
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.
z
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.
z
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.
z
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.
z
Chunk bundling
Chapter 2 SIGTRAN
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.
z
Packet validation
A mandatory Verification Tag field and a 32-bit checksum field are included in the SCTP common header.
z
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) 3) SCTP supports the configuration of multiple IP addresses. 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
Chapter 2 SIGTRAN
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 peers 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.
Endpoint A T1init T3-rtx Established INIT(Tag_A) INIT ACK(Tag_Z, connection information Z) COOKIE ECHO(connection information Z) + DATA T1-cookie COOKIE ACK +DATA + SACK SACK Established Endpoint Z
Italic items: optional information chunks
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
Chapter 2 SIGTRAN
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:
z
Protecting against service denial attack
Chapter 2 SIGTRAN
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.
z
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
GRACEFUL shutdown of association is implemented through three-way handshake:

z
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 for the validation 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
Chapter 2 SIGTRAN
message from the peer end. In this status, the data received from the peer end will be validated immediately. The slowdown validation mechanism of SCTP application will be introduced in the following part.
z
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 SHUTDOWN timer 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 COMPLETE message to the peer end, and then delete the TCB of the association.
Upon receiving the SHUTDOWN COMPLETE message, the peer end will delete the TCB of association. UNGRACEFUL shutdown
2)
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, he cannot interfere an established association by sending a legal ABORT message.
III. Data Transmission

Data transmission takes place after the establishment of an association. During the establishing process, data can be carried in some steps. Features of SCTP data transmission: 1) Stream control with window
SCTP adopts two kinds of windows for data transmission: One is CWND, and the other is RWND. The former maintains every destination IP address, while the latter maintains every association. CWND describes: For a transmission path, it specifies the size of which the data can be transported 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 describe two different objects, they are needed for restriction of the data transmission. 2)
z
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
Chapter 2 SIGTRAN
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 set to 0. Even if there is space in the peer receiving buffer, the data cannot be sent.
z
When data is to be transmitted to an address, if the un-validated data has reached or exceeded the limit of CWND, no data can be sent to this address. Before new data is translated, the data labeled as retransmit should be sent in advance. That means the retransmit data is preferred. Slowdown/selected validation
3)
Slowdown selected validation can be divided into slowdown validation and selected 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 200 ms. In this way, the overload of the ACK messages on the path 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-SENT status, immediate validation mechanism 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 acknowledgement message (SACK) of SCTP selected validation is shown in Figure 2-24:
Chapter 2 SIGTRAN
Figure 2-24 Structure of SACK message

Three fields should be noted:
z
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
Chapter 2 SIGTRAN
maintain a timer for each IP address, lots of system resources are saved. The ruleof SCTP can be described as follows
z
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:
z
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. Multi-homed:
5)
Multi-homed means multiple IP addresses are supported. The following demonstrates how multi-homed is used by SCTP in data transmission.
z
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.

z
Chapter 2 SIGTRAN
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 paths 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
Chapter 2 SIGTRAN
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.
Chapter 2 SIGTRAN
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
z
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.
z z
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.

No.7 SEP SG IP IPSP
Chapter 2 SIGTRAN
MTP3-User MTP3 MTP2 MTP1 MTP3 MTP2 MTP1 M2PA SCTP IP
MTP3-User MTP3 M2PA SCTP IP
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.
IP IPSP IPSP
MTP3 M2PA SCTP IP
MTP3 M2PA SCTP IP
Figure 2-26 M2PA symmetrical peer-to-peer architecture
Chapter 2 SIGTRAN
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.
1 3 0 2 01234567890123456789012345678901
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.
Chapter 2 SIGTRAN
3 0 1 2 01234567890123456789012345678901 Message Version Message class Spare type Message length
Figure 2-28 Common message header

z
Version
The version field contains the version of M2PA.The supported versions are: Value 1
z
Version 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.
z
Message Class
The following list contains the valid message classes: Value (decimal) 11 Message Class M2PA Messages
Other values are invalid for M2PA.

z
Message Type
The following list contains the message types for the defined messages. Value ----1 2 Message Type -----------User Data Link Status
Other values are invalid.

z
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.

0 3 1 2 01234567890123456789012345678901 Not used Not used FSN BSN
Chapter 2 SIGTRAN
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.
z
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 8n(n 2) SIO 8 00 2 LI 6
2 0 1 3 01234567890123456789012345678901 User data
Figure 2-30 User data message

z
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.
2 0 1 3 01234567890123456789012345678901 Status
Figure 2-31 Link status

The valid values for State are shown in the following table.
Chapter 2 SIGTRAN
Value (decimal) 1 2 3 4 5 6 7 8 9 10
Description Alignment Proving Normal Proving Emergency Ready Processor Outage Processor Outage Ended Busy Busy Ended Out of Service 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.
DCBA 0001 H0 4 Label 56
M2PA sequence number

24
H1 4
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.
Chapter 2 SIGTRAN
II. MTP2 Functionality

M2PA provides MTP2 functionality that is not provided by SCTP. This includes
z z z z
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:
z z z z
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.

z z z
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.

z z
Chapter 2 SIGTRAN
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.
z z
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 (Associate)
OOS
Link Configured (Associate) MTP3 start
AIP
MTP3 stop or T1 expiry
SCTP Comm Error or SCTP Comm Lost
Receive LS Alignment OR LS Proving
PROVING
MTP3 Stop OR Receive LS OOS SCTP Comm Error or SCTP Comm Lost
ALIGNED READY
SCTP Comm Error MTP3 Stop OR T3 Expiry OR Receive LS OOS or SCTP Comm Lost
Receive LS Ready OR Receive User Data
INS
MTP3 Stop OR Receive LS OOS OR SCTP Comm Error OR SCTP Comm Lost OR T6 Expiry M2PA link faulty
RETRIVAL Retrieval complete OR MTP3 Start
Figure 2-33 M2PA Link State Transition Diagram

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

z z z
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 (Issue SCTP associate)
(Issue SCTP associate)
ASSOCIATE
SCTP Comm Error
SCTP Comm Up
ESTABLISHED SCTP Comm Error OR 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.
Chapter 2 SIGTRAN
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.
z
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
IPA port= PW SLC= a
SCTP Association 1
IPB port= PW SLC= a
IPC port= PW SLC= b
SCTP Association 2
IPD port= PW SLC= b
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 Association
1 2
IPSPX IP address
IPA IPC
IPSPY Port
PW PW
IP address
IPB IPD
Port
PW PW
SLC
a b
Associations and links one IPSP connected to two IPSPs
Figure 2-36 and Table 2-3 show an example with three IPSPs.

IPSP X SCTP Association 1 IPSP Y
Chapter 2 SIGTRAN
IPA port= PW SLC= a
IPB port= PW SLC= a
IPC port= PW SLC= b
SCTP Association 2 IPSP Z
IPD port= PW SLC= 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 IPSPX Association
1
IPSPY Port
PW
IP address
IPA
IP address
IPB
Port
PW
SLC
a
IPSPX Association
2
IPSPZ Port
PW
IP address
IPC
IP address
IPD
Port
PW
SLC
b

z
Chapter 2 SIGTRAN
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 SCTP Association 1 IPSP Y
IPA port= P1 SLC= a
IPB port= PW SLC= a
IPA port= PW SLC= b
SCTP Association 2
IPB port= PW SLC= b
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 Association
1 2
IPSPX IP address
IPA IPA
IPSPY Port
P1 PW
IP address
IPB IPB
Port
PW PW
SLC
a 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:

z
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.
z z
Link alignment procedure:
Chapter 2 SIGTRAN
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.
Chapter 2 SIGTRAN
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:
z z z z z
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
Chapter 2 SIGTRAN
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 16 seconds. 6) Error monitoring
Chapter 2 SIGTRAN
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.
Chapter 2 SIGTRAN
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:
z
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
Chapter 2 SIGTRAN
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:
z
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:
z
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).
Chapter 2 SIGTRAN
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.
Chapter 2 SIGTRAN
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
Chapter 2 SIGTRAN
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.
SEP
SS7
SG
IP
MGC
MTP User MTP3 MTP2 MTP1
NIF MTP3 MTP2 MTP1 M3UA SCTP IP
NIF M3UA SCTP IP
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.
MGC
IP
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
Chapter 2 SIGTRAN
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:
z
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 ASPs 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).
Chapter 2 SIGTRAN
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.
3 0 1 2 01234567890123456789012345678901 Version Spare Message class Message type
Message length
Figure 2-41 Common message header

z
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.

z
Chapter 2 SIGTRAN
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

Management (MGMT) message Transfer messages SS7 signaling messages network management (SSNM) 00 01 02 03 04 05 06 07 08 09 0A-7F 80-FF
Message class code (hexadecimal)
ASP state maintenance (ASPSM) messages ASP traffic maintenance (ASPTM) messages Reserved for other Sigtran adaptation layers Reserved for other Sigtran adaptation layers Reserved for other Sigtran adaptation layers Reserved for other Sigtran adaptation layers Routing key management (RKM) messages Reserved by the Internet Engineering Task Force (IETF) Reserved for extensions IETF-defined message class
Table 2-6 M3UA management (MGMT) message types Message type

Error (ERR) Notify (NTFY) Reserved by the IETF Reserved for IETF-defined MGMT extensions 00 01 02-7F 80-FF
Message type code (hexadecimal)
Table 2-7 M3UA transfer message types Message type

Reserved 00
Chapter 2 SIGTRAN
Message type
Data (DATA) Reserved by the IETF Reserved for IETF-defined transfer extensions 01
02-7F 80-FF
Table 2-8 M3UA signaling network management (SSNM) message types Message type
Reserved Destination unavailable (DUNA) Destination available (DAVA) Destination state audit (DAUD) SS7 network congestion (SCON) Destination user part unavailable (DUPU) Destination restricted temporarily) Reserved by the IETF Reserved for IETF-defined SSNM extensions (DRST) (not in use 00 01 02 03 04 05 06 7-7F 80-FF
Table 2-9 M3UA state maintenance (ASPSM) message types Message type
Reserved ASP up (ASPUP) ASP down (ASPDN) Heartbeat (BEAT) ASP up acknowledgement (ASPUP ACK) ASP down acknowledgement (ASPDN ACK) Heartbeat acknowledgement (BEAT ACK) Reserved by the IETF Reserved for IETF-defined ASPSM extensions 00 01 02 03 04 05 06 7-7F 80-FF
Chapter 2 SIGTRAN
Table 2-10 M3UA traffic maintenance (ASPTM) message types Message type
Reserved ASP active (ASPAC) ASP inactive (ASPIA) ASP active acknowledgement (ASPAC ACK) ASP inactive acknowledgement (ASPIA ACK) Reserved by the IETF Reserved for IETF-defined ASPTM extensions 00 01 02 03 04 5-7F 80-FF
Table 2-11 M3UA routing key management (RKM) message types Message type
Reserved Registration request (REG REQ) Registration response (REG RSP) Deregistration request (DEREG REQ) Deregistration response (DEREG RSP) Reserved by the IETF Reserved for IETF-defined RKM extensions 00 01 02 03 04 5-7F 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.

0 2 1 3 01234567890123456789012345678901 Parameter tag Parameter length
Chapter 2 SIGTRAN
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.
z
Parameter tag
The tag field is a 16-bit identifier of the type of parameter. Its 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

Reserved Not used in M3UA Not used in M3UA Not used in M3UA INFO string Not used in M3UA Routing context Diagnostic information Not used in M3UA Heartbeat data Not used in M3UA Traffic mode type Error code Status Not used in M3UA Not used in M3UA
Parameter tag code (hexadecimal)

0x0000 0x0001 0x0002 0x0003 0x0004 0x0005 0x0006 0x0007 0x0008 0x0009 0x000a 0x000b 0x000c 0x000d 0x000e 0x000f
Chapter 2 SIGTRAN
Parameter
Not used in M3UA ASP identifier Affected signaling point code Correlation ID

0x0010 0x0011 0x0012 0x0013
Table 2-13 lists the M3UA specific parameters.
Table 2-13 M3UA specific parameters Parameter

Network appearance Reserved Reserved Reserved User/cause Congestion indications Concerned destination Routing key Registration result Deregistration result local_routing key identifier Destination point code Service indicators Reserved Originating point code list Circuit range Protocol data Reserved Registration status Deregistration status Reserved by the IETF 0x0200 0x0201 0x0202 0x0203 0x0204 0x0205 0x0206 0x0207 0x0208 0x0209 0x020a 0x020b 0x020c 0x020d 0x020e 0x020f 0x0210 0x0211 0x0212 0x0213 0x0214-0xffff

z
Chapter 2 SIGTRAN
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 Routing context Protocol data Correlation ID Optional (not in use temporarily) Optional Mandatory Optional
Figure 2-43 shows the parameter format for the data message.
0 1 2 3 01234567890123456789012345678901 Tag(0x0200) Network appearance Tag(0x0006) Routing context Tag (0x00210) Protocol data Tag(0x0013) Correlation Id Length=8 Length=8 Length=8 Length=8
Figure 2-43 Data message parameter format

1) Network appearance
Chapter 2 SIGTRAN
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:
z z z z z
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 01234567890123456789012345678901 Idle Idle Idle SI Idle NI Protocol data OPC DPC Idle SLS
Figure 2-44 Format of protocol data

z z
OPC: 24 bits; DPC: 24 bits;


z z z z
Chapter 2 SIGTRAN
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:
z z z z
Network appearance Routing context Affected destinations INFO string
Optional (not in use temporarily) Optional Mandatory Optional
0 1 2 3 01234567890123456789012345678901 Tag(0x0200) Network appearance Tag(0x0006) Routing context Tag(0x0012) Reserved Length Affected destinations DPC1 : Reserved Tag (0x0004) INFO string Affected destinations DPCn Length Length Length=8
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.
Chapter 2 SIGTRAN
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:
z z z z
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:
z z z z
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
Chapter 2 SIGTRAN
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:
z z z z z z
Network appearance Routing context Affected destinations Concerned destination Congestion indications INFO string
Optional (not in use temporarily) Optional Mandatory Optional Optional Optional
Figure 2-46 shows the format for the SCON message parameters.
0 1 2 3 01234567890123456789012345678901 Tag (0x0200) Length=8 Network appearance Tag(0x0006) Routing context Tag (0x0012) Reserved Length Affected destination DPC1 : Reserved Tag (0x0206) Reserved Tag (0x205) Reserved Tag(0x0004) INFO string Concerned DPC Length
Congestion indications
Length
Affected destination DPCn Length
Length
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)
Chapter 2 SIGTRAN
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 Routing context Affected destinations User/cause INFO string Optional (not in use temporarily) Optional Mandatory Mandatory Optional
The format for DUPU message parameters is as follows:

0 1 2 3 01234567890123456789012345678901 Tag(0x0200) Network appearance Tag(0x0006) Routing context Tag(0x0012) Reserved Tag(0x0204) Cause Tag(0x0004) INFO string Length=8 Affected destination DPC Length=8 User Length Length Length=8
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.
Chapter 2 SIGTRAN
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
Unknown Unequipped remote user Inaccessible remote user 0x0000 0x0001 0x0002
Value
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
Reserved SCCP TUP ISUP Reserved Broadband ISUP Satellite ISUP Reserved AAL type 2 signaling BICC Gateway control protocol Reserved
Value
0x0000 0x0002 0x0003 0x0004 0x0005 0x0006 0x0008 0x0009 0x000a 0x000b 0x000c 0x000d 0x000e 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.
Chapter 2 SIGTRAN
The ASP Up message contains the following parameters: ASP identifier INFO string Optional Optional
Figure 2-48 shows the format for the ASP Up message parameters.
0 1 2 3 01234567890123456789012345678901 Tag (0x0011) ASP identifier Tag (0x0004) INFO string Length Length
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: INFO string Optional
Figure 2-49 shows the format for the ASP Up Ack message parameters.
3 0 1 2 01234567890123456789012345678901 Tag(0x0004) INFO string Length
Figure 2-49 ASP Up Ack message parameter format

The format and description of the optional INFO string parameter is the same as that of the DUNA message. 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:
Chapter 2 SIGTRAN
INFO string
Optional
Figure 2-50 shows the format for the ASPDN message parameters.
3 0 1 2 01234567890123456789012345678901 Tag (0x0004) INFO string Length
Figure 2-50 ASPDN message parameter format

The format and description of the optional INFO string parameter is the same as that of the DUNA message. 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: INFO string Optional
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 01234567890123456789012345678901 Tag (0x0004) Heartbeat data ...... Length
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
Chapter 2 SIGTRAN
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 01234567890123456789012345678901 Tag (0x0207) Routing key 1 ...... Tag (0x0207) Routing key n Length 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.

0 1 2 3 01234567890123456789012345678901 Local-RK-identifier Traffic mode type (optional) Destination point code Network appearance (optional) SI (optional) Origination point code list (optional) Circuit range list (optional)
. . .
Chapter 2 SIGTRAN
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.
z
Local-RK-identifier
Figure 2-54 shows the format of the local-RK-identifier field.

0 2 1 3 01234567890123456789012345678901 Tag (0x020a) Length=8 Local RK identifier
Figure 2-54 Local-RK-identifier parameter format

z
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:

0 2 1 3 01234567890123456789012345678901 Tag (0x020b) Length=8 Traffic mode identifier
Chapter 2 SIGTRAN
Figure 2-55 Traffic mode type parameter format

The valid values for traffic mode type are as follows:
z z z
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.
z
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 01234567890123456789012345678901 Tag (0x020b) Reserved Length=8 Destination Point Code
Figure 2-56 Destination point code parameter format

z
Network appearance
The network appearance parameter is not in use temporarily.

z
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.

0 2 1 3 01234567890123456789012345678901 Tag (0x020c) SI#1 SI#2 ..... Length=variable SI#3 SI#4
Chapter 2 SIGTRAN
SI#n
0 padding if necessary
Figure 2-57 SI parameter format

z
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 2 1 3 01234567890123456789012345678901 Tag (0x020e) Reserved ..... Length=variable OPC#1
Reserved
OPC#n
Figure 2-58 OPC parameter format

z
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:

0 2 1 3 01234567890123456789012345678901 Tag (0x020f) Reserved Lower CIC value #1 Reserved Lower CIC value #2 ...... Reserved Lower CIC vlaue #n OPC#n Upper CIC value #n Length=8 OPC#1 Upper CIC value #1 OPC#2 Upper CIC value #2
Chapter 2 SIGTRAN
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 01234567890123456789012345678901 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:

0 2 1 3 01234567890123456789012345678901 Tag=0x020a Length=8
Chapter 2 SIGTRAN
Local-RK-identifier value Tag=0x0212 Registration status Tag=0x0006 Routing context Length=8 Length=8
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 1 2 3 4 5 6 7 8 9 10 Successfully registered Error unknown Error invalid DPC Error invalid network appearance Error invalid routing key Error permission denied Error cannot support unique routing Error routing key not currently provisioned Error insufficient resources Error unsupported RK parameter field 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
Chapter 2 SIGTRAN
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 2 1 3 01234567890123456789012345678901 Tag (0x0006) Routing context ...... Length
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 2 1 3 01234567890123456789012345678901 Tag (0x0209) De-registration result 1 ...... Tag (0x0209) De-registration result n Length Length
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:

0 2 1 3 01234567890123456789012345678901 Tag=0x0006 Routing context Tag=0x0213 Length=8 De-registration status Length=8
Chapter 2 SIGTRAN
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:
z z z
Traffic mode type Routing context INFO string
Optional Optional Optional
The format for the ASPAC message is shown in Figure 2-65:

0 1 2 3 01234567890123456789012345678901 Tag (0x000b) Traffic mode type Tag (0x0006) Routing context ..... Tag (0x0004) INFO string Length Length Length
Chapter 2 SIGTRAN
Figure 2-65 ASPAC message format

z
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

1 2 3 Over-ride Load-share Broadcast
Description
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.
z
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.

z
Chapter 2 SIGTRAN
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:
z z z
Traffic mode type Routing context INFO string
Optional Optional 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:
z z
Routing context INFO string
Optional Optional
The format for the ASPIA message parameters is as follows:

3 0 1 2 01234567890123456789012345678901 Tag (0x0006) Routing context ..... Tag (0x0004) INFO string Length Length
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
Chapter 2 SIGTRAN
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:
z z
Routing context INFO string
Optional 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:
z z z z z
Error code Routing key Network appearance Affected signaling point code Diagnostic information
Mandatory Mandatory Optional Mandatory Optional
The format for the ERR message is shown in Figure 2-67.

2 0 1 3 01234567890123456789012345678901 Tag (0x000c) Error code Tag (0x0006) Routing context ...... Tag (0x0012) Length Affected signaling point code 1 ...... Affected signaling point code n Tag (0x0200) Network appearance Tag (0x0007) Length Length Length Length=8
Chapter 2 SIGTRAN
Diagnostic information
Figure 2-67 ERR message format

z
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

0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c Invalid version Not used in M3UA Unsupported message class Unsupported message type Unsupported/invalid traffic handling mode Unexpected message Protocol error Not used in M3UA Invalid stream identifier Not used in M3UA Not used in M3UA Not used in M3UA
Description
Chapter 2 SIGTRAN
Value
0x0d 0x0e 0x0f 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a
Description
Refused management blocking Requiring ASP identifier Invalid ASP identifier Not used in M3UA Invalid parameter value Parameter field error Unexpected parameter Unknown destination status Invalid network appearance Loss of parameter Not used in M3UA Not used in M3UA Invalid routing context 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.
Chapter 2 SIGTRAN
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.
z
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
Chapter 2 SIGTRAN
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:
z z z z
Status ASP identifier Routing context INFO string
Mandatory Optional Optional Optional
The format for the NTFY message is shown in Figure 2-68..

0 1 2 3 01234567890123456789012345678901 Tag (0x000d) Status type Tag (0x0011) ASP identifier Tag (0x0006) Routing context Tag (0x0004) INFO string Length Length Length=8 Status information Length
Figure 2-68 NTFY message format

z
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

1 2
Description
Application server state change AS_State_Change 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.
Chapter 2 SIGTRAN
Table 2-19 Status information values if the status type is AS_State_Change Value
1 2 3 4 Reserved Application server inactive (AS_Inactive) Application server active (AS_Active) Application server pending (AS_Pending)
Description
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

0x01 0x02 0x03
Description
Insufficient ASP resources active in AS Alternate ASP active 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.
Chapter 2 SIGTRAN
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 From an SS7 standpoint, a signaling point management cluster (SPMC)
A cluster of application servers provides the overall support for one or more SS7 upper layers. 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
Chapter 2 SIGTRAN
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.
Chapter 2 SIGTRAN
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).
z
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.

SG P/IPSP ASP1/IPSP1
ASP 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)

z
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 ASP Up ASP Up Ack REG REQ (LRCn,RKn) REGRSP (LRCn,RKn) ASP active (RCn) ASP active Ack (RCn) LRC: Local Routing Context RK: Routing Key RC: Routing Context ASP1
Figure 2-70 Procedure to set up an M3UA message (example 2)

z
Chapter 2 SIGTRAN
Single ASP in multiple application servers (each with 1+0 sparing), dynamic registration
In such conditions, the sending of M3UA messages is shown in Figure 2-71.

SGP ASP Up ASP Up Ack REG REQ(LRC1,RK1) REG RSP(LRC1,RC1) ASP active(RC1) ASP active Ack (RC1) LRC: Local Routing Context RK: Routing Key RC: Routing Context ASP1
REG REQ (LRCn,RKn) REG RSP (LRCn,RCn) ASP active (RCn) ASP activeAck (RCn)

2)
z
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. In such conditions, the sending of M3UA messages is shown in Figure 2-72.

SGP ASP Up ASP Up Ack ASP Up ASP Up Ack ASP Active ASP Active Ack ASP1 ASP2
Chapter 2 SIGTRAN

z
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. In such conditions, the sending of M3UA messages is shown in Figure 2-73.
SGP ASP Up ASP-Up Ack ASP Up ASP-Up Ack ASP Active (load-share) ASP Active Ack NFTY (AS_Active) ASP Active (load-share) ASP Active Ack ASP1 ASP2

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). In such conditions, the sending of M3UA messages is shown in Figure 2-74.

ASP3
Chapter 2 SIGTRAN
SGP
ASP Up ASP Up Ack ASP Up
ASP1
ASP2
ASP Up Ack ASP Up ASP Up Ack ASP Active (load-share) ASP Active Ack NTFY (AS_Active) NTFY (AS_Active) ASP Act (load-share) ASP Active Ack
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 NTFY (AS-Pending) ASP active ASP active Ack 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
Chapter 2 SIGTRAN
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 ASP active ASP active Ack NTFY (alternate ASP-active) ASP2
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 ASP1 ASP2 ASP3
ASP inactive ASP inactive Ack
NTFY (insufficient ASPs) ASP active (load-sharing) ASP active Ack
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.
Chapter 2 SIGTRAN
See Figure 2-78.

SGP ASP inactive (RCn) ASP inactive Ack (RCn) DEREG REQ(RCn) DEREG RSP( LRCn,RCn ) ASP Down ASP Down Ack RC: Routing Context ASP1
Figure 2-78 Example of normal withdrawal of an ASP from an application server and
teardown of an association
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 (RCb)
RC: Routing Context ( (optional) )
ASP active Ack (RCb) DATA ASP inactive (RCb) RC: Routing Context (optional) ) ASP inactive Ack (RCb) ASP Down ASPDown Ack
Figure 2-79 M3UA message communication example in IPSP-IPSP mode

Sigtran Main Concepts

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sigtran Main Concepts

Uploaded by

Copyright:

Available Formats

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

Huawei Technologies Proprietary i

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

2.1.2 SIGTRAN Protocol Model

2.1.3 Application Model of SIGTRAN Protocols

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

Switched Circuit Network

2.1.4 Basic Architecture of SIGTRAN Stack

ISUP M3UA MTP SCTP 1-3 IP

ISUP M3UA SCTP IP

II. Application Architecture of M2UA Stack

Huawei Technologies Proprietary 2-2

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

M2UA MTP SCTP 1-2 IP

III. Application Architecture of M2PA Stack

MTP3 MTP1-3 MTP1-3 M2PA MTP 1-2 SCTP IP

MTP3 M2PA SCTP IP

2.2 Internet Protocol

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

II. IP and Relative Protocols

TELNET: Telecommunications Network FTP: File transfer protocol

Figure 2-6 IP and relative protocols

2.2.2 IP Address and Conversion

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

Reserved for future use

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

The following IP addresses are reserved for special purposes.

Now we shall describe the key features of IP address:

II. Subnet Addressing

Huawei Technologies Proprietary 2-6

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

A dd the sub bet field

Figure 2-8 Meaning of subnet mask

III. Address Resolution

Huawei Technologies Proprietary 2-7

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

host-b DNS 209.0.06 ARP

Host name host-b Network adaptator

Physical address of destination host

Huawei Technologies Proprietary 2-8

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

2.2.3 Format of IP Datagram

Huawei Technologies Proprietary 2-9

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

Bits 0 4 Version Fixed length of 20 bits

31 Total length Flag Fragment offset Header checksum

Identification Time to live Protocol

Source address Destination address

Options Data ...

Figure 2-10 Format of IP datagram

I. Fixed Part of IP Datagram Header

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

Huawei Technologies Proprietary 2-11

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

II. Variable Options in IP Header

1 Copied to all fragments 0 Copied to the first fragment only

1bit Copied flag

2bit Option class

5bit Option number

Figure 2-11 Option format

The option number indicates the utility of one option.

Technical Manual Signaling and Protocols U-SYS SG7000 Signaling Gateway

Figure 2-12 Format of Record route option

should negotiate with the destination