SIGTRAN

SIGTRAN is the name, derived from signaling transport, of a defunct Internet Engineering Task Force (IETF) working group that produced specifications for a family of protocols that provide reliable datagram service and user layer adaptations for Signaling System 7 (SS7) and ISDN communications protocols. The SIGTRAN protocols are an extension of the SS7 protocol family. It supports the same application and call management paradigms as SS7 but uses an Internet Protocol (IP) transport called Stream Control Transmission Protocol (SCTP). Indeed, the most significant protocol defined by the SIGTRAN group is SCTP, which is used to carry PSTN signaling over IP.
The SIGTRAN group was significantly influenced by telecommunications engineers intent on using the new protocols for adapting VoIP networks to the PSTN with special regard to signaling applications. Recently, SCTP is finding applications beyond its original purpose wherever reliable datagram service is desired.
SIGTRAN has been published in RFC 2719, under the title Architectural Framework for Signaling Transport. RFC 2719 also defines the concept of a Signaling gateway (SG), which converts CCS messages from SS7 to SIGTRAN. Implemented in a variety of network elements including softswitches, the SG function can provide significant value to existing common channel signaling networks, leveraging investments associated with SS7 and delivering the cost/performance values associated with IP transport.

SIGTRAN protocols

The SIGTRAN family of protocols includes:

1. IUA
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:
0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
9 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined Message Class extensions

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

Q.921/Q.931 Boundary Primitives Transport (QPTM) Messages
0 Reserved
1 Data Request Message
2 Data Indication Message
3 Unit Data Request Message
4 Unit Data Indication Message
5 Establish Request
6 Establish Confirm
7 Establish Indication
8 Release Request
9 Release Confirm
10 Release Indication
11 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined QPTM extensions

Application Server Process State Maintenance (ASPSM) 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 Heatbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions

Application Server Process 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 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions




Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions

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


2. 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 Type
The following list contains the message types for the defined messages.

1
2
User Data
Link Status

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.




3. 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 class
The values for message class can be any of the following:
0
3
4
5 Management Messages (MGMT)
ASP State Maintenance Messages (ASPSM)
ASP Traffic Maintenance Messages (ASPTM)
MTP2 User Adaptation Messages (MAUP)

Message type
Management:

0
1
Error (ERR)
Notify (NTFY)

ASP State Maintenance:
1
2
4
5 ASP Up (UP)
ASP Down (DOWN)
ASP Up Ack (UP ACK)
ASP Down Ack (DOWN ACK)

ASP Traffic Maintenance:
1
2
3
4 ASP Active (ACTIVE)
ASP Inactive (INACTIVE)
ASP Active Ack (ACTIVE ACK)
ASP Inactive Ack (INACTIVE ACK)

MTP2 User Adaptatation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 Data
Establish Request
Establish Confirm
Release Request
Release Confirm
Release Indication
State Request
State Confirm
State Indication
Data Retrieval Request
Data Retrieval Confirm
Data Retrieval Indication
Data Retrieval Complete Indication
Congestion Indication
TTC Data

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:








4. 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 class
The values for Message class can be any of the following:
0
1
2
3
4
9 Management (MGMT)
Transfer Messages
SS7 Signalling Network Management (SSNM)
ASP State Maintenance (ASPSM)
ASP Traffic Maintenance (ASPTM)
Routing Key Management (RKM)

Message type
Management:
0
1 0 Error (ERR)
1 Notify (NTFY)
Transfer:
1 Payload Data (DATA)
SS7 Signalling Network Management:
1
2
3
4
5
6 Destination Unavailable (DUNA)
Destination Available (DAVA)
Destination State Audit (DAUD)
SS7 Network Congestion State (SCON)
Destination User Part Unavailable (DUPU)
Destination Restricted (DRST)
ASP State Maintenance:
1
2
3
4
5
6 ASP Up (UP)
ASP Down (DOWN)
Heartbeat (BEAT)
ASP Up Ack (UP ACK)
ASP Down Ack (DOWN ACK)
Heartbeat Ack (BEAT ACK)
ASP Traffic Maintenance:

