DLPI Services

This service provides information about the DLPI stream to the DLS user. The message DL_INFO_REQ requests the DLS provider to return operating information about the stream. The DLS provider returns the information in a DL_INFO_ACK message as shown in Figure 1-3 “Message Flow: Information Reporting”.

Figure 1-3 Message Flow: Information Reporting

The attach service assigns a physical point of attachment (PPA) to a stream. This service is required for style 2 DLS providers to specify the physical medium over which communications will occur. The DLS provider indicates success with a DL_OK_ACK message and failure with a DL_ERROR_ACK message. The normal message sequence is illustrated in Figure 1-4 “Message Flow: Attaching a Stream to a Physical Line”.

Figure 1-4 Message Flow: Attaching a Stream to a Physical Line

A PPA may be disassociated with a stream using the DL_DETACH_REQ. The normal message sequence is illustrated in Figure 1-5 “Message Flow: Detaching a Stream to a Physical Line”.

Figure 1-5 Message Flow: Detaching a Stream to a Physical Line

The bind service associates a data link service access point (DLSAP) with a stream. The DLSAP is identified by a DLSAP address.

DL_BIND_REQ requests that the DLS provider bind a DLSAP to a stream. It also notifies the DLS provider to make the stream active with respect to the DLSAP for processing connectionless data transfer and connection establishment requests. DL_SUBS_BIND_REQ provides the added capability on binding on multiple DLSAP addresses.

The connection establishment service establishes a data link connection between a local DLS user and a remote DLS user for the purpose of sending data. Only one data link connection is allowed on each stream.

Normal Connection Establishment

In the connection establishment model, the caller initiates connection establishment, while the callee waits for incoming requests. DL_CONNECT_REQ requests that the DLS provider establish a connection.

DL_CONNECT_IND informs the callee of the request, which may be accepted using DL_CONNECT_RES. DL_CONNECT_CON informs the caller that the connection has been established.

The normal sequence of messages is illustrated in Figure 1-12 “Message Flow: Successful Connection Establishment”.

Figure 1-12 Message Flow: Successful Connection Establishment

Once the connection is established, the DLS users may exchange user data using DL_DATA_REQ and DL_DATA_IND.

The DLS user may accept an incoming connect request on either the stream where the connect indication arrived or at an alternate, responding stream. The responding stream is indicated by a token in the DL_CONNECT_RES. This token is a value associated with the responding stream and is obtained by issuing a DL_TOKEN_REQ on that stream. The DLS provider responds to this request by generating a token for the stream and returning it to the DLS user in a DL_TOKEN_ACK.

Connections may be established on a stream other than that which received the DL_CONNECT_IND by passing a non-zero dl_resp_token in the DL_CONNECT_RES. The dl_resp_token value is obtained by doing a DL_TOKEN_REQ on the stream to which the connection is being passed (the data stream). The DL_CONNECT_RES is done on the stream which received the DL_CONNECT_IND (the control stream). Both the control and data streams must be bound on the same local SAP. After the DL_CONNECT_RES, the control stream will be left in the INCON_PEND state if there are more outstanding connect indications; otherwise, it will be left in the IDLE state. The data stream will be in the DATAXFER state.

The normal sequence of messages for obtaining a token is illustrated in Figure 1-13 “Message Flow: Token Retrieval”.

Figure 1-13 Message Flow: Token Retrieval

In the typical connection establishment scenario, the callee processes one connect indication at a time, accepting the connection on another stream. Once the user responds to the current connect indication, the next connect indication (if any) can be processed. DLPI also enables the callee to multi-thread incoming connect indications. The user can receive multiple connect indications before responding to any of them. This enables the DLS user to establish priority schemes on incoming connect requests.

Connection Establishment Rejection

In certain situations, the connection establishment request cannot be completed. The following describes the occasions under which DL_DISCONNECT_REQ and DL_DISCONNECT_IND primitives will flow during connection establishment, causing the connect request to be aborted.

Figure 1-14 “Message Flow: Callee Rejection of Connection Establishment Attempt” illustrates the situation where the callee chooses to reject the connect request by issuing DL_DISCONNECT_REQ instead of DL_CONNECT_RES.

Figure 1-14 Message Flow: Callee Rejection of Connection Establishment Attempt

