Data Link Provider Interface (DLPI), Version 2
Copyright © 2000 The Open Group

Allowable Sequence of DLPI Primitives

This appendix presents the allowable sequence of DLPI primitives. The sequence is described using a state transition table that defines possible states as maintained by the DLS provider.

The state transition table describes transitions based on the current state of the interface and a given DLPI event. Each transition consists of a state change and possibly an interface action.

The states, events, and related transition actions are described below, followed by the state transition table itself.

The DLS provider is required to acknowlege the majority of requests from the user with a locally generated acknowlegement (either a DL_OK_ACK, some specific DL_xxx_ACK or a DL_ERROR_ACK primitive). These acknowlegement primitives are M_PCPROTO messages.

While expecting these responses, the user is said to "have a local acknowlegement pending".

The DLS provider can generate a DL_ERROR_ACK primitive in response to a DL_CONNECT_REQ, DL_RESET_REQ or DL_TEST/XID_REQ/RES primitive even though a positive acknowlegement is not required.

DLPI States

The following table describes the states associated with DLPI. It presents the state name used in the state transition table , the corresponding DLPI state name used throughout this specification, a brief description of the state, and an indication of whether the state is valid for connection-oriented data link service (DL_CODLS), connectionless data link service (DL_CLDLS), acknowledged connectionless data link service (ACLDLS) or all.

Table: States Associated with DLPI

State DLPI State Description Service
Type
0) UNATTACHED DL_UNATTACHED Stream opened but PPA not attached ALL

1) ATTACH PEND DL_ATTACH_PENDING The DLS user is waiting for an acknowledgement of a DL_ATTACH_REQ ALL

2) DETACH PEND DL_DETACH_PENDING The DLS user is waiting for an acknowledgement of a DL_DETACH_REQ ALL

3) UNBOUND DL_UNBOUND Stream is attached but not bound to a DLSAP ALL

4) BIND PEND DL_BIND_PENDING The DLS user is waiting for an acknowledgement of a DL_BIND_REQ ALL

5) UNBIND PEND DL_UNBIND_PENDING The DLS user is waiting for an acknowledgement of a DL_UNBIND_REQ ALL

6) IDLE DL_IDLE The stream is bound and activated for use - connection establishment or connectionless data transfer may take place ALL

7) UDQOS PEND DL_UDQOS_PENDING The DLS user is waiting for an acknowledgement of a DL_UDQOS_REQ DL_CLDLS

8) OUTCON PEND DL_OUTCON_PENDING An outgoing connection is pending - the DLS user is waiting for a DL_CONNECT_CON DL_CODLS

9) INCON PEND DL_INCON_PENDING An incoming connection is pending - the DLS provider is waiting for a DL_CONNECT_RES DL_CODLS

10) CONN_RES PEND DL_CONN_RES_PENDING The DLS user is waiting for an acknowledgement of a DL_CONNECT_RES DL_CODLS

11) DATAXFER DL_DATAXFER Connection-mode data transfer may take place DL_CODLS

12) USER RESET PEND DL_USER_RESET_PENDING A user-initiated reset is pending - the DLS user is waiting for a DL_RESET_CON DL_CODLS

13) PROV RESET PEND DL_PROV_RESET_PENDING A provider-initiated reset is pending - the DLS provider is waiting for a DL_RESET_RES DL_CODLS

14) RESET_RES PEND DL_RESET_RES_PENDING The DLS user is waiting for an acknowledgement of a DL_RESET_RES DL_CODLS

15) DISCON 8 PEND DL_DISCON8_PENDING The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_OUTCON_PENDING state DL_CODLS

16) DISCON 9 PEND DL_DISCON9_PENDING The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_INCON_PENDING state DL_CODLS

17) DISCON 11 PEND DL_DISCON11_PENDING The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_DATAXFER state DL_CODLS

18) DISCON 12 PEND DL_DISCON12_PENDING The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_USER_RESET_PENDING state DL_CODLS

19) DISCON 13 PEND DL_DISCON13_PENDING The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_PROV_RESET_PENDING state DL_CODLS

