SDLI

Section: Linux STREAMS Programmer's Manual (7)
Updated: $Date: 2014/10/10 10:45:00 $
Index Return to Main Contents
 

NAME

sdli - Signalling System No. 7 Signalling Data Link (SDL) Interface  

SYNOPSIS

#include <ss7/sdli.h>
#include <ss7/sdli_ioctl.h>

fd = open("/dev/sdl", flags);
ret = ioctl(fd, cmd, ... /* arg */ );
 

DESCRIPTION

This man page describes the STREAMS interface which is used to configure and exchange data with an SS7 Signalling Data Link Interface (SDLI) for all SS7 devices conforming to the OpenSS7 Signalling Data Link Interface (SDLI) specification.

SDLI drivers are normally linked using streamio(7) I_PUSH ioctl under a Signalling Data Terminal (SDT) STREAMS module conforming to the Signalling Data Terminal Interface specification sdti(7) such as sdt(8), by the SS7 Configuration Daemon ss7d(8). Yet, this interface is available for the purpose of ferry-clip conformance and diagnostic testing of the SS7 Signalling Data Link.

SDLI Style 1 or Style 2 drivers may be configured to autopush the sdt(8) module and appear as sdti(7) drivers. Not all SS7 drivers need be written to the SDL interface: drivers may be written to the sdti(7), sli(7), slsi(7) and even mtpi(7) interfaces.

The SDLI interface consists of three subcomponents:

LOCAL MANAGEMENT INTERFACE
SDLI provides a local management interface which utilizes M_PROTO and M_PCPROTO messages which can be exchanged with the interface using putmsg(2) and getmsg(2) system calls on the stream head once the interface is opened. The local management interface controls local management (STREAMS configuration functions) which are normally used by the SS7 Configuration Daemon ss7d(8) on the driver interface before pushing an sdt(8) module onto the stream head. The local management interface is described in detail in section "LOCAL MANAGEMENT INTERFACE".
PROTOCOL (SERVICE) INTERFACE
SDLI provides a protocol interface which utilizes M_DATA, M_PROTO and M_PCPROTO messages which can be exchanged with write(2), read(2), putmsg(2) or getmsg(2) system calls on the stream head, or which can be exchanged with the driver by upstream pushed or linked modules. The protocol interface exchanges SS7 protocol primitives between the Signalling Data Terminal (SDT) and the Signaling Data Link (SDL), but may also be used for ferry-clip conformance testing or diagnostics. The protocol interface is described in detail in section "PROTOCOL INTERFACE".
PROTOCOL MANAGEMENT INTERFACE
SDLI provides a protocol management interface which utilizes M_CTL message between modules or M_IOCTL I_STR messages from a stream head formatted per the SS7 Management Interface smi(7). The protocol management interface provides protocol configuration, state inquiry, statistics and event management (SNMP functions). This interface is normally used by the SS7 Configuration Daemon ss7d(8) on the stream after opening or during operation. The protocol management interface is described in smi(7) and detailed in section "PROTOCOL MANAGEMENT INTERFACE" below.
CONTROL INTERFACE
SDLI provides a control interface which utilizes ioctl(2) transparent calls or an I_STR ioctl from streamio(2) from a stream head to the driver, or M_CTL messages between modules. The control interface controls specific aspects of the SDL driver which are outside the scop of the SS7 protocol. These controls are normally used by the SS7 Configuration Daemon ss7d(8) on the driver interface or multiplexor control channel before or after the protocol stack has been assembled. The control interface is described in the section "CONTROL INTERFACE".

 

LOCAL MANAGEMENT INTERFACE

PPA Style

From the local management view, the SDLI can support two styles for Point of Physical Address (PPA) selection. These styles are as follows:

