SDTI
Section: Linux STREAMS Programmer's Manual (7)
Updated: $Date: 2014/10/10 10:45:00 $
Index
Return to Main Contents
NAME
sdti - Signalling System No. 7 Signalling Data Teriminal (SDT) Interface
SYNOPSIS
#include <ss7/sdti.h>
#include <ss7/sdti_ioctl.h>
fd = open("/dev/sdt", flags);
ret = ioctl(fd, cmd, ... /* arg */ );
DESCRIPTION
This man page describes the STREAMS interface which is used to configure and
exchange data with SS7 Signalling Data Terminal Interfaces (SDTI) for all SS7
link devices conforming to the OpenSS7 Signalling Data Terminal
Interface specification.
SDTI drivers are nomally linked using streamio(7) I_PUSH ioctl
under a Signalling Link (SL) STREAMS module conforming to the Signalling Link
Interface specification, sli(7) such as sl(8), by the SS7
configuration daemon ss7d(8). Nevertheless, this interface is available
to user level programs for the purpose of Ferry-Clip testing and conformance
testing of SS7 Level 2.
SDTI Style 1 or 2 drivers may be configured to autopush the sl(8) module
and appear as sli(7) drivers. Not all SS7 drivers are written to the
SDT interface: drivers may be written to the sli(7) or slsi(7)
interfaces.
SDTI drivers which are included in the OpenSS7 release include:
- acb56(8)
-
An SDTI compliant signalling data terminal driver for the SeaLevel ACB56 card.
- soip(8)
-
An SDTI compliant signalling data terminal emulator over UDP for SS7/IP.
- m2tp(8)
-
An SDTI compliant signalling data terminal emulator for MTP Level 2 Tunneling
Protocol (M2TP) for SS7/SCTP.
The SDTI interface consists of three components:
- LOCAL MANAGEMENT INTERFACE
-
A local management interface which utilizes M_PROTO and M_PCPROTO
messages which can be exchanged using the putmsg(2) and getmsg(2)
functions on the stream head once the driver is opened.
This interface controls local management (STREAMS configuration functions)
which are normally used by the SS7 configuration daemon ss7d(8) on the
driver before pushing an sl(8) module onto the stream head. This
interface is described in the section LOCAL MANAGEMENT INTERFACE.
- PRIMITIVE INTERFACE
-
A protocol primitive interface which utilizes M_DATA, M_PROTO and
M_PCPROTO messaages which can be exchanged with the stream head using
putmsg(2) and getmsg(2) functions on the stream head, or which may
be exchanged with the driver by upstream pushed or linked modules.
This interface exchanges SS7 protocol primitives between the signalling link
and the signalling data terminal, but may be used for Ferry-Clip testing or
specialized applications (e.g. user space M2TP inetworking functions).
This interface is described in the section PRIMITIVE INTERFACE.
- IOCTL INTERFACE
-
An ioctl interface which utilizes ioctl(2) or an I_STR ioctl from
streamio(2) from a stream head for a stream to the driver.
This interface controls specific aspects of the signalling link driver which
are outside the scope of the SS7 protocol such as interface configuration and
is normally used by the SS7 configuration daemon ss7d(8) or upstream
modules during driver operation.
This interface is described in the section IOCTLS.
LOCAL MANAGEMENT INTERFACE
The OpenSS7 Signalling Link Interface (SLI) defines M_PROTO or
M_PCPROTO protocol primtives which can be sent using putmsg(2) or
received using getmsg(2). This interface is normally used only by the
ss7d(8) during STREAMS configuration, or by the upstream protocol
modules during streamio(7) I_PUSH and I_POP operations,
but for testing or special applications (e.g. M2TP) it is possible for a user
level program to use this interface directly on an open SDTI driver stream
head.
PPA Style
The SDT Provider can support one of two styles of PPA (Physical Point of
Attachment). These styles are as follows:
- SDT_STYLE1
-
A Style 1 driver is a driver whose SDL (Signalling Data Link) is associated
with the stream head at open time. These drivers open in the
SDT_DISABLED state and do not require a SDT_ATTACH_REQ local
management primitive to associate them with an SDL. Style 1 drivers do not
require PPA addresses.
- SDT_STYLE2
-
A Style 2 driver is a driver whose SDL must be attached to the stream after
open. These drivers open in the SDT_UNATTACHED state and must be
attached with a SDT_ATTACH_REQ local management primitive before they
can be enabled. Style 2 drivers require a PPA address to indicate the PPA
(Physical Point of Attachment) address to which the stream has been attached.
The PPA Address is an opaque address which is meaningful only to a specific
driver implementation of the SDTI.
Local Management States
From the perspective of local management, the SDT provider can be in a number
of management states. Some local management primitives are applicable in only
on state. The SDT provider can be moved through the states with local
management primitives.
The management states of the SDT provider are as follows:
- SDT_UNATTACHED
-
The interface is not attached. It is not attached to a Signalling Data Link
(SDL). This state is only applicable to Style 2 device drivers which
must be explicitly attached to the SDL. Style 1 drivers open in the
SD_DISABLED state an cannot be detached.
- SDT_UNUSABLE
-
The interface is unusable. This may be due to the attached SDL being no
longer usable or the device being rendered unusable due to some other reason
(i.e. removal from the system).
- SDT_DISABLED
-
The interface has been attached but has not yet been enabled for use. The
device must be enabled with a SDT_ENABLE_REQ local management primitive
before data or protocol primitives can be exchanged across the interface.
- SDT_ENABLE_PENDING
-
An enable has been initiated on the interface but the provider must wait until
an event occurs before the provider can be considered enabled. The provider
will respond with an SDT_ENABLE_CON once the enabling is successful, or
an SDT_ERROR_IND if it has not.
- SDT_ENABLED
-
The device is enabled and ready for use.
- SDT_DISABLE_PENDING
-
A disable has been initiated on the interface but the provider must wait until
an event occurs before the provider can be considered disabled.
The provider will respond with a SDT_DISABLE_CON once the disabling is
successful, or an SDT_ERROR_IND if it has not.
Local Management Primitives
Local management primitives can be exchanged with the device driver as
M_PROTO or
M_PCPROTO primitives using the
putmsg(2) or
getmsg(2) system calls on the stream head. This interface is normally
used only by the SS7 Configuration Daemon
ss7d(8) during STREAMS
configuration, or by the upstream protocol modules during
streamio(7)
I_PUSH and
I_POP operations, but for testing or special
applications, it is possible for a user level program to use this interface
directly on an open SDTI driver stream head.
It should be noted that only M_PROTO local management primitives will be
deferred during congestion of the SDT provider. Local management primitives
sent as M_PCPROTO will receive a SDT_ERROR_ACK in response should
it not be possible to execute them immediately.
Local management primitives provided by SDTI are as follows:
- SDT_INFO_REQ, SDT_INFO_ACK
-
Request and returns information about the SDTI driver which is of interest to
local configuration management (i.e. the ss7d(8)). These requests are
normally performed by the ss7d(8) on the open streamhead for the SDTI
driver before pushing it beneath the Level 2 module.
The SDT_INFO_REQ takes an sdt_info_req_t structure as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_INFO_REQ */
} sdt_info_req_t;
The SDT_INFO_ACK returns an sdt_info_ack_t structure as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_INFO_ACK */
sdt_ulong sdt_version;
sdt_ulong sdt_state;
sdt_ulong sdt_max_sdu;
sdt_ulong sdt_min_sdu;
sdt_ulong sdt_ppa_style;
sdt_uchar sdt_ppa_addr[8];
sdt_ulong sdt_bitrate;
sdt_conf_t sdt_config;
} sdt_info_ack_t;
-
- sdt_version
-
Provides the version of the SDTI interface specification to which the driver
conforms with one byte per version number. The current (and only) version of
the SDTI is 1.0.0.0. or 0x01000000 in host order.
- sdt_min_sdu, sdt_max_sdu
-
Reflect the minimum and maximum frame sizes which may be transferred to and
from the interface. In SS7 this is not a negotiated value: it is determined
by the type of SDL (Signalling Data Link) which is provided by the interface.
- sdt_ppa_style, std_ppa_addr
-
Indicate the style of driver as follows:
-
- SDT_STYLE1
-
A Style 1 driver is a driver whose SDL (Signalling Data Link) is associated
with the stream head at open time. These drivers open in the
SDT_DISABLED state and do not require an SDT_ATTACH_REQ to
associate them with a Signalling Data Link. For Style 1 drivers, the
sdt_ppa_addr member is meaningless.
- SDT_STYLE2
-
A Style 2 driver is a driver whose SDL must be attached to the stream after
open. These drivers open in the SDT_UNATTACHED state and must be
attached with an SDT_ATTACH_REQ local management primitive before they
can be enabled. The sdt_ppa_addr member indicate which PPA (Physical
Point of Attachment) address to which the stream has been attached. The PPA
is an opaque address which is meaningful to a specific driver.
- sdt_bitrate
-
Indicates the bit rate on the line in bits per second (bps). This value may
be used by the ss7d(8) to calculate the durations of timers and other
bitrate-dependent parameters.
- sdt_config
-
Contains SS7 Initial Alignment Control (IAC),
Alignment Error Rate Monitor (AERM), Signal Unit Error Rate Monitor (SUERM)
and Errored Interval Monitor (EIM) parameters and thresholds. These values
determine the operating characteristics of these SS7 Level 2 state machines
and are normally set by the ss7d(8) using the SDT_CONFIG_REQ
primitive.
- SDT_CONFIG_REQ, SDT_CONFIG_ACK, SDT_ERROR_ACK
-
Request that the SS7 Level 2 configuration parameters and thresholds be
configured as specified in the sdt_config_req_t structure
defined in <ss7/sdti.h> as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_CONFIG_REQ */
sdt_conf_t sdt_config;
} sdt_config_req_t;
The members of sdt_config are SS7 Initial Alignment Control (IAC),
Alignment Error Rate Monitor (AERM) and Signal Unit Error Rate Monitor (SUERM)
parameters and thresholds. These values determine the operating
characteristics of these SS7 Level 2 state machines. Their current values may
be examined with the SDT_INFO_REQ primitive.
The SDT_CONFIG_ACK indicates that the previous SDT_CONFIG_REQ was
successful and uses the sdt_config_ack_t structure defined in
<ss7/sdti.h> as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_CONFIG_ACK */
} sdt_config_ack_t;
- SDT_ATTACH_REQ, SDT_OK_ACK, SDT_ERROR_ACK
-
Requests that a Style 2 SDTI be attached to a Signalling Data Link (SDL).
This request uses an sdt_ppa_addr which specifies the PPA (Physical
Point of Appearance) of the SDL to which the SDT should be attached. This is
an opaque address to the interface and is only meaningful to a specific driver
implementation.
The SDT_ATTACH_REQ primitive is only valid from the SDT_UNATTACHED
state of the interface and takes an sdt_attach_req_t structure defined
in <ss7/sdti.h> as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_ATTACH_REQ */
sdt_uchar sdt_ppa_addr[8];
} sdt_attach_req_t;
When successful an SDT_OK_ACK is returned, otherwise an
SDT_ERROR_ACK is returned with the errno and reason set to
one of the values in Section ERRORS.
- SDT_DETACH_REQ, SDT_OK_ACK, SDT_ERROR_ACK
-
Requests that a Style 2 SDTI be detached from its Signalling Data Link (SDL).
This request is only valid from the SDT_ATTACHED state of the interface
and takes an sdt_detach_req_t structure defined in <ss7/sdti.h> as
follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_DETACH_REQ */
} sdt_detach_req_t;
When successful an SDT_OK_ACK is returned, otherwise an
SDT_ERROR_ACK is returned with the errno and reason set to
one of the values in Section ERRORS.
- SDT_ENABLE_REQ, SDT_ENABLE_CON, SDT_ERROR_ACK
-
Requests that the interface be enabled for operation.
This request is only valid from the SDT_DISABLED state of the interface
and takes an sdt_enable_req structure defined in <ss7/sdti.h> as
follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_ENABLE_REQ */
sdt_ulong sdt_rx_init;
sdt_ulong sdt_tx_init;
} sdt_enable_req_t;
The sdt_rx_init and sdt_tx_init specify what the initial state of
the receivers and transmitters should be when the interface is enabled. The
receivers can be initialized in any of the following states (all values are
not necessarily supported by all drivers):
-
- SDT_RX_OFF
-
Initializes the receivers but keeps them detached from the line. The
receivers do not synchronize with flags or generate any indications to the
driver.
- SDT_RX_NONE
-
Leaves the receivers in the state that they were before the
SDT_ENABLE_REQ command. This permits an SDT_DISABLE_REQ followed
by an SDT_ENABLE_REQ without changing the state of the receiver. The
first initialization of the receiver leaves it in the default state
SDT_RX_OFF.
- SDT_RX_DISABLE
-
Turns on the receiver interrupt service routine but disables the transfer of
frames from the driver. Other internal indications (such as loss of sync) are
detected and reported internally to the driver.
-
The transmitters can be initialized in any of the following states (all values
are not necessarily supported by all drivers):
-
- SDT_TX_OFF
-
Initializes the transmitters but keeps then disconnected from the line (i.e.
allows the Tx line to float). The transmitters do not generate flags or any
other idle character on the line.
- SDT_TX_NONE
-
Leaves the transmitters in the state that they were befoer the
SDT_ENABLE_REQ command. This permits an SDT_DISABLE_REQ followed
by an SDT_ENABLE_REQ without changing the state of the transmitter. The
first initialization of the transmitter leave it in the default state
SDT_TX_OFF.
- SDT_TX_IDLE_MARK, SDT_TX_IDLE_SPACE, SDT_TX_IDLE_FLAG
-
Initializes the transmitter and attaches it to the line but configures it to
idle mark 0xff (space 0x00 or flag 0x7e). The transmit interrupt service
routine can be disabled if the serial controller chip is capable of idling
mark (space or flag) on its own.
- SDT_TX_IDLE_FISU, SDT_TX_IDLE_SIOS
-
Initializes the transmitter and attaches it to the line but configures it to
idle a FISU (or LSSU SIOS). The value of the BIB/BSN FIB/FSN in the FISU (or
LSSU SIOS) is determined by the last transmitted MSU on the interface. The
transmit interrupt service routine can be enabled if the serial controller
chip is incapable of idling FISU on its own.
-
When successful an SDT_ENABLE_CON is returned, otherwise an
SDT_ERROR_ACK is returned with the errno and reason set to
one of the values in Section ERRORS.
- SDT_DISABLE_REQ, SDT_DISABLE_CON, SDT_ERROR_ACK
-
Requests that the interface be disabled from operation.
This requiest is only valid from the SDT_ENABLED state of the interface
and takes an sd_disable_req_t structure defined in <ss7/sdti.h> as
follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_DISABLE_REQ */
sdt_ulong sdt_rx_disp;
sdt_ulong sdt_tx_disp;
} sdt_disable_req_t;
The sdt_rx_disp and sdt_tx_disp specify the disposition of the
receiver and transmitter when the interface is disabled. The receiver can be
left in any of the following states (all values are not necessarily supported
by all drivers):
-
- SDT_RX_OFF
-
Shuts down the receiver and detaches it from the line. The receiver no longer
synchronize with flags or generate any indications to the driver. The
receiver interrupt service routine is disabled.
- SDT_RX_NONE
-
Leaves the receiver in the state that it was before the
SDT_DISABLE_REQ command. The receivers are disabled from transferring
received SUs across the SDT interface.
- SDT_RX_DISABLE
-
Disables the receivers and the transfer of received SUs to the upper level
state machines, but continues to monitor the line and sychronize with flags.
-
The transmitter can be left in any of the following states (all values are not
necessarily supported by all drivers):
-
- SDT_TX_OFF
-
Shuts down the transmitter and detaches it from the line. The transmitter
does not generate any bits and the line is allowed to float.
- SDT_TX_NONE
-
Leaves the transmitter in the state that it was before the
SDT_DISABLE_REQ command. The transmitter no longer accepts SUs for
transmission from the SDT interface. If the transmitter was idling an LSSU it
continues to idle that LSSU. If the transmitter was idling a FISU, it
continues to idle that FISU. It the transmitter was sending an MSU, it
completes transmission of the MSU and then idles a FISU with the same BIB/BSN
FIB/FSN as the last transmitted MSU.
- SDT_TX_IDLE_MARK, SDT_TX_IDLE_SPACE, SDT_TX_IDLE_FLAG
-
Shuts down the transmit interrupt service routine, but configures the
transmitter to idle mark, space or flags as indicated by the specific
value above.
- SDT_TX_IDLE_FISU, SDT_TX_IDLE_SIOS
-
Disables the ability to transfer SUs across the SDT interface for
transmission and configures the transmitter (and TxISR if necessary) to idle
a FISU (or LSSU SIOS) with the BIB/BSN FIB/FSN of the last transmitted FISU or
MSU.
-
When successful an SDT_DISABLE_CON is returned, otherwise an
SDT_ERROR_ACK is returned with the errno and reason set to
one of the values in Section ERRORS.
- SDT_STATUS_REQ, SDT_STATUS_ACK, SDT_ERROR_ACK
-
This request and acknowledgement permit the SDT user to interrogate the state
of any of the state machines in the SDT. This is particularly important for
SDT users which may loose communications with the SDT provider and need to
resynchronize state between the user and provider. It may also be used for
diagnostic, debuggin or ferry-clip testing purposes when the state of the
internal state machines of the SDT provider need be examined.
The SDT_STATUS_ACK primitive
contains the sdt_status_ack_t type structure defined in
<ss7/sdti.h> as follows:
-
-
typedef struct {
sdt_ulong sdt_primitive; /* SDT_STATUS_ACK */
sdt_statem_t sdt_statem;
} sdt_status_ack_t;
typdef struct sdt_statem {
sdt_ulong daedt_state;
sdt_ulong daedr_state;
sdt_ulong octet_counting_mode;
sdt_ulong aerm_state;
sdt_ulong Ca;
sdt_ulong Ti;
sdt_ulong suerm_state;
sdt_ulong Cs;
sdt_ulong Ns;
sdt_ulong eim_state;
sdt_ulong Ce;
sdt_ulong su_received;
sdt_ulong interval_error;
} sdt_statem_t;
The members of the sdt_statem structure are interpreted as follows:
- daedt_state
-
Provides the total state of the DAEDT (Delimitation Alignment and Error
Detection Transmitting) per Q.703. This member can take on values
SDT_STATE_IDLE or SDT_STATE_IN_SERVICE.
- daedr_state, octet_counting_mode
-
Provides the total state of the DAEDR (Delimitation Alignment and Error
Detection Receiving) per Q.703. The daedr_state member can take on
values SDT_STATE_IDLE or SDT_STATE_IN_SERVICE. The
octet_counting_mode member is a flag which indicates that the DAEDR is
in octet counting modes as defined by Q.703 when non-zero and in normal mode
when zero.
- aerm_state, Ca, Ti
-
Provides the total state of the AERM (Alignment Error Rate Monitor) per Q.703.
The aerm_state member can take on values SDT_STATE_IDLE or
SDT_STATE_MONITORING. The Ca member provides the current count of
errored SUs for the interval that the AERM has been monitoring and the
Ti member provides the current threshold (either Tin or Tie)
to which the error count is being compared.
- suerm_state, Cs, Ns
-
Provides the total state of the SUERM (Signal Unit Error Rate Monitor) per
Q.703. The suerm_state member can take on values SDT_STATE_IDLE
or SDT_STATE_MONITORING. The Cs member provides the current
time-weighted ratio of errored SUs to correct SUs and Ns provides the
number of above error threshold intervals which remain before link failure.
- eim_state, Ce, su_received, interval_error
-
Provides the total state of the EIM (Errorred Interval Rate Monitor) per Q.703
Annex A. The eim_state member can take on values SDT_STATE_IDLE
or SDT_STATE_MONITORING. The Ce member provides the current
time-weighted ration of errored intervals to error-free intervals. The two
flags su_received and interval_error are used to indicate whether
there is an error at this point in time in the current interval.
If it is not possible to retreive the state of the SDT provider, the provider
will return an SDT_ERROR_ACK containing the sdt_errno and
sdt_reason indicating the problem. Normally it is possible to retreive
state information at any time.
PRIMITIVE INTERFACE
The OpenSS7 Signalling Link Interface (SLI) defines M_PROTO or
M_PCPROTO protocol primitives which can be sent using putmsg(2) or
received using getmsg(2). This interface is normally used only for
module to module communications within the STREAM SS7 stack, but for testing
or special application purposes, it is possible to open a module implementing
the Signalling Link Interface and exchange these messages directly with a user
level program.
Some primitives require a data (M_DATA) part when
indicated. Many primitives do not have arguments in the control
(M_PROTO or M_PCPROTO) part and the control part only contains the
sdt_primitive. Where additional arguments are required in the control
part, those arguments and the control part datastructure are indicated.
Downstream primitives (requests, responses) can be sent using putmsg(2).
No response is provided to properly formatted primitives outside of the scope
of the protocol (i.e. no SDT_OK_ACK). Improperly formatted primitives
receive the errors described in under ERRORS. All downstream messages
must be sent as regular (M_PROTO) or priority messages
(M_PCPROTO). SDT_SIGNAL_UNIT_REQ may also be sent as a data only
(M_DATA) message using putmsg(2) with no control part or
write(2). The only downstream message which contains a data
(M_DATA) part is the SDT_SIGNAL_UNIT_REQ message. Any data part
in the other request primitives will be ignored.
Upstream primitives (indications, confirmations) are sent from the Signalling
Data Terminal Interface provider to the user of the module. These are
normally priority (M_PCPROTO) messages with the exception of
SDT_SIGNAL_UNIT_IND messages. A number of these primtives are provided
in response to the downstream primtives as described below. The only upstream
message which contains a data (M_DATA) part is the
SDT_SIGNAL_UNIT_IND message. Any data part in the other indication
primitives should be ignored. The SD_SIGNAL_UNIT_IND message is normally
sent as a data only (M_DATA) message and should be collected using
getmsg(2) not expected a control part or read(2).
Protocol primitives are as follows:
- SDT_SIGNAL_UNIT_REQ, SDT_SIGNAL_UNIT_IND (M_DATA)
-
This request and indication provide an SU (Signal Unit) for transmission (or
received) in the data (M_DATA) part of the message. The SU represents
all of the bytes between the opening flag and the CRC bits in the transmitted
(received) frame. The SDT_SIGNAL_UNIT_IND is not normally used by the
driver, received SUs are normally transferred upstream using M_DATA
messages. Although recognized by the driver, the SDT_SIGNAL_UNIT_REQ
should not normally be used by the module above this driver. Transmitted SUs
should be normally transferred downstream using M_DATA messages.
- SDT_DAEDT_START_REQ
-
This request starts the DAEDT state machine in the SDT within the SS7
protocol. The DAEDT state machine is essentially the transmitter. If the
transmitter was left in one of the idle states (SDT_STATE_IDLE), it is
moved to the in service state (SDT_STATE_IN_SERVICE).
- SDT_DAEDR_START_REQ
-
This request starts the DAEDR state machine in the SDT within the SS7
protocol. The DAEDR state machine is essentially the receiver. If the
receiver was left in one of the idle states (SDT_STATE_IDLE), it is
moved to the in service state (SDT_STATE_IN_SERVICE).
- SDT_DAEDR_CORRECT_SU_IND
-
This is an indication which is given from the DAEDR to the IAC (Initial
Alignment Control) above the SDT interface to indicate that a correct SU has
been received immediately after an SDT_AERM_ABORT_PROVING_IND has been
indicated. This SU indication is necessary to trigger the next proving period
of the IAC if further proving is required.
- SDT_AERM_START_REQ, SDT_AERM_STOP_REQ
-
These requests start and stop the AERM (Alignment Error Rate Monitor) within
the SS7 protocol implemented in the SDT.
- SDT_AERM_SET_TI_TO_TIN_REQ, SDT_AERM_SET_TI_TO_TIE_REQ
-
These request set the value of Ti in the AERM to either the normal threshold
value (Tin) or the emergency threshold value (Tie). This is used to indicate
to the SDT whether error rate monitoring should be performed on a normal or
emergency basis.
- SDT_AERM_ABORT_PROVING_IND
-
This indication is given from the AERM when it detects that the number of
SU errors received has exceeded the current Ti threshold.
- SDT_SUERM_START_REQ, SDT_SUERM_STOP_REQ
-
These requests start and stop the SUERM (Signal Unit Error Rate Monitor)
within the SS7 protocol implemented in the SDT.
- SDT_SUERM_LINK_FAILURE_IND
-
This indication is given from the SUERM (Signal Unit Error Rate Monitor)
within the SS7 protocol implemented in the SDT.
- SDT_LINK_CONG_IND, SDT_NO_LINK_CONG_IND
-
These indications are given from the SDT to the signalling link when the
driver detects that it can no longer keep up with the receive SU stream.
An indicatoin of SDT_LINK_CONG_IND is assumed to be at the discard
level.
IOCTLS
OpenSS7 supports some standard ioclts to configure SS7 Signalling Data
Terminal Interface (SDTI) device drivers. They must be used on a stream which
is attached to the device to which the ioctl applies, or passed through a
multiplexor (e.g. MTP, SLS) using pass through IOCTLs of the multiplexor (see,
mtpi(7) and slsi(7)).
If an ioctl is indicated as privileged, then using it requires sufficient
access credentials. If this is not the case, EPERM will be returned.
- SDT_IOCSIFMODE, SDT_IOCGIFMODE
-
Sets or gets the mode of the interface. Some of these modes are applicable to
V.35 interfaces only, some are applicable to E1/T1/J1 interfaces only.
arg indicates modes of the interface which can be one of the following:
-
- SDT_MODE_DCE
-
Indicates a V.35 interface in Data Control Equipment mode. This defines the
sense and direction of the various leads on the V.35 interface. This is the
normal operating mode when connecting a V.35 interface from the host to a V.35
modem or channel bank.
- SDT_MODE_DTE
-
Indicates a V.35 interface in Data Terminal Equipment mode. This defines the
sense and direction of the various leads on the V.35 interface.
- SDT_MODE_LOOP
-
Indicates a V.35 or E1/T1/J1 channel in loopback mode. In loopback mode all
received bits on the Rx lead are looped back to the Tx lead.
- SDT_MODE_JACK
-
Indicates a V.35 interface in loopback jack mode. In this mode, a loopback
jack is used to loop Tx bits back to Rx bits. This mode sets the sense of
other leads and clocking to permit use of a loopback jack.
- SDT_MODE_ECHO
-
Indicates a V.35 interface in echo mode. In this mode all bits transmitted on
the Tx lead are looped back to the Rx lead.
- SDT_MODE_BOTH
-
Indicates a V.35 interface into both loopback and echo modes. This is not too
useful.
If arg is inappropriate for the interface type, the the ioctl returns
EINVAL to the caller.
- SDT_IOCSIFCLOCK, SDT_IOCGIFCLOCK
-
Sets or getst the clocking mode of the interface. Some of these modes are
applicable to V.35 interfaces only, some are applicable to E1/T1/J1 interfaces
only. arg indicates clocking modes of the interface which can be one of
the following:
-
- SDT_CLOCK_EXT
-
Indicates a V.35 interface in external clocking mode. This means that the
interface will use the external clock leads for synchronizing the Tx bitstream
as well as for generating the Rx bitstream.
- SDT_CLOCK_INT
-
Indicates a V.35 interface in internal clocking mode. This means that the
interface will use and internal clock source to syncrhonize both the Rx and Tx
bitstreams.
- SDT_CLOCK_DPLL
-
Indicates a V.35 interface in digital phase locked loop mode. This means that
the interface will use a DPLL syncrhonized to the Tx bitstream to regenerate
an internal clock for both Tx bitstream sampling as well as Rx bitstream
pulse generation.
- SDT_CLOCK_SLAVE
-
Indicates an E1/T1/J1 interface in slave mode. This means that the local
clock will be derived from the Rx stream and used to sample both Rx and
generate Tx bitstreams. This applies to then entire E1/T1/J1 interface (not
just this channel).
- SDT_CLOCK_MASTER
-
Indicates an E1/T1/J1 interface in master mode. This means that a local clock
will be used to sample the Rx stream as well as generate Tx timings. This
applies to the entire E1/T1/J1 interface (not just the channel).
- SDT_CLOCK_LOOP
-
Indicates an E1/T1/J1 interface in loop mode. This means that a local clock
will be syncrhonized to the Rx stream and regenerated (using a phase locked
loop) to sample the Rx stream as well as generate Tx stream timings. This
applies to the entire E1/T1/J1 interface (not just the channel).
If arg is inappropriate for the interface type, the ioctl returns
EINVAL to the caller.
- SDT_IOCSIFLEAD, SDT_IOCGIFLEAD
-
Sets or gets the state of the leads of a V.35 interface. arg is a
bitmask indicating the the state of the leads on a get and the state in which
to place the lead for a get. Some leads cannot be set by SDT_IOCSIFLEAD
but only read with SDT_IOCGIFLEAD. arg is a bitwise or of the
following bitmasks, where a one in the mask position indicates a lead which is
`true' and a zero in the mask position indicates a lead which is `false'
regardless of whether the lead is high-true or low-true.
-
- SDT_LEAD_DTR
-
Data-terminal-ready lead.
This lead can be set or get and indicates the (desired) state of the DTR lead
on the V.35 interface.
- SDT_LEAD_RTS
-
Request-to-send lead.
This lead can be set or get and indicates the (desired) state of the RTS lead
on the V.35 interface.
- SDT_LEAD_DCD
-
Data-carrier-detect lead.
This lead can only be read and indicates the state of the DCD lead on the V.35
interface.
- SDT_LEAD_CTS
-
Clear-to-send lead.
This lead can only be read and indicates the state of the CTS lead on the V.35
interface.
- SDT_LEAD_DSR
-
Data-set-ready lead.
This lead can only be read and indicates the state of the DSR lead on the V.35
interface.
- SDT_IOCCBRKTXLINE, SDT_IOCCCONTXLINE
-
These ioctls simulate breaking and reconnecting the transmit line. These are
for the purpose of automated testing only (Q.781 conformance tests require the
ability to break and reconnect the Tx channel as part of the testing) and
provides a means to automatically break and reconnect the Tx line. These
ioctls should not be used during normal operation of the link. The arg
is ignored for these ioctls.
- SDT_IOCCIFSTATS
-
Clears the interface statistics. This resets the statistics counts to zero.
In addition, the arg argument to the ioctl indicates a number of clock
ticks at which the statistics accumulators should be synchronized. This is
normally the number of ticks on the UNIX system clock at the time that the
last 30 minute interval occured. The statistics accumulators in the driver
will use this value to determine when the next accumulation interval should
start.
- SDT_IOCSIFSTATSP
-
Sets the duration of the accumulation period to arg. The accumulation
period is the duration of time for which counts will be allowed to increase.
After this period has expired (in syncrhonization with the value provided in
SDT_IOCCSTATS, above) the counts will be collected and the running counts
reset to zero for the next period. Typically, this period should be set to 5
minutes or 30 minutes in accordance with ITU-T Recommendation Q.752, but can
be set to any value. Setting this value too low could have an impact
on system performance. A value of zero (0) defeat periodic accumulation and
all accumlators will have counts which reflect the number of occurences since
the last time that the statistics counts were reset with SDT_IOCCSTATS.
- SDT_IOCGIFSTATS
-
Get the interface statistics for the last (expired) accumulation period when
the accumulation period is non-zero; otherwise, it return the current
interface statistics. When accumulation period is non-zero, is is the
responsibility of the interface user to collect statistics in a timely manner.
- SDT_IOCSCONFIG, SLIOCGCONFIG
-
Sets or gest the configuration information for the signalling link. Both set
and get takes a pointer to a sdt_config_t structure. For setting the
configuration, the caller must complete this structure which the driver uses
to set the appropriate configuration parameters. Both the set and get return
the resulting (current) configuration to the struct pointed to by arg.
The structure type sdt_config_t is defined in <ss7/sdti_ioctl.h> as
follows:
typedef struct {
sdt_ulong pvar; /* Protocol Variant */
sdt_ulong popt; /* Protocol Options */
sdt_ulong M; /* IAC proving */
sdt_ulong Tin; /* AERM norm thres */
sdt_ulong Tie; /* AERM emerg thres */
sdt_ulong T; /* SUERM threshold */
sdt_ulong D; /* SUERM rate parm */
sdt_ulong N; /* octets/SU error */
sdt_ulong t8; /* EIM interval timer */
sdt_ulong Te; /* EIM threshold */
sdt_ulong De; /* EIM downcount */
sdt_ulong Ue; /* EIM upcount */
} sdt_conf_t;
Any value which is set to 0xffffffff will not affect the current or
default configuration. By setting values to 0xffffffff it is possible
to affect only a select few of the members for modification in the
configuration. if no members are changed from the current setting (i.e. all
members are set to 0xffffffff) all values will take on the default
values assigned by the driver.
The members in the sdt_config_t structure are interpreted as follows:
-
- pvar
-
This indicates the protocol variant which the Signalling Data Terminal is
expected to support. This may be any of the protocol variant values described
in ss7(7). When this member alone is changed, the other members of the
configuration are defaulted to the default value of the specifications
associated with the protocol variant selected.
- popt
-
This is a bit-vector of protocol options which may be enabled or disabled on
the SDTI interface. Currently there is only one protocol option as follows:
-
- SDT_POPT_EIM
-
When set, this option bit indicates that the EIM (Errored Interval Monitor) of
Q.703 Annex A should be used instead of the SUERM (Signal Unit Error Rate
Monitor) of the main Q.703. This option is required for high-speed links.
- M
-
This is the number of proving cycles that the IAC (Initial Alignement Control)
will perform during normal alignment. This value is normally set to 5
according to specifications.
- Tin, Tie
-
These are the AERM (Alignment Error Rate Monitor) thresholds for normal and
emergency alignment. They are unitless integer values. These values are
normally set to Tin = 4 and Tie = 1 according to specifications.
- T, D, N
-
This is the error threshold (T), the error rate parameter (D) and
the number of octets per SU error indication in octet counting mode (N)
associated with the SUERM (Signal Unit Error Rate Monitor) of Q.703. These
are unitless values and must normally be set to 32 or 64, 256, and 16
respectively to meet specifications.
- t8, Te, De, Ue
-
This is the interval time t8, the error threshold Te, the correct
interval downcount De and the errored interval upcount Ue
associated with the EIM (Errorred Interval Monitor) state machine of Q.703
Annex A. The time interval t7 is in jiffies, and the other numbers
unitless numbers which are decimal numbers represented as an integer by
multiplying the recommendations of Q.703 Annex A by 1000 and rounding to
obtain an integer value.
ERROR HANDLING
When successful, a local management primitive will return an acknowledgement
which is paired with the request. A number of local management primitives are
paired with the
SDT_OK_ACK primitive which is returned on success. The
format of the
SDT_OK_ACT primitive uses the
sdt_ok_ack_t structure
defined in
<ss7/sdti.h> as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_OK_ACK */
sdt_ulong sdt_state;
sdt_ulong sdt_correct_primitive;
} sdt_ok_ack_t;
The sdt_state member returns the current state of the interface. The
local management states of the interface are described in
LOCAL MANAGEMENT PRIMITIVES. The sdt_correct_primitive member
returns the primitive identifier of the primitive which was successful.
When the local management primitive operation is unsuccessful, the SDT
provider returns a SDT_ERROR_ACK acknowledgement indicating
the primitive in error (sdt_error_primitive), the state of the interface
(sdt_state) and the error number (sdt_errno) and explanation
(sdt_reason) of the error encountered. The format of the
SDT_ERROR_ACK primitive uses the sdt_error_ack_t structure defined
in <ss7/sdti.h> as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_ERROR_ACK */
sdt_ulong sdt_state;
sdt_ulong sdt_error_primitive;
sdt_ulong sdt_errno;
sdt_ulong sdt_reason;
} sdt_error_ack_t;
The SDTI is also capable of indicating an error condition which is not related
to a specific request. When such an error condition is encountered, the
interface returns a SDT_ERROR_IND primitive indicating the state of the
interface (sdt_state) and the error number (sdt_error) and
explanation (sdt_reason) of the error encountered. The format of the
SDT_ERROR_IND primitive uses the sdt_error_ind_t structure defined
in <ss7/sdti.h> as follows:
typedef struct {
sdt_ulong sdt_primitive; /* SDT_ERROR_IND */
sdt_ulong sdt_state;
sdt_ulong sdt_errno;
sdt_ulong sdt_reason;
} sdt_error_ind_t;
ERRORS
Error numbers and reasons which may be returned in the
SDT_ERROR_ACK or
SDT_ERROR_IND primitives are as follows:
- ERROR NUMBERS
-
The following error numbers may be returned in the sdt_errno member of
the SDT_ERROR_ACK or SDT_ERROR_IND primitive:
-
- SDT_BADDISPOSAL
-
Bad disposal parameter. This means that the value of the sdt_rx_init,
sdt_tx_init, sdt_rx_disp or sdt_tx_disp parameter of an
SDT_ENABLE_REQ or an SDT_DISABLE_REQ was not a listed value.
- SDT_BADFRAME
-
A bad frame was delivered to the driver with SDT_SIGNAL_UNIT_REQ.
Either the size was smaller than that provided for in sdt_min_sdu or
larger than that provided for in sdt_max_sdu which can be discovered
in an SDT_INFO_ACK.
This is normally provided in an SDT_ERROR_ACK to an
SDT_SIGNAL_UNIT_REQ or as an SDT_ERROR_IND to an M_DATA.
- SDT_BADPPA
-
The PPA (Physical Point of Appearance) address provided in an
SDT_ATTACH_REQ was invalid. The error reason may provide more
information.
This is normally provided in an SDT_ERROR_ACK.
- SDT_BADPRIM
-
The primitive provided in an M_PROTO or M_PCPROTO command is not
and expected value. This is normally provided in an SDT_ERROR_ACK.
- SDT_DISC
-
The primitive cannot be completed because the link is not in the
SDT_STATE_IN_SERVICE state. This is normally provided in an
SDT_ERROR_IND in response to one of M_PROTO primitives when the
interface has not been attached by SDT_ATTACH_REQ and enabled by
SDT_ENABLE_REQ.
- SDT_EVENT
-
Some protocol specific event occured which does not permit the operation.
- SDT_FATALERR
-
A fatal error occured in the device or driver. This error is not recoverable
and will result in the generation of an M_ERROR indication.
- SDT_INITFAILED
-
Initialization of the device or driver failed. This is normally in an
SDT_ERROR_ACK response to a local management primitive.
- SDT_NOTSUPP
-
The primitive is not supported by this particular device or driver. This is
normally returned in an SDT_ERROR_ACK to a local management primitive
and indicates that the primitive or a parameter of the primitive is not
supported by the device or driver.
- SDT_OUTSTATE
-
The primitive is only valid for a different state of the interface. The state
of the interface is not consistent with the primitive. This is normally
returned to a local management primitive which is out of order with the state,
such as an SDT_ENABLE_REQ before an SDT_ATTACH_REQ has been
fullfilled. This error is normally returned in an SDT_ERROR_ACK to a
local management primitive.
- SDT_PROTOSHORT
-
The M_PROTO or M_PCPROTO block is too short for the primitive.
- SDT_SYSERR
-
A UNIX system error occured which does not permit the operation to complete.
- SDT_WRITEFAIL
-
An attempt to write the SDT_SIGNAL_UNIT_REQ or M_DATA failed.
This is normally returned in an SDT_ERROR_ACK in the former case and an
SDT_ERROR_IND in the later.
- ERROR EXPLANATIONS
-
The following error reasons (explanations) may be returned in the
sdt_reason member of the SDT_ERROR_ACK or SDT_ERROR_IND
primitive:
-
- SDT_FORMAT
-
Formatting error. This indicates something wrong with the formatting of the
item indicated by the error number.
- SDT_OVERRUN
-
Receiver overrun. This is a reason for a error indication such as
SDT_SYSERR or SDT_EVENT.
- SDT_BUSY
-
The requested resource was busy. For example, this is a reason for refusing a
validly formatted PPA in an SDT_ATTACH_REQ where the PPA is already
assigned.
- SDT_QUIESCENT
-
The requested PPA is in a transient state and is unavailable for assignment.
- SDT_DSRTIMEOUT
-
The DSR lead has timedout on a V.35 interface.
- SDT_LOSTCTS
-
The CTS lead has been deasserted on a V.35 interface.
SEE ALSO
streamio(2),
putmsg(2),
getmsg(2),
ioctl(2),
sli(7),
slsi(7),
mtpi(7),
ss7d(8).
CAVEATS
The SDTI relies on the STREAMS queue back-enabling mechanism to invoke the
upper layer module as to when to generate a frame for transmission. This is
so that frames have timely BIB/BSN FIB/FSN values before they are transferred
across the SDTI. The high-water mark on the SDTI write queue is set to 1 so
that when the driver takes a frame from its write queue, the queue is
back-enabled to invoke the writer's write service routine an potentially
back-enable the queue all the way to the stream head (if opened at the user
level).
AUTHOR
Brian F. G. Bidulock,
<bidulock@openss7.org>.
HISTORY
This STREAMS interface for SS7 is an original part of the
OpenSS7
package.
REFERENCES
COPYRIGHT
Copyright (C) 2000 Brian Bidulock. All Rights Reserved.
PUBLIC LICENSE
This license is provided without fee, provided that the above copyright
notice and this public license must be retained on all copies,
extracts, compilations and derivative works. Use or distribution of
this work in a manner that restricts its use except as provided here
will render this license void.
The author(s) hereby waive any and all other restrictions in respect
of their copyright in this software and its associated documentation.
The authors(s) of this software place in the public domain any novel
methods or processes which are embodied in this software.
The author(s) undertook to write it for the sake of the advancement
of the Arts and Sciences, but it is provided as is, and the author(s)
will not take any responsibility in it.
Index
- NAME
-
- SYNOPSIS
-
- DESCRIPTION
-
- LOCAL MANAGEMENT INTERFACE
-
- PPA Style
-
- Local Management States
-
- Local Management Primitives
-
- PRIMITIVE INTERFACE
-
- IOCTLS
-
- ERROR HANDLING
-
- ERRORS
-
- SEE ALSO
-
- CAVEATS
-
- AUTHOR
-
- HISTORY
-
- REFERENCES
-
- COPYRIGHT
-
This document was created by
man2html,
using the manual pages.
Time: 23:32:01 GMT, January 07, 2001