20) SUBS_BIND PEND DL_SUBS_BIND_PND The DLS user is waiting for an acknowledgement of a DL_SUBS_BIND_REQ ALL

21) SUBS_UNBIND PEND DL_SUBS_UNBIND_PND The DLS user is waiting for an acknowledgement of a DL_SUBS_UNBIND_REQ ALL

	State	DLPI State	Description	Service
				Type
0)	UNATTACHED	DL_UNATTACHED	Stream opened but PPA not attached	ALL

1)	ATTACH PEND	DL_ATTACH_PENDING	The DLS user is waiting for an acknowledgement of a DL_ATTACH_REQ	ALL

2)	DETACH PEND	DL_DETACH_PENDING	The DLS user is waiting for an acknowledgement of a DL_DETACH_REQ	ALL

3)	UNBOUND	DL_UNBOUND	Stream is attached but not bound to a DLSAP	ALL

4)	BIND PEND	DL_BIND_PENDING	The DLS user is waiting for an acknowledgement of a DL_BIND_REQ	ALL

5)	UNBIND PEND	DL_UNBIND_PENDING	The DLS user is waiting for an acknowledgement of a DL_UNBIND_REQ	ALL

6)	IDLE	DL_IDLE	The stream is bound and activated for use - connection establishment or connectionless data transfer may take place	ALL

7)	UDQOS PEND	DL_UDQOS_PENDING	The DLS user is waiting for an acknowledgement of a DL_UDQOS_REQ	DL_CLDLS

8)	OUTCON PEND	DL_OUTCON_PENDING	An outgoing connection is pending - the DLS user is waiting for a DL_CONNECT_CON	DL_CODLS

9)	INCON PEND	DL_INCON_PENDING	An incoming connection is pending - the DLS provider is waiting for a DL_CONNECT_RES	DL_CODLS

10)	CONN_RES PEND	DL_CONN_RES_PENDING	The DLS user is waiting for an acknowledgement of a DL_CONNECT_RES	DL_CODLS

11)	DATAXFER	DL_DATAXFER	Connection-mode data transfer may take place	DL_CODLS

12)	USER RESET PEND	DL_USER_RESET_PENDING	A user-initiated reset is pending - the DLS user is waiting for a DL_RESET_CON	DL_CODLS

13)	PROV RESET PEND	DL_PROV_RESET_PENDING	A provider-initiated reset is pending - the DLS provider is waiting for a DL_RESET_RES	DL_CODLS

14)	RESET_RES PEND	DL_RESET_RES_PENDING	The DLS user is waiting for an acknowledgement of a DL_RESET_RES	DL_CODLS

15)	DISCON 8 PEND	DL_DISCON8_PENDING	The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_OUTCON_PENDING state	DL_CODLS

16)	DISCON 9 PEND	DL_DISCON9_PENDING	The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_INCON_PENDING state	DL_CODLS

17)	DISCON 11 PEND	DL_DISCON11_PENDING	The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_DATAXFER state	DL_CODLS

18)	DISCON 12 PEND	DL_DISCON12_PENDING	The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_USER_RESET_PENDING state	DL_CODLS

19)	DISCON 13 PEND	DL_DISCON13_PENDING	The DLS user is waiting for an acknowledgement of a DL_DISCONNECT_REQ issued from the DL_PROV_RESET_PENDING state	DL_CODLS

20)	SUBS_BIND PEND	DL_SUBS_BIND_PND	The DLS user is waiting for an acknowledgement of a DL_SUBS_BIND_REQ	ALL

21)	SUBS_UNBIND PEND	DL_SUBS_UNBIND_PND	The DLS user is waiting for an acknowledgement of a DL_SUBS_UNBIND_REQ	ALL

Variables and Actions for State Transition Table

The following tables describe variables and actions used to describe the DLPI state transitions.

The variables are used to distinguish various uses of the same DLPI primitive. For example, a DL_CONNECT_RES causes a different state transition depending on the current number of outstanding connect indications. To distinguish these different connect response events, a variable is used to track the number of outstanding connect indications.

