The SS7 signalling data link provides a synchronous communications channel for passing bits between SS7 signalling points. 

The model of the SS7 signalling data link is presented here to describe concepts that are used throughout the specification fo the SDLI. It is described in terms of an interface architecture, as well as addressing concepts needed to identify different components of that architecture. The description of the model assumes familiarity with the ITU-T Q.700-Series Recommendations or similar national SS7 specifications documents. 

Each layer of the SS7 Protocol Stack has two standards: 

SDLI is an implementation of the first type of standard. It specifies an interface to the services of the SS7 Signalling Data Link. The following picture depicts the abstract view of SDLI. 

The SS7 Signalling Data Link interface is the boundary between the Signalling Data Terminal (SDT) and the Signalling Data Link (SDL) in the SS7 model. The terminal entity is the user of the services of the signalling data link interface (SDL user), and the link entity is the provider of those services (SDL provider). The interface consists of a set of primitives that provide access to the data link services, plus the rules for using those primitives (state transition rules). A signalling link service primitive might request a particular service or indicate a pending event. 

To provide uniformity across various UNIX system implementations of OpenSS7, an effort is underway to develop service interfaces that map to the OpenSS7 Model. A set of kernel-level interfaces, based on the STREAMS development environment, constitute a major portion of this effort. The service primitives that make up these interfaces are defined as STREAMS messages that are tranferred between the user and provider of the service. SDLI is one such kernel-level interface, and is targetted for STREAMS protocol modules that either use or provide SS7 Signalling Data Link services. In addition, user programs that wish to access a STREAMS based signalling data link provider directly may do so using the putmsg(2) and getmsg(2) system calls.³ 

Referring to the abstract view of SDLI (Figure 10), the SDLI provider is configured as a STREAMS driver, and the SDLI user accesses the provider using open(2) to establish a stream to the SDLI provider. The stream acts as a communications endpoint between an SDL user and a SDL provider. After the stream is created, the SDL user and SDL provider communicate via the messages presented later in this section. 

SDLI is intended to free SS7 signalling data link users from specific knowledge of the characteristics of the signalling data link provider. Specifically, the definition of SDLI hopes to acheive the goal of allowing an SDL user to be implemented independent of a specific communications medium or synchronous serial interface. Any signalling data link provider (supporting any communications medium or sychronous serial interface) that conforms to the SDLI specification may be substituted beneath the SDL user to provide the signalling data link services. Support of a new SDL provider should not require any changes to the implementation of the SDL user. 

The signalling data link provider interface supports only one of the three OSI modes of communication at the data link layer: connection mode. The other two modes (connectionless and acknowledged connectionless) are not supported by SS7 at this level. The connection mode is circuit-oriented and enables data to be transferred over a pre-established connection in a sequenced manner. Data may be lost or corrupted in this service mode, however, due to provider-initiated resynchronization or connection aborts. 

Connectionless and acknowledged connectionless modes are provideed by the upper levels of the SS7 protocol (i.e. SCCP). 

The connection-mode service is characterized by four phases of communication: local management, connection establishment, data transfer, and connection release. 

This phase enables a SDL user to initialize a stream for use in communication and establish an identity with the SDL provider. 

Connection Establishment 

This phase enables two SDL users to establish a signalling data link connection between them to exchange data. Each SDL user is responsible for initiating a connection to an identified signalling data link in accordance with procedures identified at a higher level (i.e. within MTP Level 3 Signalling Link Management). The link to which to connect is identified by an address associated with its stream (as will be discussed shortly). 

For each of the SDL users, only one connection may be established per stream. Thus, the stream is the communication endpoint for a signalling data link connection. 

Each SDL user is responsible for connection and disconnection streams from separate physical communications channels necessary for the exchange of data between SDL users. Coordination between SDL users on either side of the stream is accomplished by using methods for the automatic allocation of signalling data links as provided for in ITU-T Recommendation Q.704^[5]. 

