The kernel-level interface to the signalling data link layer defines a STREAMS-based message interface between the provider of the signalling data link service (SDL provider) and the consumer of the signalling data link service (SDL user). STREAMS provides the mechanism in which SDLI primitives may be passed between the SDL user and SDL provider. 

Before SDLI primitives can be passed between the SDL user and the SDL provider, the SDL user must establish a stream to the SDL provider using open(2). The SDL provider must therefore be configured as a STREAMS driver. When interactions between the SDL user and SDL provider have completed, the stream may be closed. 

The STREAMS messages used to transport signalling data link service primitives across the interface have on of the following formats: 

The information contained in the M_PROTO or M_PCPROTO message blocks must begin on a byte boundary that is appropriate for structure alignment(e.g. word aligned on the AT&T 3B2 Computer). STREAMS will allocate buffers that begin on such a boundary. However, these message blocks may contain information whose representation is described by a length and an offset within the block. An example of the DLSAP address (sdl_addr_length and sdl_addr_offset) in the LMI_BIND_ACK primitive. The offset of such information within the message block is not guaranteed to be properly aligned for casting the appropriate data type (such as an int or structure). 

Section ??? defines the sequence in which SDLI primitive can be passed between SDL user and SDL provider, and section ?? summarizes the precedence rules associated with each primitive for ordering the primitives on the SDL provider and SDL user queues. 

The following section describe the format of the primitives that support the services described in the previous section. The primitives are grouped into two general categories for presentation: 

This section describes the local management service primitives that are common to all service modes. These primitives support the Information Reporting, Attach, and Bind services. Once a stream has been opened by an SDL user, these primitives initialize the stream, preparing it for use. 

The PPA associated with each stream must be initialized before the SDL provider can transfer data over the medium. The initialization and de-initialization of the PPA is a network management issue, but SDLI must address the issue because of the impact such actions will have on the SDL user. More specifically, SDLI requires the SDL provider to initialize the PPA associated with a stream at some point before it completes the processing of the LMI_BIND_REQ. Guidelines for initialization and de-initialization of a PPA by a SDL provider are presented here. 

A SDL provider may initialize a PPA using the following methods: 

A specific SDL provider may support any of these methods, or possibly some combination of them, but the method implemented has no impact on the SDL user. From the SDL user's viewpoint, the PPA is guaranteed to be initialized and available for transmission until it closes or unbinds the stream associated with the PPA. 

SDL provider-specific addendum documentation should describe the method chosen for PPA initialization and de-initialization. 

Requests information of the SDL provider about the SDLI stream. This information includes a set of provider-specific parameters, as well as the current state of the interface. 

This message is consistent with the CD_INFO_REQ message of the Communications Device Interface. 

The message consists of one M_PCPROTO message block, which contains the following structure: 

The message is valid in any state in which a local acknowledgement is not pending, as described in section 2.6, Sequences. 

The resulting state is unchanged. 

The SDL provider responds to the information request with a LMI_INFO_ACK. 

Aside from minor renaming and renumbering, this message is consistent with the CD_INFO_REQ of the CDI. 

This message is sent in response to LMI_INFO_REQ; it conveys information bout the SDLI stream to the SDL user. 

The semantics of this message is consistent with the CD_INFO_REQ of the Communications Device Interface (CDI), however the parameter number, kind, and layout are different. 

The message consists of one M_PCPROTO message block, which contains the following structure. 

This message is valid in any state in response to a LMI_INFO_REQ. 

The resulting state is unchanged. 

Note:- The CDI also has the fields cd_duplex, cd_class, cd_output_style, and cd_features. It lacks the lmi_version and lmi_header_len fields, but note that the lmi_header field is not really used a the signalling data link interface; it is reserved for use by the signalling link interface and to allow the info_ack types to be consistent across the lowest levels of the OpenSS7 stack. 

The reason that the cd_duplex field is missing is that the field would always be set to CD_HALFDUPLEX. The reason that the cd_class field is missing is that the field would always be set to CD_HDLC for SS7. The reaons that the cd_output_style field is not supported is that the field would always be set to CD_PACEDOUTPUT. The reason that the cd_features field is missing is that the field would always be set to CD_CANREAD|CD_AUTOALLOW. 

Requests the SDL provider associate a physical point of attachment (PPA) with a stream. LMI_ATTACH_REQ is needed for style 2 SDL providers to identify the physical medium over which communication will transpire. The request may not be issued to a style 1 SDL provider; doing so may cause errors. 

The SDL provider may initialize the physical line on receipt of this primitive or the LMI_ENABLE_REQ. Othersize, the line must be initialized through some management mechanism before this request is issued by the SDL user. Either way, the physical link must be initialized and ready for use on successful completion of the SDL_ENABLE_REQ. 

The message consists of one M_PROTO message block, which contains the following structure: 

The message is valid in state LMI_UNATTACHED. 

The resulting state is LMI_ATTACH_PENDING. 

If the attach request is successful, LMI_OK_ACK is sent to the SDL user resulting in state LMI_UNBOUND. 

If the request fails, the message LMI_ERROR_ACK is returned and the resulting state is unchanged. 

For style 2 SDL providers, this requests the SDL provider detach a physical point of attachment (PPA) from a stream. The request may not be issued to a style 1 SDL provider; doing so may cause errors. 

The message consists of one M_PROTO message block, which contains the following structure: 

The message is valid in state LMI_UNBOUND. 

The resulting state is LMI_DETACH_PENDING. 

If the detach request is successful, LMI_OK_ACK is sent to the SDL user resulting in state LMI_UNATTACHED. 

Request the SDL provider enable the connection to the stream. The request directs the SDL provider to activate the stream associated with the physical connection identified in the attached PPA. 

A streams is viewed as active when the SDL provider may transmit and receive protocol data units destined to or originating from the stream. The PPA associated with each stream must be initializede upon completion of the processing of the LMI_ENABLE_REQ (see section 2.3.1.1, PPA Initialization/Deinitialization). More specifically, the SDL user is ensured that the PPA is initialized when the LMI_ENABLE_ACK is received. If the PPA cannot be initialized, the LMI_ENABLE_REQ will fail. 

The message consists of one M_PROTO message block, which contains the following structure: 

The message is valid in state LMI_DISABLED. 

The resulting state is LMI_ENABLE_PENDING. 

If the enable request is successful, LMI_ENABLE_CON is sent to the SDL user resulting in state LMI_ENABLED. 

If the request fails, the message LMI_ERROR_ACK is returned and the resulting state is unchanged.