VARIABLE DESCRIPTION
token The token contained in a DL_CONNECT_RES that indicates on which stream the connection will be established. A value of zero indicates that the connection will be established on the stream where the DL_CONNECT_IND arrived. A non-zero value indicates the connection will be passed to another stream.

outcnt Number of outstanding connect indications - those to which the DLS user has not responded. Actions in the state tables that manipulate this value may be disregarded when providing connectionlessservice.

VARIABLE	DESCRIPTION
token	The token contained in a DL_CONNECT_RES that indicates on which stream the connection will be established. A value of zero indicates that the connection will be established on the stream where the DL_CONNECT_IND arrived. A non-zero value indicates the connection will be passed to another stream.

outcnt	Number of outstanding connect indications - those to which the DLS user has not responded. Actions in the state tables that manipulate this value may be disregarded when providing connectionlessservice.

Table: DPLI State Transition Table Variables

The actions represent steps the DLS provider must take during certain state transitions to maintain the interface state. When an action is indicated in the state transition table, the DLS provider should change the state as indicated and perform the specified action.

ACTION DESCRIPTION
1 outcnt = outcnt + 1

2 outcnt = outcnt - 1

3 Pass connection to the stream indicated by the token in the DL_CONNECT_RES primitive

ACTION	DESCRIPTION
1	outcnt = outcnt + 1

2	outcnt = outcnt - 1

3	Pass connection to the stream indicated by the token in the DL_CONNECT_RES primitive

Table: DLPI State Transition Actions

DLPI User-originated Events

The following table describes events initiated by the DLS user that correspond to the various request and response primitives of DLPI. The table presents the event name used in the state transition table, a brief description of the event (including the corresponding DLPI primitive), and an indication of whether the event is valid for connection-oriented data link service (DL_CODLS), connectionless data link service (DL_CLDLS), acknowledged connectionless data link service (DL_ACLDLS) or all.

FSM EVENT DESCRIPTION SERVICE
TYPE
ATTACH_REQ DL_ATTACH_REQ primitive ALL

DETACH_REQ DL_DETACH_REQ primitive ALL

BIND_REQ DL_BIND_REQ primitive ALL

SUBS_BIND_REQ DL_SUBS_BIND_REQ primitive ALL

UNBIND_REQ DL_UNBIND_REQ primitive ALL

SUBS_UNBIND_REQ DL_SUBS_UNBIND_REQ primitive ALL

UNITDATA_REQ DL_UNITDATA_REQ primitive DL_CLDLS

UDQOS_REQ DL_UDQOS_REQ primitive DL_CLDLS

CONNECT_REQ DL_CONNECT_REQ primitive DL_CODLS

CONNECT_RES DL_CONNECT_RES primitive DL_CODLS

PASS_CONN Received a passed connection from a DL_CONNECT_RES primitive DL_CODLS

DISCON_REQ DL_DISCONNECT_REQ primitive DL_CODLS

DATA_REQ DL_DATA_REQ primitive DL_CODLS

RESET_REQ DL_RESET_REQ primitive DL_CODLS

RESET_RES DL_RESET_RES primitive DL_CODLS

DATA_ACK_REQ DL_DATA_ACK_REQ primitive DL_ACLDLS

REPLY_REQ DL_REPLY_REQ primitive DL_ACLDLS

REPLY_UPDATE_REQ DL_REPLY_UPDATE_REQ primitive DL_ACLDLS

FSM EVENT	DESCRIPTION	SERVICE
		TYPE
ATTACH_REQ	DL_ATTACH_REQ primitive	ALL

DETACH_REQ	DL_DETACH_REQ primitive	ALL

BIND_REQ	DL_BIND_REQ primitive	ALL

SUBS_BIND_REQ	DL_SUBS_BIND_REQ primitive	ALL

UNBIND_REQ	DL_UNBIND_REQ primitive	ALL

SUBS_UNBIND_REQ	DL_SUBS_UNBIND_REQ primitive	ALL