In this phase, the SDL users are considered peers and may exchange data simultaneously in both directions over an established signalling data link connection. Either SDL user may send data to its peer SDL user at any time. Data sent by a SDL user is guaranteed to be delivered to the remote user in the order in which it was sent.⁴ 

This phase enables either the SDL user or the SDL provider to break and established connection . The release procedure is considered abortive, so any data that has not reached the destination user when the connection is released may be discarded by the SDL provider. 

Each user of SDLI must establish an identity to communicate with other signalling data link users. This identity consists of two pieces. First, the SDL user must somehow identify the physical medium over which it will communicate. This is particularly evident on systems that are attached to multiple physical media. Second, the SDL user must register itself with the SDL provider so that the provider can deliver protocol data units destined for that user. The following figure illustrates the components of this identification approach, which are explained below. 

The physical piont of attachment (PPA in Figure 11) is the point at which a system attaches itself to a physical communications medium. All communication on that physical medium funnels through the PPA. On systems where a SDL provider suppors more than one physical medium, the SDL user must identify which medium it will communicate through. A PPA is identified by a unique PPA identifier. For media that support physical layer multiplexing of multiple channels over a single physical medium (such as the individual channels of a T1 span), the PPA identifier must identify the specific channel over which communication will occur. 

Two styles of SDL provider are defined by SDLI, distinguished by the way they enable a SDL user to choose a particular PPA. The style 1 provider assigns a PPA based on the major/minor device the SDL user opened. One possible implementation of a style 1 driver would reserve a major device for each PPA the signalling data link driver would support. For a style 2 driver, the open(2) creates a stream between the SDL user and the SDL provider, and the attach primitive then associates a particular PPA with that stream. The format of the PPA identifier is specific to the SDL provider, and should be described in the provider-specific addendum documentation. 

SDLI provides a mechanism to get and/or modify the physical address. The primitives to handle these functions are described in a later section. The physical address value can be modified in a post-attached state. This would modify the value for all streams for that provider for a particular PPA. The physical address cannot be modified if even a single stream for that PPA is in the bound state. 

The SDL User uses the LMI_ATTACH_REQ primitive to associate itself with a specific phsyical address on a per Stream basis. It is invalid for a SDL Provider to ever send upstream data messages on a stream from a phsyical attachment to which that stream has not been attached with the LMI_ATTACH_REQ primitive. 

In addition to the physical point of attachment (PPA) concept which is consistent with that of the Data Link Provider Interface (DLPI) and the Communications Device Interface (CDI), SS7 also includes the concept of a signallint data link identifier (sdli) which is used in upper-layer messages for the coordination of the connection and disconnection of signalling data links using the automatic allocation of signalling data link procedures of the Message Transfer Part (MTP). 

The format of this signalling data link identifer (sdli) must normally be agreed upon between MTP peers at either end of the communications channel and can normally take the form of a Circuit Identification Code (CIC) or a Bearer Identification Code (BIC). 

A signalling data link user's identity is established by associating it with a signalling data link identification (sdli), which is the point through which the user will communicate with the signalling data link provider. An sdli is identified by a DLSAP address. 

The DLSAP address identifies a particular data link access point that is associated with a stream (communication endpoint). A bind service primitive enables a SDL user to either choose a specific DLSAP by specifying its DLSAP address, or to determine the DLSAP associated with a stream by retrieving the bound DLSAP address. This DLSAP address can then be used by other SDL users to access a specific SDL user. The format of the DLSAP address is specific to the SDL provider, and should be described in a provider-specific addendum documentation. However, SDLI provides a mechanism for decomposing the DLSAP address into component pieces. The LMI_INFO_ACK primitive returns the length of the SAP component of the DLSAP address, along with the total length of the DLSAP address. 

SDL providers do not require the capability (nor do they permit) the capability to bind on multiple DLSAP addresses. SDL providers only supports peer binding of DLSAPs. That is, the DLSAP specified in any subsequent bind is used in lieu of the DLSAP bound in the LMI_BIND_REQ.