Figure 1-15 “Message Flow: DLS Provider Rejection of a Connection Establishment Attempt” illustrates the situation where the DLS provider rejects a connect request for lack of resources or other reasons. The DLS provider sends DL_DISCONNECT_IND in response to DL_CONNECT_REQ.

Figure 1-15 Message Flow: DLS Provider Rejection of a Connection Establishment Attempt

Figure 1-16 “Message Flow: Both Primitives are Destroyed by Provider” through Figure 1-18 “Message Flow: DL_DISCONNECT Indication Arrives after DL_CONNECT Response is Sent” illustrate the situation where the caller chooses to abort a previous connection attempt. The DLS user issues DL_DISCONNECT_REQ at some point following a DL_CONNECT_REQ. The resulting sequence of primitives depends on the relative timing of the primitives involved, as defined in the following time sequence diagrams.

Figure 1-16 Message Flow: Both Primitives are Destroyed by Provider

Figure 1-17 Message Flow: DL_DISCONNECT Indication Arrives before DL_CONNECT Response is Sent

Figure 1-18 Message Flow: DL_DISCONNECT Indication Arrives after DL_CONNECT Response is Sent

The connection-mode data transfer service provides for the exchange of user data in either direction or in both directions simultaneously between DLS users. Data is transmitted in logical groups called data link service data units (DLSDUs). The DLS provider preserves both the sequence and boundaries of DLSDUs as they are transmitted.

Normal data transfer is neither acknowledged nor confirmed. It is up to the DLS users, if they so choose, to implement a confirmation protocol.

Each DL_DATA_REQ primitive conveys a DLSDU from the local DLS user to the DLS provider. Similarly, each DL_DATA_IND primitive conveys a DLSDU from the DLS provider to the remote DLS user. The normal flow of messages is illustrated in Figure 1-19 “Message Flow: Normal Data Transfer”.

Figure 1-19 Message Flow: Normal Data Transfer

The connection release service provides for the DLS users or the DLS provider to initiate the connection release. Connection release is an abortive operation and any data in transit (not been delivered to the DLS user) may be discarded.

DL_DISCONNECT_REQ requests that a connection be released. DL_DISCONNECT_IND informs the DLS user that a connection has been released. Normally, one DLS user requests disconnection and the DLS provider issues an indication of the ensuing release to the other DLS user, as illustrated by the message flow in Figure 1-20 “Message Flow: DLS User-Invoked Connection Release”.

Figure 1-20 Message Flow: DLS User-Invoked Connection Release

Figure 1-21 “Message Flow: Simultaneous DLS User Invoked Connection Release” illustrates that when two DLS users independently invoke the connection release service, neither of them receives a DL_DISCONNECT_IND.

Figure 1-21 Message Flow: Simultaneous DLS User Invoked Connection Release

Figure 1-22 “Message Flow: Simultaneous DLS User & DLS Provider Invoked Connection Release” illustrates that when the DLS provider and the local DLS user simultaneously invoke the connection release service, the remote DLS user receives a DL_DISCONNECT_IND.

Figure 1-22 Message Flow: Simultaneous DLS User & DLS Provider Invoked Connection Release

The reset service may be used by the DLS user to resynchronize the use of a data link connection, or by the DLS provider to report detected loss of data unrecoverable within the data link service.

Invocations of the reset service will unblock the flow of DLSDUs if the data link connection is congested; DLSDUs may be discarded by the DLS provider. The DLS user or users that did not invoke the reset will be notified that a reset has occurred. A reset may require a recovery procedure to be performed by the DLS users.

The interaction between each DLS user and the DLS provider will be one of the following:

The DL_RESET_REQ acts as a synchronization mark in the stream of DLSDUs that are transmitted by the issuing DLS user; the DL_RESET_IND acts as a synchronization mark in the stream of DLSDUs that are received by the peer DLS user. Similarly, the DL_RESET_RES acts as a synchronization mark in the stream of DLSDUs that are transmitted by the responding DLS user; the DL_RESET_CON acts as a synchronization mark in the stream of DLSDUs that are received by the DLS user which originally issued the reset.

The resynchronizing properties of the reset service are as follows:

The complete message flow depends on the origin of the reset, which may be the DLS provider or either DLS user. Figure 1-23 “Message Flow: DLS User-Invoked Connection Reset” illustrates the message flow for a reset invoked by one DLS user.