UNITDATA_REQ	DL_UNITDATA_REQ primitive	DL_CLDLS

UDQOS_REQ	DL_UDQOS_REQ primitive	DL_CLDLS

CONNECT_REQ	DL_CONNECT_REQ primitive	DL_CODLS

CONNECT_RES	DL_CONNECT_RES primitive	DL_CODLS

PASS_CONN	Received a passed connection from a DL_CONNECT_RES primitive	DL_CODLS

DISCON_REQ	DL_DISCONNECT_REQ primitive	DL_CODLS

DATA_REQ	DL_DATA_REQ primitive	DL_CODLS

RESET_REQ	DL_RESET_REQ primitive	DL_CODLS

RESET_RES	DL_RESET_RES primitive	DL_CODLS

DATA_ACK_REQ	DL_DATA_ACK_REQ primitive	DL_ACLDLS

REPLY_REQ	DL_REPLY_REQ primitive	DL_ACLDLS

REPLY_UPDATE_REQ	DL_REPLY_UPDATE_REQ primitive	DL_ACLDLS

Table: DLPI User-oriented Events

DLPI Provider-Originated Events

The following table describes the events initiated by the DLS provider that correspond to the various indication, confirmation, and acknowledgement primitives of DLPI. The table presents the event name used in the state transition table, a brief description of the event (including the corresponding DLPI primitive), and an indication of whether the event is valid for connection-oriented data link service (DL_CODLS), connectionless data link service (DL_CLDLS), acknowledged connectionless service (DL_ACDLS) or all.

FSM EVENT DESCRIPTION SERVICE
TYPE
BIND_ACK DL_BIND_ACK primitive ALL

SUBS_BIND_ACK DL_SUBS_BIND_ACK primitive ALL

UNITDATA_IND DL_UNITDATA_IND primitive DL_CLDLS

UDERROR_IND DL_UDERROR_IND primitive DL_CLDLS

CONNECT_IND DL_CONNECT_IND primitive DL_CODLS

CONNECT_CON DL_CONNECT_CON primitive DL_CODLS

DISCON_IND1 DL_DISCONNECT_IND primitive when outcnt == 0 DL_CODLS

DISCON_IND2 DL_DISCONNECT_IND primitive when outcnt == 1 DL_CODLS

DISCON_IND3 DL_DISCONNECT_INDprimitive when outcnt >1 DL_CODLS

DATA_IND DL_DATA_IND primitive DL_CODLS

RESET_IND DL_RESET_IND primitive DL_CODLS

RESET_CON DL_RESET_CON primitive DL_CODLS

OK_ACK1 DL_OK_ACK primitive when outcnt == 0 ALL

OK_ACK2 DL_OK_ACK primitive when outcnt == 1 and token == 0 DL_CODLS

OK_ACK3 DL_OK_ACK primitive when outcnt == 1 and token != 0 DL_CODLS

OK_ACK4 DL_OK_ACK primitive when outcnt >1 and token != 0 DL_CODLS

ERROR_ACK DL_ERROR_ACK ALL

DATA_ACK_IND DL_DATA_ACK_IND ACLDLS

DATA_ACK_STATUS_IND DL_DATA_ACK_STATUS_IND ACLDLS

REPLY_IND DL_REPLY_IND ACLDLS

REPLY_STATUS_IND DL_REPLY_STATUS_IND ACLDLS

REPLY_UPDATE_STATUS_IND DL_REPLY_UPDATE_STATUS_IND ACLDLS

FSM EVENT	DESCRIPTION	SERVICE
		TYPE
BIND_ACK	DL_BIND_ACK primitive	ALL

SUBS_BIND_ACK	DL_SUBS_BIND_ACK primitive	ALL

UNITDATA_IND	DL_UNITDATA_IND primitive	DL_CLDLS

UDERROR_IND	DL_UDERROR_IND primitive	DL_CLDLS

CONNECT_IND	DL_CONNECT_IND primitive	DL_CODLS

CONNECT_CON	DL_CONNECT_CON primitive	DL_CODLS