SDT_STYLE1
A Style 1 driver is a driver whose Signalling Data Link (SDL) is associated with the stream at open time. These drivers open in the SDL_DISABLED state and do not require a SDL_ATTACH_REQ local management primitive to association them with a specific transmission channel. Style 1 drivers do not require PPA addresses.
SDT_STYLE2
A Style 2 driver is a driver whose Signalling Data Link (SDL) must be attached to the stream after open. These drivers open in the SDL_UNATTACHED state an must be attached with a SDL_ATTACH_REQ local management primitive to associate them with an SDL before then can be enabled for use. Style 2 drivers required a PPA (Physical Point of Attachment) address to indicate the physical transmission channel to which the stream is to be attached. The PPA Address is an opaque address which is meaningful only to a specific driver implementation of the SDLI.

Local Management States

From the perspective of local management, the SDL provider can be in a number of management states. Some local management primitives are applicable only in specific states. The SDL provider can be moved through the states wih local management primitives.

The management states of the SDL provider are as follows:

SDL_UNATTACHED
The SDL provider is not attached to a SDL PPA. This state is only applicable to Style 2 drivers which must be explicitly attached to a specific transmission channel. Style 2 drivers open in this state.
SDL_UNUSABLE
The SDL provider is unusable. This state occurs when the streams module is no longer able to perform local management actions on the SDL provider. This may be due to the failure, removal or failure to communicate with, some component in the system.
SDL_DISABLED
The SDL provider is attached but has not yet been enabled for use. The provider must be enabled with a SDL_ENABLE_REQ local management primitive before data or protocol primitives may be exchanged with the SDL user.
SDL_ENABLE_PENDING
The SDL provider has accepted a SDL_ENABLE_REQ request on the interface, but the provider must wait until some event occurs before the provider can be considered enabled. The provider will respond with a SDL_ENABLE_CON confirmation once the enabling is successful, or a SDL_ERROR_ACK if unsuccessful.
SDL_ENABLED
The SDL provider is enabled and ready for use (to provide SDL protocol services).
SDL_DISABLE_PENDING
The SDL provider has accepted a SDL_DISABLE_REQ request on the interface, but the provider must wait until some event occurs before the provider can be considered disabled. The provider will response with a SDL_DISABLE_CON confirmation once the disabling is successful, or a SDL_ERROR_ACK if unsuccessful.

Local Management Primitives

Local management primitive 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 after opening the device. This interface is normally used only by the SS7 Configuration Daemon ss7d(2) during STREAMS configuration, or by the upstream protocol modules during streamio(7) I_PUSH and I_POP operations. It is possible, however, for a user-level program to use this interface directly on an open SDLI driver stream head for special purposes and testing.

Only M_PROTO local management primitives will be deferred during congestion or overload of the SDL provider. Local management primitives sent as M_PCPROTO will be discarded and return a SDL_ERROR_ACK in response should it not be possible to execute them immediately.

Local management primitives provided by the SDLI are as follows:

SDL_INFO_REQ, SDL_INFO_ACK, SDL_ERROR_ACK

Invoked by the SDL user to request and return information about the SDL provider which is of interest to local configuration management. These requests are normally performed by the SS7 Configuration Daemon ss7d(8) on the newly opened stream head for the SDLI driver before pushing it under the Signalling Data Terminal sdt(8) module.

SDL_INFO_REQ
SDL_INFO_REQ uses a sdt_info_req_t structure which contains the request primitive in member sdt_primitive.
SDL_INFO_ACK
SDL_INFO_ACK uses a sdt_info_ack_t structure as follows: 