Figure 1-23 Message Flow: DLS User-Invoked Connection Reset

Figure 1-24 “Message Flow: Simultaneous DLS User-Invoked Connection Reset” illustrates the message flow for a reset invoked by both DLS users simultaneously.

Figure 1-24 Message Flow: Simultaneous DLS User-Invoked Connection Reset

Figure 1-25 “Message Flow: DLS Provider-Invoked Connection Reset” illustrates the message flow for a reset invoked by the DLS provider.

Figure 1-25 Message Flow: DLS Provider-Invoked Connection Reset

Figure 1-26 “Message Flow: Simultaneous DLS User & DLS Provider-Invoked Connection Reset” illustrates the message flow for a reset invoked simultaneously by one DLS user and the DLS provider.

Figure 1-26 Message Flow: Simultaneous DLS User & DLS Provider-Invoked Connection Reset

The connectionless data transfer service provides for the exchange of user data (DLSDUs) in either direction or in both directions simultaneously without having to establish a data link connection. Data transfer is neither acknowledged nor confirmed, and there is no end-to-end flow control provided. As such, the connectionless data transfer service cannot guarantee reliable delivery of data. However, a specific DLS provider can provide assurance that messages will not be lost, duplicated, or reordered.

DL_UNITDATA_REQ conveys one DLSDU to the DLS provider. DL_UNITDATA_IND conveys one DLSDU to the DLS user. The normal flow of messages is illustrated in Figure 1-27 “Message Flow: Connectionless Data Transfer”.

Figure 1-27 Message Flow: Connectionless Data Transfer

The connectionless-mode error reporting service may be used to notify a DLS user that a previously sent data unit either produced an error or cannot be delivered. This service does not, however, guarantee that an error indication will be issued for every undeliverable data unit.

Figure 1-28 Connectionless-Mode Error Reporting

The raw-mode data transfer service provides the same service as the connectionless data transfer service. The only difference is that the raw- mode DLS user builds the complete MAC and LLC headers prior to data transfer, whereas the connectionless-mode DLS user merely specifies the peer DLS user, and the DLS provider then builds the complete MAC and LLC headers before transferring the packet.

The DL_HP_RAWDATA_REQ conveys one DLSDU to the DLS provider. The DL_HP_RAWDATA_IND conveys one DLSDU to the DLS user. The normal flow of messages is illustrated in Figure 1-29 “Message Flow: Raw Data Transfer”.

Figure 1-29 Message Flow: Raw Data Transfer

The raw-mode error reporting service provides the same services as the connectionless-mode error reporting services. However, the DL_ERROR_ACK primitive is used instead of the DL_UDERROR primitive to report all the error conditions in raw-mode.

Figure 1-30 Raw-Mode Error Reporting

The XID and TEST service enables the DLS user to issue an XID or TEST request to the DLS provider. On receiving a response for the XID or TEST frame transmitted to the peer DLS provider, the DLS provider sends up an XID or TEST confirmation primitive to the DLS user. On receiving an XID or TEST frame from the peer DLS provider, the local DLS provider sends up an XID or TEST indication respectively to the DLS user. The DLS user must respond with an XID or TEST response primitive.

If the DLS user requested automatic handling of the XID or TEST response, at bind time, the DLS provider will send up an error acknowledgment on receiving an XID or TEST request. In addition, no indications will be generated to the DLS user on receiving XID or TEST frames from the remote side.

XID and TEST packets are handled differently on connection oriented streams compared to connectionless streams. On connectionless streams, XID and TEST packets may be sent and received by any stream at any time after binding. On connection oriented streams, XID and TEST packets may be sent and received at any time after binding by streams specifying a non- zero dl_max_conind in the DL_BIND_REQ.

Connection oriented streams which specify a zero dl_max_conind in the DL_BIND_REQ will only receive XID and TEST packets after a connection has been established.

LLC Type 2 monitors XID packets sent and received on connection oriented streams. If the stream has a connection established, LLC Type 2 will set the local and remote receive window sizes to the sizes specified in the XID packets.

The normal flow of message is illustrated in Figure 1-31 “Message Flow: XID Service” and Figure 1-32 “Message Flow: Test Service”.

Figure 1-31 Message Flow: XID Service

Figure 1-32 Message Flow: Test Service