1
2
3
4
ASP Active (ACTIVE)
ASP Inactive (INACTIVE)
ASP Active Ack (ACTIVE ACK)
ASP Inactive Ack (INACTIVE ACK)
Routing Key Management:
1
2
3
4 Registration Request (REG REQ)
Registration Response (REG RSP)
Deregistration Request (DEREG REQ)
Deregistration Response (DEREG RSP)

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 tag
The Parameter tag identifies the type of parameter.

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Reserved
Network Appearance
Protocol Data 1
Protocol Data 2
Info String
Affected Destinations
Routing Context
Diagnostic Information
Heartbeat Data
User/Cause
Reason
Traffic Mode Type
Error Code
Status Type/ID
Congestion Indications
Concerned Destination
Routing Key
Registration Result
De-registration Result
Local_Routing Key Identifier
Destination Point Code
Service Indicators
Subsystem Numbers
Originating Point Code List
Circuit Range
Registration Results
De-registration Results

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.




5. 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
00000000 Payload Data (DATA)
00000001 Initiation (INIT)
0000001 0Initiation Acknowledgment (INIT ACK)
00000011 Selective Acknowledgment (SACK)
00000100 Heartbeat Request (HEARTBEAT)
00000101 Heartbeat Acknowledgment (HEARTBEAT ACK)
00000110 Abort (ABORT)
00000111 Shutdown (SHUTDOWN)
00001000 Shutdown Acknowledgment (SHUTDOWN ACK)
00001001 Operation Error (ERROR)
00001010 State Cookie (COOKIE)
00001011 Cookie Acknowledgment (COOKIE ACK)
00001100 Reserved for Explicit Congestion Notification Echo (ECNE)
00001101 Reserved for Congestion Window Reduced (CWR)
00001110 to 11111101 - reserved by IETF
11111110 Vendor-specific Chunk Extensions
11111111 IETF-defined Chunk Extensions

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.
Fixed Parameters Status
Initiate Tag Mandatory
Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN Mandatory

Variable Parameters Status
IPv4 Address/Port Optional
IPv6 Address/Port Optional
Cookie Preservative Optional
Reserved For ECN Capable Optional
Host Name Address Optional
Supported Address Types Optional



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?




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







Version
The protocol version.

The message class
The following message classes are available:

0


Management (MGMT) Message

2


SS7 Signalling Network Management (SSNM) Messages

3


ASP State Maintenance (ASPSM) Messages

4


ASP Traffic Maintenance (ASPTM) Messages

7


Connectionless Messages

8


Connection-Oriented Messages

9


Routing Key Management (RKM) Messages

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.




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

0


Management (MGMT) Message

3


ASP State Maintenance (ASPSM) Messages

4


ASP Traffic Maintenance (ASPTM) Messages

9


V5 Boundary Primitives Transport Messages (V5PTM)

The message names for the defined messages are as follows:

Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 TEI Status Request
3 TEI Status Confirm
4 TEI Status Indication
5 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined MGMT extensions

Application Server Process State Maintenance (ASPSM) 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 Heatbeat Ack (BEAT ACK)
7 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPSM extensions

Application Server Process 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 to 127 Reserved by the IETF
128 to 255 Reserved for IETF-Defined ASPTM extensions

V5 Boundary Primitives Transport Messages (V5PTM)
1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC)
11 Link Status Start Reporting (MGC -> SG)
12 Link Status Stop Reporting (MGC -> SG)
13 Link Status Indication (SG -> MGC)
14 Sa-Bit Set Request (MGC -> SG)
15 Sa-Bit Set Confirm (SG -> MGC)
16 Sa-Bit Status Request (MGC -> SG)
17 Sa-Bit Status Indication (SG -> MGC)
18 Error Indication (SG -> MGC)