typedef struct {
    sdl_ulong   sdl_primitive;  /* SDL_INFO_ACK */
    sdl_ulong   sdl_version;
    sdl_ulong   sdl_state;
    sdl_ulong   sdl_max_sdu;
    sdl_ulong   sdl_min_sdu;
    sdl_ulong   sdl_ppa_style;
    sdl_uchar   sdl_ppa_addr[8];
} sdt_info_ack_t;
sdl_version
The version of the SDLI interface specification to which the device conforms with one byte per vesion number in host order. The current (and only) version of the SDLI is 1.0.0.0 or 0x01000000.
sdl_state
The current local management state of the SDL provider.
sdl_min_sdu
The minimum data unit size which may be transferred to and from the transmission channel. For some Signalling Data Links this may be zero.
sdl_max_sdu
The maximum data unit size which may be transferred to and from the transmission channel. For some Signalling Data Links this size may be unlimited, in which case the value returned here is 0xffffffff.
sdl_ppa_style
The style of the driver which may be one of the following:
SDL_STYLE1
A Style 1 device which is implicitly associated with a transmission channel at the time that the device is opened. These devices open in the SDL_DISABLED state.
SDL_STYLE2
A Style 2 device which must be explicitly attached to a transmission channel identified by a sdl_ppa_addr in a SDL_ATTACH_REQ local management primitive after opening. These devices open in the SDL_UNATTACHED state.
sdl_ppa_addr
The PPA address that a Style 2 device is attached to. If the device is a Style 1 device or an unattached Style 2 device, this member will return all zeros.
SDL_ERROR_ACK
SDL_ERROR_ACK containing the error number in sdl_errno and an error explanation in sdl_reason will be returned by the SDL provider in the rare event that an error occurs while attempting to retrieve the information requested by a SDL_INFO_REQ.

SDL_ATTACH_REQ, SDL_OK_ACK, SDL_ERROR_ACK

Invoked by the SDL user to attach a Style 2 SDL provider to a PPA using a PPA Address. This primitive is normally used by the SS7 Configuration Daemon ss7d(8) when assembling the SS7 protocol stack.

SDL_ATTACH_REQ
Requests that the SDL provider attach to the PPA address specified in the request. The SDL_ATTACH_REQ primitive is only valid from the SDL_UNATTACHED state for a Style 2 interface. SDL_ATTACH_REQ uses the sdl_attach_req_t structure as follows: 

typedef struct {
    sdl_ulong   sdl_primitive;  /* SDL_ATTACH_REQ */
    sdl_uchar   sdl_ppa_addr[8];
} sdl_attach_req_t;
sdl_ppa_addr
Specifies the PPA (Physical Point of Appearance) of the transmission channel to which the SDT provider should attach. This is an opaque address to the interface and is only meaningful to a specific driver implementation.
SDL_OK_ACK
Returned if the attach request is successful.
SDL_ERROR_ACK
Returned with the error number and explanation set if the attach request fails.

SDL_DETACH_REQ, SDL_OK_ACK, SDL_ERROR_ACK

Invoked by the SDL user to detach a Style 2 SDL provider from its PPA. This primitive is normally used by the SS7 Configuration Daemon ss7d(8) when disassembling or reconfiguring the SS7 protocol stack.

SDL_DETACH_REQ
Requests that the SDL provider detach itself from the current attached PPA. SDL_DETACH_REQ is only valid for Style 2 SDL providers in the SDL_DISABLED state. The DL_DETACH_REQ uses the sdt_detach_req_t structure which contains only the sdl_primitive.
SDL_OK_ACK
Returned if the detach request is successful.
SDL_ERROR_ACK
Returned with the error number and explanation set if the detach request fails.

SDL_ENABLE_REQ, SDL_ENABLE_CON, SDL_ERROR_ACK

SDL_DISABLE_REQ, SDL_DISABLE_CON, SDL_ERROR_ACK  

PROTOCOL MANAGEMENT INTERFACE

Protocol management primitives are provided to allow for protocol-specific configuration, state examination, statistical and event reporting. These primitives use the configuration structure sdl_conf_t, the state machine structure sdl_statem_t, statistics structure sdl_stats_t and event categories described above.

Protocol management primitives are exchanged using M_PROTO and M_PCPROTO messages in the same manner as protocol primtives, using putmsg(2) and Bgetmsg(2) system calls at the stream head or using the pass through mechanism provided by the control channel of an open multiplexor (see sls(8) and mtp(8)). These primitives are normally only used by ss7d(8) during configuration and operation, but may be used for testing and special purposes by user-level programs from the stream head.  

Protocol Configuration

Protocol management primitives are invoked by SDL management to configure or request configuration information from the SDL provider. Any M_DATA block attached to the primitives contains a sdl_conf_t structure (see below) which represents the configuration parameters. Configuration requests should normally be sent as M_PCPROTO messages.

