SIGTRAN

IUA

ftp://ftp.rfc-editor.org/in-notes/rfc3057.txt

The architecture that has been defined for SCN signaling transport over IP uses multiple components, including an IP transport protocol, a signaling common transport protocol and an adaptation module to support the services expected by a particular SCN signaling protocol from its underlying protocol layer. IUA defines an adaptation module that is suitable for the transport of ISDN Q.921-User Adaptation Layer (e.g., Q.931) messages.

The IUA layer inmplements the following functions

• Mapping
  The IUA layer maintains a map of the Interface Identifier to a physical interface on the Signaling Gateway. A physical interface can be a T1 line, E1 line, etc., and could include the TDM timeslot. In addition, for a given interface the SG is able to identify the associated signaling channel. IUA layers on both SG and MGC maintain the status of TEIs and SAPIs.
• Status of ASPs
  The IUA layer on the SG maintains the state of the ASPs it is supporting. The state of an ASP changes because of reception of peer-to-peer messages or reception of indications from the local SCTP association.
• SCTP Stream Management
  SCTP allows a user specified number of streams to be opened during the initialization. It is the responsibility of the IUA layer to ensure proper management of these streams. Because of the unidirectional nature of streams, an IUA layer is not aware of the stream number to Interface Identifier mapping of its peer IUA layer. Instead, the Interface Identifier is in the IUA message header.
• Seamless Network Management Interworking
  The IUA layer on the SG passes an indication of unavailability of the IUA-User (Q.931) to the local Layer Management, if the currently active ASP moves from the ACTIVE state. The Layer Management could instruct Q.921 to take some action, if it deems appropriate.
• Congestion Management
  If the IUA layer becomes congested (implementation dependent), it may stop reading from the SCTP association to flow control from the peer IUA.

Header

Version
Contains the version of the IUA adaptation layer. The supported version is 1 (Release 1.0).

Message Classes and Types
The following list contains the valid message classes:

Message Class:

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

Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages

Application Server Process State Maintenance (ASPSM) messages

Application Server Process Traffic Maintenance (ASPTM) messages

Management (MGMT) Messages

Message Length
Defines the length of the message in octets including the common header.

Interested in more details about testing this protocol?

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

The M2PA protocol supports the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). M2PA is also used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages.

There is a need for Switched Circuit Network (SCN) signaling protocol delivery over an IP network. This includes message transfer between the following:

• A Signaling Gateway (SG) and a Media Gateway Controller (MGC)
• A SG and an IP Signaling Point (IPSP)
• An IPSP and an IPSP

This could allow for convergence of some signaling and data networks. SCN signaling nodes would have access to databases and other devices in the IP network domain that do not use SS7 signaling links. Likewise, IP telephony applications would have access to SS7 services. There may also be operational cost and performance advantages when traditional signaling links are replaced by IP network "connections".

The delivery mechanism described here allows for full MTP3 message handling and network management capabilities between any two SS7 nodes, communicating over an IP network. An SS7 node equipped with an IP network connection is called an IP Signaling Point (IPSP). The IPSPs function as traditional SS7 nodes using the IP network instead of SS7 links.

The delivery mechanism supports:

• Seamless operation of MTP3 protocol peers over an IP network connection.
• The MTP Level 2 / MTP Level 3 interface boundary.
• Management of SCTP transport associations and traffic instead of MTP2 Links.
• Asynchronous reporting of status changes to management.

The structure of the M2PA protocol header is as follows:

Version
The version field contains the version of M2PA. The supported version is
1 - Release 1.0 of M2PA protocol.

Message Class
The only allowed value is 11 for M2PA Messages.

Message Length
The Message Length defines the length of the message in octets, including the Common Header.

BSN
Backward Sequence Number - This is the FSN of the message last received from the peer.

FSN
Forward Sequence Number -
This is the M2PA sequence number of the User Data message being sent.

Interested in more details about testing this protocol?

M2UA

http://search.ietf.org/internet-drafts/draft-ietf-sigtran-m2ua-07.txt