DISCON_IND1	DL_DISCONNECT_IND primitive when outcnt == 0	DL_CODLS

DISCON_IND2	DL_DISCONNECT_IND primitive when outcnt == 1	DL_CODLS

DISCON_IND3	DL_DISCONNECT_INDprimitive when outcnt >1	DL_CODLS

DATA_IND	DL_DATA_IND primitive	DL_CODLS

RESET_IND	DL_RESET_IND primitive	DL_CODLS

RESET_CON	DL_RESET_CON primitive	DL_CODLS

OK_ACK1	DL_OK_ACK primitive when outcnt == 0	ALL

OK_ACK2	DL_OK_ACK primitive when outcnt == 1 and token == 0	DL_CODLS

OK_ACK3	DL_OK_ACK primitive when outcnt == 1 and token != 0	DL_CODLS

OK_ACK4	DL_OK_ACK primitive when outcnt >1 and token != 0	DL_CODLS

ERROR_ACK	DL_ERROR_ACK	ALL

DATA_ACK_IND	DL_DATA_ACK_IND	ACLDLS

DATA_ACK_STATUS_IND	DL_DATA_ACK_STATUS_IND	ACLDLS

REPLY_IND	DL_REPLY_IND	ACLDLS

REPLY_STATUS_IND	DL_REPLY_STATUS_IND	ACLDLS

REPLY_UPDATE_STATUS_IND	DL_REPLY_UPDATE_STATUS_IND	ACLDLS

Table: DLPI Provider-Originated Events

DLPI State Transition Table