SDL_CONFIG_SETUP
Test if the configuration parameters provided in the attached M_DATA block are settable and correct. Any values set to 0xffffffff in the configuration parameters should not be tested for change by the SDL provider. When successful, this request also write locks the configuration until a successful SDL_CONFIG_COMMIT is executed.
SLD_CONFIG_COMMIT
Commits the changes of a previous successful SDL_CONFIG_TEST operation. No configuration data is associated with this request and any attached M_DATA is ignored. When successful, this request also releases the write locks on the configuration.
SDL_CONFIG_SET
Set the configuration parameters to the values provided in the attached M_DATA block. This request will fail if the configuration is write locked.
SDL_CONFIG_GET
Get the configuration parameters. Any attached M_DATA is ignored. If the configuration is write locked, this request will only return the values which have been setup for a commit and not necessarily the current values.
Responses
Upon success, the SDL provider will return a SDL_OK_ACK to confirm a successful configuration request. The provider attaches a M_DATA block which contains a sdt_conf_t structure with the results of the configuration request.

Upon failure, the SDL provider will return a SDL_ERROR_ACK to reject the configuration request due to an error. The provider attaches a M_DATA block which contains a sdt_conf_t structure with 0xffffffff in any values which are in error. Error numbers which are specific to a configuration request rejection are as follows:

SDL_CONFLOCKED
The request attempted to perform an illegal operation on a locked configuration.
SDL_NOCONFDATA
The request was missing configuration data (i.e. missing M_DATA block or M_DATA block too short.
SDL_BADCONFDATA
Some configuration data was invalid. The attached M_DATA block contains 0xffffffff in the data elements which are considered invalid.
Datastructures
Configuration of the SDL provider uses the sdl_conf_t structure as follows: 

typedef struct sdl_conf {
    sdl_ulong   pvar;   /* protocol variant */
    sdl_ulong   popt;   /* protocol options */
    sdl_ulong   N;      /* octet count      */
} sdl_conf_t;
pvar
(Protocol Variant) Default: SS7_PVAR_ITUT_96

Protocol variant which will be used for the SDT provider. When the protocol variant is set, all configuration parameters, options and state machine procedures must conform to the Signalling Data Link sections of the applicable standards. Modifications to this configuration can be made by changing other parameters in the configuration. When the value of pvar is changed, protocol variant specific default values for the rest of the configuration members, unless specified, will be used. pvar can be any of the protocol variant values specified in ss7(7).

popt
(Protocol Options) Default: 0

Options to modify the main specification as determined by pvar. popt is a bit-wise OR of the folloing option bitmasks:

SDL_POPT_HSL
When this bit is set, the SDL provider will use the High-Speed Link (HSL) version of the DAEDR as specified in Q.703 Annex A which does not perform octet counting mode but only reports single SDL_DAEDR_SU_IN_ERROR for loss of synchronization.

When this bit is clear, it indicates that normal Q.703 DAEDR behaviour should be used and SDL_DAEDR_SU_IN_ERROR reported once for every N octets during loss of syncrhonization.

N
(Octets Per SU) Default: 16

The number of octets representing an SU in octet counting mode per Q.703. This value is ignored if popt includes SDL_POPT_HSL.

 

Protocol State

Protocol management primitives may be invoked by SDL management to request and return state information about the SDL provider. This may be useful for resynchronization between protocol modules as well as for testing and diagnostic purposes. Any M_DATA block attached to the primitive or acknowledgement contains a sdl_statem_t structure (see below) which represents the current state of the protocol state machines. State requests may be sent as M_PROTO or M_PCPROTO messages from the stream head. Upstream modules may send a M_CTL message if desired.

SDL_STATE_REQ
Requests that the SDL provider return the current state variables associated with the SDL state machines. This primitive uses a sdl_state_req_t structure which contains only the sdl_primitive.
Responses
Upon success, the SDL provider will return a SDL_OK_ACK to confirm the successful state request. The provider attaches a M_DATA block which contains a sdl_statem_t structure (see "PROTOCOL STATE") containing the state variables.

Upon failure, the SDL provider will return a SDL_ERROR_ACK to reject the state request. Normally the request is successful and only the general error codes (see "ERROR HANDLING") will be returned.

Datastructures
For communicating state information, the SDL provider uses the sdl_statem_t structure as follows: 

typedef struct sdl_statem {
    sdl_ulong   daedt_state;
    sdl_ulong   daedr_state;
    sdl_ulong       octet_counting_mode;
} sdl_statem_t;
daedt_state
Total state of the DAEDT state machine per Q.703. This member can take on the value SDL_STATE_IDLE or SDL_STATE_IN_SERVICE.s
daedr_state
Primary state of the DAEDR state machine per Q.703. This member can take on the values SDL_STATE_IDLE or SDL_STATE_IN_SERVICE.
octet_counting_mode
Flag of the DAEDR per Q.703. Indicates that the DAEDR is in octet counting mode per Q.703 when non-zero and in normal mode when zero. The values of this flag is undefined if the SDL_POPT_HSL protocol option is set.
 

Protocol Statistics

Protocol management primitives may be invoked by the SDL management to request and return statistical information collected during the operation of the SDL provider.

Any M_DATA block attached to the primitive or acknowledgement contains a sdl_stats_t structure (see below) which represents the statistics collected during the collection interval by the provider.

Statistics requests should be sent as low priority band M_PROTO messages. The SDLI provider will respond with low priority band M_PROTO messages for all but error conditions, which are sent as M_PCPROTO. SDL_STATS_IND messages will all be sent a low priority band M_PROTO messages. This avoids congestion resulting from syncrhonized data collection intervals across a large number of managed objects in the SS7 stack.

SDL_STATS_SET
Sets the statistics collection and aggregation parameters.
SDL_STATS_GET
Gets the statistics collection and aggrepation parameters as well as the
SDL_STATS_IND
Delivers an indication of the aggregated statistics for a collection period.
Responses
Upon success, SDL_OK_ACK acknowledges a successful statistics request and returns a M_DATA which contains the sdl_stats_t structure returning the statistics and collection and aggregation parameters. Upon failure, SDL_ERROR_ACK rejects a failed statistics request and returns a M_DATA which contains the sdl_stats_t structure returning the statistics, collection and aggregation parameters. Upon autonomous failure, SDL_ERROR_IND indicates a spontaneous failure in statistic collection or aggregation.

In error indications and acknowledgements, sdl_errno values can be a general error value (see "ERROR HANDLING") or one of:

SDL_STATSOOM
Statistics collection ran out of memory.
SDL_STATSSUSPEND
Statistics collection is congested and has been suspended.
SDL_STATSRESUME
Statistics collection congestion has cleared and has been resumed.
Datastructures
The SDL provider communicates statistics using the sdl_stats_t structure as follows: 

typedef struct sdl_stats {
    sdl_ulong   octets_transmitted;
    sdl_ulong   octets_received;
} sdl_stats_t;
octets_transmitted
Provides a count (in bytes) of the octets transmitted through the DAEDT for the collection interval.
octets_received
Provides a count (in bytes) of the octets received through the DEADR for the collection interval.
 

Protocol Events

Protocol management primitives may be used by the SDL provider to indicate significant protocol management events or errors.
SDL_EVENT_REQ, SDL_EVENT_IND
Indicates a protocol management event has occured. The event indication uses the sdl_event_int_t structure as follows: 

typedef struct {
    sdl_ulong   sdl_primitive; /* SDL_EVENT_IND */
    sdl_ulong   sdl_event_id;
} sdl_event_int_t;
sdl_type
The type of event which has occured. This indicates what may be the structure of any attached M_DATA block. It is one of the following values:

 

PROTOCOL INTERFACE

Protocol Primitives

Protocol primitives are as follows:

SDL_BITS_FOR_TRANSMISSION, SDL_RECEIVED_BITS
SDL_DAEDT_START_REQ
SDL_DAEDR_START_REQ
SDL_DAEDR_CORRECT_SU_IND
SDL_DAEDR_SU_IN_ERROR_IND

 

PROTOCOL MANAGEMENT INTERFACE

SDLI providers recognize the SMI M_CTL interface for protocol layer configuration, state, statistics and event management (see smi(7)) utilizing the following structures:  

Configuration

The control interface uses the sdl_conifig_t structure for configuration requests and responses as follows: 

typedef struct sdl_config {
    sdl_ulong   pvar;   /* protocol variant */
    sdl_ulong   popt;   /* protocol options */
    sdl_ulong   N;      /* octets per su    */
    sdl_ulong   type;   /* interface type   */
    sdl_ulong   gtype;  /* group type       */
    sdl_ulong   rate;   /* interface rate   */
    sdl_ulong   mode;   /* interface mode   */
    sdl_ulong   clock;  /* interface clock  */
    sdl_ulong   coding; /* interface coding */
} sdl_config_t;
pvar
Protocol variant which can take on one of the values described in smi(7).
popt
Protocol options which contains a bit vector with any of the following bits set:
SDL_POPT_HSL
High speed links. When this bit is set it indicates that the SDL is a high speed link and will only deliver the first occurence of SDL_DAEDR_SU_IN_ERROR and not to enter octet_counting_mode.
SDL_POPT_XSN
Extended sequence numbers. When this bit is set it indicates that the L2 header consists of 6 octets instead of the normal 3.
N
The number of octets after which to deliver a SDL_DAEDR_SU_IN_ERROR when in octet_counting_mode. This number is meaningless when popt is has bit SDL_OPT_HSL set.

SDLI provides the following common SMI IOCTLS for protocol configuration management:

SDL_IOCTCONFIG [WR] (SMI_CONFIG_SETUP)
arg provides a pointer to a sdl_config_t structure which contains the configuration to setup and returns the results of the setup. This also locks the current configuration if successful.
SDL_IOCCCONFIG [-R] (SMI_CONFIG_COMMIT)
arg provides a pointer to a sdl_config_t structure which will contain the resulting configuration after commiting the last setup configuration. This also unlocks the current configuration if successful.
SDL_IOCSCONFIG [WR] (SMI_CONFIG_SET)
arg provides a pointer to a sdl_config_t structure which contains the configuration to set as well as returning the results of the settings.
SDL_IOCGCONFIG [-R] (SMI_CONFIG_GET)
arg provides a pointer to a sdl_config_t structure which will contain the current configuration when successful.

 

State

The control interface uses the sdl_statem_t structure for protocol state requests and responses as follows: 

typedef struct sdl_statem {
    sdl_ulong   daedt_state;
    sdl_ulong   daedr_state;
    sdl_ulong   octet_counting_mode;
} sdl_statem_t;
daedt_state
State of the DAEDT state machine. This state may be either SDL_STATE_IDLE or SDL_STATE_IN_SERVICE.
daedr_state
State of the DAEDR state machine. This state may be either SDL_STATE_IDLE or SDL_STATE_IN_SERVICE.
octet_counting_mode
Flag indicating whether the DAEDR is in octet counting mode.

SDLI provides the following common SMI IOCTLS for protocol state management:

SDL_IOCCMRESET [-R] (SMI_RESET_REQ)
Performs a master reset of the SDL protocol state, placing it into the power-on condition and returns the state of the SDL. arg provides a pointer to a sdl_statem_t structure which will contain the state after master reset.
SDL_IOCGSTATEM [-R] (SMI_STATE_REQ)
Gets the current protocol state of the SDL. arg provides a pointer to a sdl_statem_t structure which will contain the state when successful.

 

Statistics

The control interface uses the sdl_stats_t structure for protocol statistics requests and responses as follows: 

typedef struct sdl_stats {
    sdl_ulong   octets_transmitted;
    sdl_ulong   octets_received;
    sdl_ulong   sus_transmitted;
    sdl_ulong   sus_received;
    sdl_ulong   sus_in_error;
    sdl_ulong   breaks;
    sdl_ulong   aborts;
    sdl_ulong   residue_errors;
    sdl_ulong   framing_errors;
    sdl_ulong   frame_too_long;
    sdl_ulong   frame_too_short;
    sdl_ulong   lost_sync;
    sdl_ulong   rx_overruns;
    sdl_ulong   tx_underruns;
    sdl_ulong   dsr_transitions;
    sdl_ulong   cts_transitions;
    sdl_ulong   spurious_interrupts;
    /* others */
} sdl_stats_t;
octets_transmitted
octets_received
sus_transmitted
sus_received
sus_in_error
breaks
aborts
residue_errors
framing_errors
frame_too_long
frame_too_short
lost_sync
rx_overruns
tx_underruns
dsr_transitions
cts_transitions
spurious_interrupts

SDLI provides the following common SMI IOCTLS for protocol statistics management:

SDL_IOCSSTATSP [WR] (SMI_STATSP_SET)
SDL_IOCGSTATSP [R] (SMI_STATSP_GET)
SDL_IOCCSTATS [W] (SMI_STATS_CLR)
SDL_IOCGSTATS [R] (SMI_STATS_GET)

 

Events

 

CONTROL INTERFACE

The SDL provider is expected to support some standard ioctls to configure the SS7 Signalling Data Link driver. They may be used on a stream which is attached to the deivce to which the ioctl applies, or passed through a multiplexor using the 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.

For the following ioctls, it might not be possible to perform the set operations on all drivers implementations. For some drivers, it might not be possible to perform set operations while the interface is running. Set operations on running interfaces might result in line disruptions. Pseudo-devices should return the null value on get operations.

The ioctls provided by the SDTI are as follows:

SDL_IOCSIFRATE, SDL_IOCGIFRATE
Sets or gets the bit rate associated with the SDL interface. It may not be possible to set the bit rate on all devices (some device have a fixed bit rate). arg points to the bit rate of the line in bits per second at or above 56kbps, and the baud rate of the line in baud below 56kbps.
SDL_IOCSIFTYPE, SDL_IOCGIFTYPE
Sets or gets the interface type associated with the SDL interface. arg is a pointer to an sdl_ulong which contains one of the following values:

SDL_TYPE_NONE Unknown or unspecified. This may be used by some pseudo-devices.
SDL_TYPE_V35 Sychronous serial V.35 channel.
SDL_TYPE_DS0 64kbps DS0 channel.
SDL_TYPE_DS0A 56kbps (robbed bit) DS0A channel.
SDL_TYPE_E1 Full E1.
SDL_TYPE_T1 Full T1.
SDL_TYPE_J1 Full J1.
SDL_TYPE_ATM ATM channel.
SDL_TYPE_PACKET Packet channel.

SDL_IOCSGRPTYPE, SDL_IOCGGRPTYPE
Sets or gets the channel group (span) type associated with the current SDL interface. arg is a pointer to an sdl_ulong which contains one of the following values:

SDL_GTYPE_NONE There is no transmission channel group (span) associated with the device (i.e. the device is a Style 1 device).
SDL_GTYPE_T1 Channel within a T1 span (1 of 24 channels).
SDL_GTYPE_E1 Channel within a E1 span (1 of 30/32 channels).
SDL_GTYPE_J1 Channel within a J1 span (1 of 24 channels).
SDL_GTYPE_ATM VC within an ATM.

SDL_IOCSIFMODE, SDL_IOCGIFMODE
Sets or sets the mode associated with the SDL interface. Valid modes may depend upon interface type. arg is a pointer to an sdl_ulong which contains one of the following values:

SDL_MODE_NONE There is no mode associated with the device. This may be returned by pseudo-devices.
SDL_MODE_DSU DSU mode of serial interface.
SDL_MODE_CSU CSU mode of serial interface.
SDL_MODE_DTE DTE mode of V.35 interface.
SDL_MODE_DCE DCE mode of V.35 interface.
SDL_MODE_CLIENT Client mode (connecting) connection.
SDL_MODE_SERVER Server mode (listening) connection.
SDL_MODE_PEER Peer in peer-to-peer connections.
SDL_MODE_REM_LB Remote Loopback mode (for testing).
SDL_MODE_LOC_LB Local Loopback mode (for testing).
SDL_MODE_LB_ECHO Loopback and Echo mode (for testing).
SDL_MODE_TEST Special purpose test mode.

SDL_IOCSIFCLOCK, SDL_IOCGIFCLOCK
Sets or gets the clocking source associated with the SDL interface. Valid sources may depend upon interface type. arg is a pointer to an sdl_ulong which contains one of the following values:

SDL_CLOCK_NONE No clocking. This may be used for clockless pseudo-devices.
SDL_CLOCK_ASYNC Data stream is asynchronous.
SDL_CLOCK_INT Internally generated clock.
SDL_CLOCK_EXT External clock attached.
SDL_CLOCK_LOOP Tx clock generated from rx clock.
SDL_CLOCK_MASTER Inteface generates tx and rx clocks.
SDL_CLOCK_SLAVE Interface accepts rx and tx clocks.
SDL_CLOCK_DPLL Interface regenerates tx to rx clock w/ DPLL.

SDL_IOCSIFCODING, SDL_IOCGIFCODING
Sets or gets the line coding associated with the SDL interface. Valid codings may depend upon interface type. arg is a pointer to an sdl_ulong which contains one of the following values:

SDL_CODING_NONE No line coding or link coding unspecified. This will be used by pseudo-devices.
SDL_CODING_NRZ Non-return to zero line coding.
SDL_CODING_NRZI Manchester line coding.
SDL_CODING_AMI AMI frame coding.
SDL_CODING_B6ZS B6ZS frame coding.
SDL_CODING_B8ZS B8ZS frame coding.
SDL_CODING_ESF Extended Super Frame coding.
SDL_CODING_AAL1 ATN Adaption Layer 1 coding.
SDL_CODING_AAL2 ATN Adaption Layer 2 coding.
SDL_CODING_AAL5 ATN Adaption Layer 5 coding.

SDL_IOCDEVPRIVATE

ERRROR HANDLING
In addition to the normal errno values returned in an M_IOCNAK message (see ioctl(2) and streamio(2)), the following error codes may also be returned:
EOPNOTSUPP
The set operation will return this error number if the driver does not support setting the object of the command. The get operation returning this error number should be considered the same as a return value of NONE.
EINVAL
The set operation will return this error number if the driver does not support the selected value of the argument in its current mode.
 

ERROR HANDLING

Errors

 

IMPLEMENTATIONS

SDLI drivers which are included in the OpenSS7 release are all pseudo-devices and include:

sdl_eth(8)
SDL emulation using raw Ethernet (802.2).
sdl_ip(8)
SDL emulation using raw Internet Protocol (IP).
sdl_upd(8)
SDL emulation using User Datagram Protocol (UDP).
sdl_tcp(8)
SDL emulation using Transmission Control Protocol (TCP).
sdl_rtp(8)
SDL emulation using Real-Time Transport Protocol (RTP).
sdl_sctp(8)
SDL emulation using Stream Control Transmission Protocol (SCTP).
 

SEE ALSO

 

CAVEATS

 

AUTHOR

Brian F. G. Bidulock, <bidulock@openss7.org>.  

HISTORY

This STREAMS interface for SS7 is an original part of the OpenSS7 package.  

REFERENCES

[Q702] ITU-T Recommendation Q.702 Signalling Data Link
[Q703] ITU-T Recommendation Q.703 Signalling Link
[Q704] ITU-T Recommendation Q.704 Message Transfer Part
 

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
PROTOCOL MANAGEMENT INTERFACE
Protocol Configuration
Protocol State
Protocol Statistics
Protocol Events
PROTOCOL INTERFACE
PROTOCOL MANAGEMENT INTERFACE
Configuration
State
Statistics
Events
CONTROL INTERFACE
ERROR HANDLING
IMPLEMENTATIONS
SEE ALSO
CAVEATS
AUTHOR
HISTORY
REFERENCES
COPYRIGHT
This document was created by man2html, using the manual pages.
Time: 05:12:10 GMT, January 08, 2001