M2UA is used for backhauling of SS7 MTP2-User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol is used for communication between a Signalling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. The SG acts as a Signalling Link Terminal.
The M2UA header structure is as follows:

Version
The version field contains the version of the M2UA adapation layer. The supported version is 1.0.

Spare
This field should be set to zero.

Message length
The message length defines the length of the message in octets (including the header) and includes parameter padding bytes (if there are any).

Variable-length parameter format
M2UA messages consist of a common header (described above) followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameter format is as follows:

Interested in more details about testing this protocol?

M3UA

RFC 3332 http://www.cis.ohio-state.edu/htbin/rfc/rfc3332.html

M3UA supports the transport of any SS7 MTP3-User signalling (such as ISUP and SCCP messages) over IP, using the services of the Stream Control Transmission Protocol (SCTP). The protocol is used for communication between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident database. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport.
The protocol consists of a common message header followed by parameters as defined by the message type.
The M3UA header structure is as follows:

Version
The version field contains the version of the M3UA adapation layer. The supported version is 1.0.

Reserved
This field should be set to zero.

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

Variable-length parameters
M3UA messages consist of a common header followed by zero or more variable-length parameters, as defined by the message type. The format of variable-length parameters is as follows:

Parameter length
Parameter length indicates the size of the parameter in bytes. The length includes the Parameter Tag, Parameter Length and Parameter Value fields.

Parameter value
The value of the parameter.

Interested in more details about testing this protocol?

SCTP

RFC 2960 http://www.cis.ohio-state.edu/htbin/rfc/rfc2960.html

The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services to its users:

• Acknowledged error-free non-duplicated transfer of user data.
• Application-level segmentation to conform to discovered MTU size.
• Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
• Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
• Enhanced reliability through support of multi-homing at either or both ends of the association.

The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data.

The following is the format of the SCTP header:

Source Port Number
This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.

Destination Port Number
This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Verification Tag
The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization.

For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's.

Adler 32 Checksum
This field contains an Adler-32 checksum on this SCTP datagram

Chunk Field Descriptions

The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field.

Chunk ID
The type of information contained in the chunk value field. The values of the chunk ID are defined as follows:

ID ValueChunk Type

Chunk Flags
The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified.

Chunk Length
The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk Value
This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID.

Chunk Types

Initiation (INIT)
This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk.

Initiate Acknowledgement (INIT ACK)
The INIT ACK chunk is used to acknowledge the initiation of a SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The Responder Cookie and the Unrecognized Parameter.

Selective Acknowledgement (SACK)
This chunk is sent to the remote endpoint to acknowledge received Data chunks and to inform the remote endpoint of gaps in the received subsequences of Data chunks as represented by their TSNs.
The selective acknowledgement chunk contains the highest consecutive TSN ACK and Rcv Window Credit (rwnd) parameters. By definition, the value of the highest consecutive TSN ACK parameter is the last TSN received at the time the Selective ACK is sent, before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the reporting end. This parameter therefore acknowledges receipt of all TSNs up to and including the value given.
The Selective ACK also contains zero or more fragment reports. Each fragment report acknowledges a sub-sequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.

Heartbeat Request (HEARTBEAT)
An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability of a particular destination transport address defined in the present association. The parameter fields contain the time values.

Heartbeat Acknowledgement (HEARTBEAT ACK)
An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The parameter field contains the time values.

Abort Association (ABORT)
The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in the SCTP datagram or they will be ignored.

SHUTDOWN
An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer.

Shutdown Acknowledgement (SHUTDOWN ACK)
This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters.

Operation Error (ERROR)
This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes.

State Cookie (COOKIE)
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram.

Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram.

Payload Data (DATA)
This contains the user data.

Vendor Specific Chunk Extensions
This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

Interested in more details about testing this protocol?

SUA

ftp://ftp.rfc-editor.org/in-notes/rfc3868.txt

There is on-going integration of SCN networks and IP networks. Network service providers are designing all IP architectures which include support for SS7 and SS7-like signaling protocols. IP provides an effective way to transport user data and for operators to expand their networks and build new services. In these networks, there may be some need for interworking between the SS7 and IP domains.

