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.
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 |
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. |
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 |
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 | ||
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 |
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 |
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 |
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:
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 following points clarify the state transition table:
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 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 | - | - |
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 |
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 | - |
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 | 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 |
Contents | Next section | Index |