DLPI State Transition - Local Management Phase, DLPI State Transition - Connectionless DT Phase, DLPI State Transition - Acknowledged Connectionless DT Phase , DLPI State Transition - Connection Establishment Phase and DLPI State Transition - Connection-mode Data Transfer Phase describe the DLPI state transitions. Each column represents a state of DLPI (see States Associated with DLPI, and each row represents a DLPI event (see DLPI User-oriented Events and DLPI Provider-Originated Events). The intersecting transition cell defines the resulting state transition (that is, next state) and associated actions, if any, that must be executed by the DLS provider to maintain the interface state. Each cell may contain the following:

-: this transition cannot occur.
n: the current input results in a transition to state "n"
n [a]: the list of actions "a" should be executed following the specified state transition "n" (see DLPI State Transition Actions for actions).

The DL_INFO_REQ, DL_INFO_ACK, DL_TOKEN_REQ, and DL_TOKEN_ACK primitives are excluded from the state transition table because they can be issued from many states and, when fully processed, do not cause a state transition to occur. However, the DLS user may not issue a DL_INFO_REQ or DL_TOKEN_REQ if any local acknowledgements are pending. In other words, these two primitives may not be issued until the DLS user receives the acknowledgement for any previously issued primitive that is expecting local positive acknowledgement. Thus, these primitives may not be issued from the following states:

: DL_ATTACH_PENDING
DL_DETACH_PENDING
DL_BIND_PENDING
DL_SUBS_BIND_PND
DL_SUBS_UNBIND_PND
DL_UNBIND_PENDING
DL_UDQOS_PENDING
DL_CONN_RES_PENDING
DL_RESET_RES_PENDING
DL_DISCON8_PENDING
DL_DISCON9_PENDING
DL_DISCON11_PENDING
DL_DISCON12_PENDING
DL_DISCON13_PENDING

Failure to comply by this restriction may result in loss of primitives at the stream head if the DLS user is a user process.

Once a DL_INFO_REQ or DL_TOKEN_REQ has been issued, the DLS provider must respond with the appropriate acknowledgement primitive.

The following rules apply to the maintenance of DLPI state:

The DLS provider is responsible for keeping a record of the state of the interface as viewed by the DLS user, to be returned in the DL_INFO_ACK.
The DLS provider may never generate a primitive that places the interface out of state (i.e. would correspond to a "-" cell entry in the state transition table below).
If the DLS provider generates a STREAMS M_ERROR message upstream, it should free any further primitives processed by it's write side put or service procedure.
The close of a stream is considered an abortive action by the DLS user, and may be executed from any state. The DLS provider must issue appropriate indications to the remote DLS user when a close occurs. For example, if the DLPI state is DL_DATAXFER,a DL_DISCONNECT_IND should be sent to the remote DLS user. The DLS provider should free any resources associated with that stream and reset the stream to its unopened condition.

The following points clarify the state transition table:

If the DLS provider supports connection-mode service, the value of the outcnt state variable must be initialized to zero for each stream when that stream is first opened.
The initial and final state for a style 2 DLS provider is DL_UNATTACHED. However, because a style 1 DLS provider implicitly attaches a PPA to a stream when it is opened, the initial and final DLPI state for a style 1 provider is DL_UNBOUND. The DLS user should not issue DL_ATTACH_REQ or DL_DETACH_REQ primitives to a style 1 DLS provider.
A DLS provider may have multiple connect indications outstanding (i.e. the DLS user has not responded to them) at one time (see Multi-threaded Connection Establishment). As the state transition table points out, the stream on which those indications are outstanding will remain in the DL_INCON_PENDING state until the DLS provider receives a response for all indications.
The DLPI state associated with a given stream may be transferred to another stream only when the DL_CONNECT_RES primitive indicates this behavior. In this case, the responding stream (where the connection will be established) must be in the DL_IDLE state. This state transition is indicated by the PASS_CONN event in table 9.
The labeling of the states DL_PROV_RESET_PENDING and DL_USER_RESET_PENDING indicate the party that started the local interaction, and does not necessarily indicate the originator of the reset procedure.
A DL_DATA_REQ primitive received by the DLS provider in the state DL_PROV_RESET_PENDING (i.e. after a DL_RESET_IND has been passed to the DLS user) or the state DL_IDLE (i.e. after a data link connection has been released) should be discarded by the DLS provider.
A DL_DATA_IND primitive received by the DLS user after the user has issued a DL_RESET_REQ should be discarded.

To ensure accurate processing of DLPI primitives, the DLS provider must adhere to the following rules concerning the receipt and generation of STREAMS M_FLUSH messages during various state transitions:

The DLS provider must be ready to receive M_FLUSH messages from upstream and flush it's queues as specified in the message.
The DLS provider must issue an M_FLUSH message upstream to flush both the read and write queues after receiving a successful DL_UNBIND_REQ primitive but before issuing the DL_OK_ACK.
If an incoming disconnect occurs when the interface is in the DL_DATAXFER, DL_USER_RESET_PENDING, or DL_PROV_RESET_PENDING state, the DLS provider must send up an M_FLUSH message to flush both the read and write queues before sending up a DL_DISCONNECT_IND.
If a DL_DISCONNECT_REQ is issued in the DL_DATAXFER, DL_USER_RESET_PENDING, or DL_PROV_RESET_PENDING states, the DLS provider must issue an M_FLUSH message upstream to flush both the read and write queues after receiving the successful DL_DISCONNECT_REQ but before issuing the DL_OK_ACK.
If a reset occurs when the interface is in the DL_DATAXFER or DL_USER_RESET_PENDING state, the DLS provider must send up an M_FLUSH message to flush both the read and write queues before sending up a DL_RESET_IND or DL_RESET_CON.

If the DLS user keeps its own DLPI state, it may need to handle additional combinations of DLPI states and primitives not described by the state transition tables. This is due to the fact that allowable primitives issued by DLS provider and DLS user may cross at the interface, so that the provider-originated event arrives after the DLS user has already changed its state according to the user-generated event. The details are part of the provider-specific documentation.

The following table presents the allowed sequence of DLPI primitives for the common local management phase of communication.

STATES UNATT. ATTACH DETACH UNBND BND UNBND IDLE SUBS_BND SUBS
PEND PEND PND PND PND UNBND
PND
EVENTS 0 1 2 3 4 5 6 20 21
ATTACH_REQ 1 - - - - - - - -
DETACH_REQ - - - 2 - - - - -
BIND_REQ - - - 4 - - - - -
BIND_ACK - - - - 6 - - - -
SUBS_BIND_REQ - - - - - - 20 - -
SUBS_BIND_ACK - - - - - - - 6 -
UNBIND_REQ - - - - - - 5 - -
OK_ACK1 - 3 0 - - 3 - - 6
ERROR_ACK - 0 3 - 3 6 - - -
SUBS_UNBND_RQ - - - - - - 21 - -

STATES	UNATT.	ATTACH	DETACH	UNBND	BND	UNBND	IDLE	SUBS_BND	SUBS
		PEND	PEND		PND	PND		PND	UNBND
									PND
EVENTS	0	1	2	3	4	5	6	20	21
ATTACH_REQ	1	-	-	-	-	-	-	-	-
DETACH_REQ	-	-	-	2	-	-	-	-	-
BIND_REQ	-	-	-	4	-	-	-	-	-
BIND_ACK	-	-	-	-	6	-	-	-	-
SUBS_BIND_REQ	-	-	-	-	-	-	20	-	-
SUBS_BIND_ACK	-	-	-	-	-	-	-	6	-
UNBIND_REQ	-	-	-	-	-	-	5	-	-
OK_ACK1	-	3	0	-	-	3	-	-	6
ERROR_ACK	-	0	3	-	3	6	-	-	-
SUBS_UNBND_RQ	-	-	-	-	-	-	21	-	-

Table: DLPI State Transition - Local Management Phase

The following table presents the allowed sequence of DLPI primitives for the connectionless data transfer phase.

STATES IDLE UDQOS
PEND
EVENTS 6 7
UDQOS_REQ 7 -
OK_ACK1 - 6
ERROR_ACK - 6
UNITDATA_REQ 6 -
UNITDATA_IND 6 -
UDERROR_IND 6 -

STATES	IDLE	UDQOS
		PEND
EVENTS	6	7
UDQOS_REQ	7	-
OK_ACK1	-	6
ERROR_ACK	-	6
UNITDATA_REQ	6	-
UNITDATA_IND	6	-
UDERROR_IND	6	-

Table: DLPI State Transition - Connectionless DT Phase

The following table presents the allowed sequence of DLPI primitives for the acknowledged connectionless-mode data transfer phase.

STATES IDLE UDQOS
PEND
EVENTS 6 7
UDQOS_REQ 7 -
OK_ACK1 - 6
ERROR_ACK - 6
DATA_ACK_REQ 6 -
REPLY_REQ 6 -
REPLY_UPDATE_REQ 6 -
DATA_ACK_IND 6 -
REPLY_IND 6 -
DATA_ACK_STATUS_IND 6 -
REPLY_STATUS_IND 6 -
REPLY_UPDATE_STATUS_IND 6 -
ERROR_ACK 6 -

STATES	IDLE	UDQOS
		PEND
EVENTS	6	7
UDQOS_REQ	7	-
OK_ACK1	-	6
ERROR_ACK	-	6
DATA_ACK_REQ	6	-
REPLY_REQ	6	-
REPLY_UPDATE_REQ	6	-
DATA_ACK_IND	6	-
REPLY_IND	6	-
DATA_ACK_STATUS_IND	6	-
REPLY_STATUS_IND	6	-
REPLY_UPDATE_STATUS_IND	6	-
ERROR_ACK	6	-

Table: DLPI State Transition - Acknowledged Connectionless DT Phase

The following table presents the allowed sequence of DLPI primitives for the connection establishment phase of connection mode service.

STATES IDLE OUTCON INCON CONN_RES DATA- DISCON 8 DISCON 9
PEND PEND PEND XFER PEND PEND
EVENTS 6 8 9 10 11 15 16
CONNECT_REQ 8 - - - - - -
CONNECT_RES - - 10 - - - -
DISCON_REQ - 15 16 - - - -
PASS_CONN 11 - - - - - -
CONNECT_IND 9 [1] - 9 [1] - - - -
CONNECT_CON - 11 - - - - -
DISCON_IND1 - 6 - - 6 - -
(outcnt == 0)
DISCON_IND2 - - 6 [2] - - - -
(outcnt == 1)
DISCON_IND3 - - 9 [2] - - - -
(outcnt > 1)
OK_ACK1 - - - - - 6 -
(outcnt == 0)
OK_ACK2 - - - 11 [2] - - 6 [2]
(outcnt == 1,
token == 0)
OK_ACK3 - - - 6 [2,3] - - 6 [2]
(outcnt == 1,
token != 0)
OK_ACK4 - - - 9 [2,3] - - 9 [2]
(outcnt > 1,
token != 0)
ERROR_ACK - 6 - 9 - 8 9

STATES	IDLE	OUTCON	INCON	CONN_RES	DATA-	DISCON 8	DISCON 9
		PEND	PEND	PEND	XFER	PEND	PEND
EVENTS	6	8	9	10	11	15	16
CONNECT_REQ	8	-	-	-	-	-	-
CONNECT_RES	-	-	10	-	-	-	-
DISCON_REQ	-	15	16	-	-	-	-
PASS_CONN	11	-	-	-	-	-	-
CONNECT_IND	9 [1]	-	9 [1]	-	-	-	-
CONNECT_CON	-	11	-	-	-	-	-
DISCON_IND1	-	6	-	-	6	-	-
(outcnt == 0)
DISCON_IND2	-	-	6 [2]	-	-	-	-
(outcnt == 1)
DISCON_IND3	-	-	9 [2]	-	-	-	-
(outcnt >	1)
OK_ACK1	-	-	-	-	-	6	-
(outcnt == 0)
OK_ACK2	-	-	-	11 [2]	-	-	6 [2]
(outcnt == 1,
token == 0)
OK_ACK3	-	-	-	6 [2,3]	-	-	6 [2]
(outcnt == 1,
token != 0)
OK_ACK4	-	-	-	9 [2,3]	-	-	9 [2]
(outcnt >	1,
token != 0)
ERROR_ACK	-	6	-	9	-	8	9

Table: DLPI State Transition - Connection Establishment Phase

The following table presents the allowed sequence of DLPI primitives for the connection mode data transfer phase.

STATES IDLE DATA- USER PROV RESET_RES DISCON 11 DISCON 12 DISCON 13
XFER RESET RESET PEND PEND PEND PEND
PEND PEND
EVENTS 6 11 12 13 14 17 18 19
DISCON_REQ - 17 18 19 - - - -
DATA_REQ - 11 - - - - - -
RESET_REQ - 12 - - - - - -
RESET_RES - - - 14 - - - -
DISCON_IND1 - 6 6 6 - - - -
(outcnt == 0)
DATA_IND - 11 - - - - - -
RESET_IND - 13 - - - - - -
RESET_CON - - 11 - - - - -
OK_ACK1 - - - - 11 6 6 6
(outcnt == 0)
ERROR_ACK - - 11 - 13 11 12 13

STATES	IDLE	DATA-	USER	PROV	RESET_RES	DISCON 11	DISCON 12	DISCON 13
		XFER	RESET	RESET	PEND	PEND	PEND	PEND
			PEND	PEND
EVENTS	6	11	12	13	14	17	18	19
DISCON_REQ	-	17	18	19	-	-	-	-
DATA_REQ	-	11	-	-	-	-	-	-
RESET_REQ	-	12	-	-	-	-	-	-
RESET_RES	-	-	-	14	-	-	-	-
DISCON_IND1	-	6	6	6	-	-	-	-
(outcnt == 0)
DATA_IND	-	11	-	-	-	-	-	-
RESET_IND	-	13	-	-	-	-	-	-
RESET_CON	-	-	11	-	-	-	-	-
OK_ACK1	-	-	-	-	11	6	6	6
(outcnt == 0)
ERROR_ACK	-	-	11	-	13	11	12	13

Table: DLPI State Transition - Connection-mode Data Transfer Phase

Contents

Next section

Index