The Signalling Connection Control Part User Adaptation Layer (SUA) protocol details the delivery of SCCP-user messages (MAP & CAP over TCAP, RANAP, etc.) and new third generation network protocol messages over IP between two signaling endpoints. Consideration is given for the transport from an SS7 Signaling Gateway (SG) to an IP signaling node (such as an IP-resident Database) as described in the Framework Architecture for Signaling Transport. This protocol can also support transport of SCCP-user messages between two endpoints wholly contained within an IP network.

The delivery mechanism meets the following criteria:

• Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP, RANAP etc.).
• Support for SCCP connectionless service.
• Support for SCCP connection oriented service.
• Support for the seamless operation of SCCP-User protocol peers
• Support for the management of SCTP transport associations between a SG and one or more IP-based signaling nodes).
• Support for distributed IP-based signaling nodes.
• Support for the asynchronous reporting of status changes to management The protocol is modular in design, allowing different implementations to be made, based upon the environment that needs to be supported. Depending upon the upper layer protocol supported, the SUA will need to support SCCP connectionless service, SCCP connect- orient service or both services.

The header appears as follows:

Header

The message class
The following message classes are available:

Message Types
The following message types exist:

SUA Management Messages
0 Error (ERR)
1 Notify (NTFY)
2 - 127 Reserved by the IETF
128- 255 Reserved for IETF-Defined Message Class Extensions

SS7 Signaling Network Management (SSNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 SS7 Network Congestion (SCON)
5 Destination User Part Unavailable (DUPU)
6 SCCP Management (SCMG)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions

Application Server Process Maintenance (ASPM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (Down ACK)
6 Heartbeat Ack (BEAT ACK)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions

ASP Traffic Maintenance (ASPTM) Messages
0 Reserved
1 ASP Active (ACTIVE)
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions

Connectionless Messages
0 Reserved
1 Connectionless Data Transfer (CLDT)
2 Connectionless Data Response (CLDR)
3 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions

Connection-Oriented Messages
0 Reserved
1 Connection Request (CORE)
2 Connection Acknowledge (COAK)
3 Connection Refused (COREF)
4 Release Request (RELRE)
5 Release Complete (RELCO)
6 Reset Confirm (RESCO)
7 Reset Request (RESRE)
8 Connection Oriented Data Transfer (CODT)
9 Connection Oriented Data Acknowledge (CODA)
10 Connection Oriented Error (COERR)
11 Inactivity Test (COIT)
12 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions

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

Interested in more details about testing this protocol?

V5UA

ftp://ftp:rfc-editor.org/iin-notes/rfc3807.txt

There is a need for Switched Circuit Network (SCN) signaling protocol delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Controller (MGC), analogous to the implementation of the ISDN Q.921 User Adaptation Layer (IUA).

Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921 and Q.931 Adaptation layer, the IUA standard must be extended to fulfil the needs for supporting V5.2.

V5.2 is an industry standard ETSI interface (reference ETS 300 347-1) defined between a Local Exchange (LE) and an Access Network (AN) providing access to the following types:

• Analog telephone access.
• ISDN Basic rate access.
• ISDN Primary Rate access.
• Other analog or digital accesses for semi-permanent connections without associated outband signaling information.

Extending IUAP to V5UA to support V5.2 backhaul requires the introduction of new boundary primitives for the Q.921/Q.931 boundary, in accordance with the definitions in the V5 standards.

V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primitive is used for transport of both V5 Layer 3 messages and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only used for V5 ISDN messages and is used and defined as described for IUAP.

Header

Version

Contains the version of the V5UA adaptation layer. The supported version is 1 (Release 1.0).

Message Classes and Types

The following List contains the valid Message Classes:

Message Class:

The message names for the defined messages are as follows:

Management (MGMT) Messages

Application Server Process State Maintenance (ASPSM) messages

Application Server Process Traffic Maintenance (ASPTM) messages

V5 Boundary Primitives Transport Messages (V5PTM)

Interested in more details about testing this protocol?